کاربران n8n در اولین workflow واقعی‌شان گیر می‌کنند، نه به‌خاطر کمبود دانش فنی، بلکه به‌خاطر یک سوءتفاهم ساختاری: فرض می‌کنند هر نود مثل task در Zapier مستقل اجرا میشود. در n8n یک JSON object اتمی در تمام مسیر flow می‌کند؛ اگر نودی در میانه شکست بخورد، نودهای قبلی rollback نمی‌شوند و retry side effects تکراری تولید می‌کند. درک مدل execution اتمی، پیش‌شرط هر تصمیم معماری در n8n است.
n8n چیست و مدل execution آن چه فرقی با Zapier دارد؟#
n8n یک موتور workflow مبتنی بر node است که تمام نودهای یک اجرا را در context مشترک کار می‌کند؛ برخلاف Zapier که هر task را stateless و ایزوله اجرا می‌کند. در n8n خروجی هر نود ورودی نود بعدی است و retry کل مسیر از نقطه‌ی شکست را دوباره اجرا می‌کند، نه فقط همان step.
این معماری node-based یعنی شما یک Trigger node تعریف میکنید، سپس نودها را بهصورت زنجیره‌ای به هم وصل میکنید. هر نود یک Credential (مجموعه‌ی کلید API) دارد و با Expression داده‌ها را map می‌کند.
تفاوت عملی این دو مدل execution در رفتار retry خودش را نشان میدهد. در Zapier، اگر یک task فیل شود، فقط همان task دوباره اجرا میشود. در n8n، کل workflow از نود فیل‌شده به بعد دوباره اجرا میشود و اگر نود قبلی یک ایمیل ارسال کرده باشد، retry آن را دوباره ارسال می‌کند. این دقیقاً همان چیزی است که در production هزینه‌ی واقعی می‌سازد.
چرا توصیف «n8n یک Zapier رایگان است» گمراه‌کننده است#
توصیف «n8n یک Zapier رایگان است» از سه جهت نادرست است: معماری execution مشترک دارد نه ایزوله، لایسنس Fair-Code آن فروش SaaS را محدود می‌کند نه free-tier ساده، و برای glue code بین APIها ساخته شده نه جایگزینی Zapier در سناریوهای one-to-one.
لایسنس Fair-Code یعنی شما میتوانید n8n را روی سرور خودتان رایگان اجرا کنید، اما نمی‌توانید آن را بهعنوان سرویس SaaS بفروشید. این تفاوت با open-source واقعی (مثل MIT) مهم است و باید قبل از تصمیم‌گیری برای self-hosting بدانید.
بیش از 400 integration آماده در n8n#
n8n طبق مستندات رسمی بیش از 400 integration آماده دارد که شبکههای اجتماعی، ابزارهای CRM، دیتابیس‌ها، سرویس‌های ابری و LLMها را پوشش میدهد. اما نکته‌ی مهم‌تر از تعداد، کیفیت پوشش است: بسیاری از این integrationها فقط wrapper روی HTTP Request node هستند و با تغییر API ممکن است بشکنند.
الگوی تکرارشونده‌ای که در پروژه‌های اعضای کامیونیتی مکرر دیده شده: کاربران ابتدا سراغ integration آماده می‌روند، با محدودیت‌هایش مواجه میشوند، و در نهایت HTTP Request node سفارشی می‌نویسند. در n8n، HTTP Request node مهمترین نود است، نه integrationهای آماده.
مراحل ساخت اولین workflow در n8n از صفر#
اولین workflow عملی n8n با ترتیب Webhook → HTTP Request → Code Node → Email ساخته میشود. با اجرای این زنجیره، مدل جریان داده‌ی JSON object بین نودها را مستقیماً تجربه میکنید و می‌فهمید چرا هر نود فقط خروجی نود قبلی را می‌بیند و نه بیشتر.
سناریو: یک Webhook پیام دریافت می‌کند، با یک API خارجی چک می‌کند، نتیجه را فیلتر می‌کند و ایمیل می‌فرستد.
- Webhook node (Trigger): یک endpoint HTTPS می‌سازد. وقتی کسی به این URL POST بزند، workflow اجرا میشود. Payload دریافتی بهصورت JSON object در خروجی نود قرار می‌گیرد.
- HTTP Request node: خروجی Webhook را با Expression به URL مقصد map می‌کند. مثلاً اگر Webhook یک email آدرس گرفته، با آن یک API را صدا می‌زنید.
- Code Node: ورودی‌اش را از $input.all() می‌خواند، روی آیتم‌ها loop می‌زند، فیلتر می‌کند و خروجی JSON جدید برمی‌گرداند.
- Email node: خروجی Code Node را با Expression در body ایمیل قرار میدهد و ارسال می‌کند.
- تست: دکمه‌ی Execute Workflow را بزنید و در پنل Execution Output، JSON هر نود را بررسی کنید. اینجا مدل اتمی execution را می‌بینید.
مدل جریان داده — هر نود ورودی‌اش را از خروجی JSON نود قبلی می‌خواند#
مدل جریان داده در n8n آرایه‌ای از JSON objects است که بین نودها حرکت می‌کند. هر object یک item با ساختار { json: {...}, binary: {...} } است. اگر نود اول 3 آیتم تولید کند، نود دوم 3 بار اجرا میشود — یک بار برای هر آیتم.
این رفتار fan-out (پخش خودکار) قدرت اصلی n8n است. اما اگر نود دوم فقط یک آیتم برمی‌گرداند، نود سوم هم یک بار اجرا میشود. تعداد آیتم‌ها بین نودها می‌تواند کم و زیاد شود و این را باید در Expressionها در نظر بگیرید.
آیا برای یادگیری n8n باید کدنویسی بلد باشم؟#
برای یادگیری n8n کدنویسی کامل لازم نیست، اما بدون آشنایی حداقلی با JSON و JavaScript، Expression و Code node عملاً غیرقابل استفاده‌اند. توصیف «n8n کاملاً no-code است» گمراه‌کننده است؛ شما باید بتوانید ساختار JSON را بخوانید، propertyها را با نقطه و براکت دسترسی بگیرید، و در Code node حلقه و شرط بنویسید.
الگوی رایج که در کامیونیتی مشاهده شده: کاربران بدون دانش JSON، در Expression گیر می‌کنند چون نمی‌فهمند چرا {{ $json.data[0].name }} کار می‌کند ولی {{ $json.name }} نه. پاسخ در ساختار آرایه‌ای خروجی نود قبلی است.
نصب n8n با Docker روی سرور لینوکس#
نصب n8n با Docker روی سرور لینوکس از طریق Docker Compose انجام میشود. مهمترین نکته‌ای که در اکثر آموزش‌ها گفته نمی‌شود: backup جداگانه‌ی encryption key. بدون N8N_ENCRYPTION_KEY، تمام credentialها غیرقابل بازیابی‌اند و باید از صفر تعریفشان کنید.
مراحل نصب:
- نصب Docker و Docker Compose: بسته‌های docker-ce و docker-compose-plugin را از مخزن رسمی Docker نصب کنید. نسخه‌های LTS توزیع لینوکس معمولاً Docker قدیمی‌تری دارند.
- نوشتن docker-compose.yml: image با نام n8nio/n8n را مشخص کنید. Volume برای /home/node/.n8n بگذارید تا workflowها و credentialها persist شوند.
- تنظیم N8N_ENCRYPTION_KEY: با دستور
openssl rand -hex 32یک کلید تصادفی بسازید و در متغیر محیطی قرار دهید. این مقدار را در یک password manager ذخیره کنید. - Expose پورت و reverse proxy: پورت 5678 n8n را پشت Nginx یا Caddy بگذارید. اگر از Caddy استفاده میکنید، HTTPS خودکار با Let's Encrypt فعال میشود.
- اتصال دامنه و SSL: DNS را به IP سرور وصل کنید. متغیرهای محیطی N8N_HOST و N8N_PROTOCOL را تنظیم کنید تا Webhook URLها درست ساخته شوند.
تفاوت n8n cloud و self-hosted از نظر هزینه و کنترل#
تفاوت n8n cloud و self-hosted در سطح کنترل و مسئولیت عملیاتی است: در cloud زیرساخت توسط n8n مدیریت میشود و محدودیت execution ماهانه دارید، در self-hosted کنترل کامل روی داده دارید اما backup encryption key، مقیاس‌پذیری و آپدیت‌های امنیتی مسئولیت شماست.
توصیه‌ی عملی: اگر workflowهایتان شامل داده‌ی حساس (API keyهای مالی، داده‌ی مشتری) هستند، self-hosted تنها گزینه‌ی منطقی است. اگر فقط اتوماسیون داخلی ساده می‌خواهید، cloud شروع بهتری است.
محدودیت‌های مقیاس‌پذیری self-hosted#
مقیاس‌پذیری self-hosted در n8n محدود به معماری single-process پیش‌فرض است. برای رفع این محدودیت، باید queue mode فعال کنید: یک Redis server + چند worker process + یک main process. این معماری در مستندات n8n توضیح داده شده ولی پیاده‌سازی‌اش برای تیم‌های کوچک سنگین است.
الگوی مشاهده‌شده در کامیونیتی: کاربران ابتدا self-hosted ساده اجرا می‌کنند، با افزایش execution به مشکل performance می‌خورند، و در نهایت به queue mode مهاجرت می‌کنند. اگر از ابتدا execution بالایی دارید، queue mode را در نصب اولیه تنظیم کنید.
پلن رایگان n8n cloud#
پلن رایگان n8n cloud امکان تست workflowها را با محدودیت execution ماهانه فراهم می‌کند. جزئیات قیمت و محدودیت‌های دقیق در صفحه‌ی pricing سایت n8n.io قابل مشاهده است و بسته به تغییرات سرویس‌دهنده به‌روزرسانی میشود. برای شروع و تست کافی است؛ برای production معمولاً به paid plan نیاز پیدا میکنید.
Expression یا Code node؟ کدام را کجا استفاده کنم#
Expression در n8n فقط یک مقدار برمی‌گرداند و برای تبدیل ساده‌ی داده‌هاست؛ Code node برای loop، condition و logic چندمرحله‌ای ضروری است. اشتباه رایج تازه‌واردها: تلاش برای شرط‌گذاری پیچیده در Expression که منجر به فرمول‌های ناخوانا و شکست‌پذیر میشود.
Expression سینتکس {{ }} دارد و به JSON جریان دسترسی میدهد. مثلاً {{ $json.name.toUpperCase() }} یک مقدار string برمی‌گرداند. اما اگر بخواهید روی 10 آیتم loop بزنید و هر کدام را شرطی پردازش کنید، Expression ابزارش نیست.
چه زمانی Expression کافی است#
Expression برای کارهای تک‌مقداری و تبدیل‌های ساده کافی است: mapping فیلدها بین نودها، string manipulation، خواندن مقدار از context، و تبدیل نوع برای مقدارهای ساده. هر کاری که فقط یک مقدار برگرداند، جای خود را در Expression دارد.
- Mapping فیلدها: خروجی نود A را به ورودی نود B وصل کنید.
- String manipulation ساده: uppercase، lowercase، trim، replace.
- خواندن مقدار از context: $json، $node، $items، $workflow.
- تبدیل نوع: Number()، String()، JSON.parse() برای مقدارهای ساده.
چه زمانی Code node لازم است#
Code node در سناریوهایی ضروری است که منطق تصمیم‌گیری چندمرحله‌ای، loop با شرط داخلی، یا تبدیل ساختار داده لازم باشد. هر جا Expression به فرمول ناخوانا تبدیل شود، نشانه‌ی جابه‌جایی به Code node است.
- Loop روی آیتم‌ها با منطق شرطی داخلی.
- Condition nested: اگر X و (Y یا Z) آنگاه...
- API call سفارشی که integration آماده ندارد.
- تبدیل ساختار داده: از آرایه‌ی تخت به nested object.
- Aggregate: جمع زدن مقادیر چند آیتم به یک خروجی.
Code node هم JavaScript و هم Python را پشتیبانی می‌کند. در JavaScript، $input.all() آرایه‌ی ورودی‌ها را برمی‌گرداند و $output.all() آرایه‌ی خروجی را تنظیم می‌کند.
Split Out node برای تکرار روی آیتم‌های آرایه‌ای#
Split Out node در n8n یک فیلد آرایه‌ای را به آیتم‌های مستقل تبدیل می‌کند. اگر یک نود خروجی‌اش یک JSON با فیلد آرایه‌ای است (مثلاً لیست 20 کاربر)، Split Out آن آرایه را به 20 آیتم مستقل تبدیل می‌کند و نودهای بعدی بهصورت fan-out روی هر آیتم اجرا میشوند.
نکته‌ی عملی: Split Out node را قبل از Code node استفاده نکنید اگر میتوانید loop را در Code node بنویسید. Split Out execution count را بالا می‌برد و در self-hosted با محدودیت memory، می‌تواند مشکل‌ساز شود.
چطور با n8n ایجنت هوش مصنوعی بسازم؟#
ایجنت هوش مصنوعی (AI Agent) در n8n با AI Agent node ساخته میشود که با LangChain و مدل‌هایی مثل OpenAI یا Anthropic کار می‌کند. ایجنت داخل workflow تعریف میشود و state بین executionها persist نمی‌شود مگر Memory node اضافه کنید. این محدودیت معماری مهمترین تفاوت n8n با LangChain standalone است.
ساختار AI Agent node سه جزء دارد: LLM (مغز ایجنت)، Tool nodes (ابزارهایی که ایجنت می‌تواند صدا بزند)، و Memory node (ذخیره‌ی context بین پیام‌ها).
تفاوت معماری AI Agent در n8n با LangChain standalone#
معماری AI Agent در n8n کنترل کمتری روی agent loop به شما میدهد نسبت به LangChain standalone. در LangChain شما تعیین میکنید چند بار tool call شود، چه زمانی متوقف شود، و state کجا ذخیره شود. در n8n، Agent loop تعداد tool callها را خودش تعیین می‌کند و شما فقط max iterations را تنظیم میکنید.
الگوی مشاهده‌شده در پروژه‌های واقعی: کاربران ابتدا با AI Agent node شروع می‌کنند، به محدودیت‌هایش برمی‌خورند، و در نهایت Code node سفارشی با fetch() به API LLM می‌نویسند. برای ایجنت‌های پیچیده، n8n بهعنوان orchestrator بهتر عمل می‌کند تا بهعنوان agent runtime.
محدودیت‌های ایجنت در n8n نسبت به CrewAI و LangGraph#
محدودیت اصلی ایجنت در n8n نسبت به CrewAI و LangGraph در معماری single-agent است. CrewAI و LangGraph برای multi-agent systems ساخته شده‌اند. اگر سناریوی شما نیاز به همکاری چند ایجنت با نقش‌های مختلف دارد، n8n ابزار درست نیست. اما اگر یک ایجنت با چند tool کافی است، n8n ساده‌تر و سریع‌تر است.
Tool node در n8n می‌تواند به APIهای خارجی یا Sub-workflow وصل شود. این یعنی ایجنت شما می‌تواند یک workflow کامل n8n را بهعنوان tool صدا بزند. این الگو — agent + sub-workflow as tool — در پروژه‌های واقعی n8n زیاد دیده میشود.
RAG در n8n با Vector Store node#
Vector Store node در n8n برای RAG (Retrieval-Augmented Generation) استفاده میشود: سند را chunk میکنید، embedding می‌گیرید، و در یک vector database ذخیره میکنید. ایجنت قبل از پاسخ‌دهی، relevant chunks را retrieve می‌کند و در context قرار میدهد.
n8n با Pinecone، Supabase، Qdrant و چند vector database دیگر integration آماده دارد. اما اگر volume اسنادتان بالاست، performance retrieval در n8n cloud ممکن است کند باشد. در این حالت، self-hosted با Redis cache بهتر عمل می‌کند.
ورک‌فلو نمونه: Webhook → AI Agent → HTTP Request → Email#
این ورک‌فلو نمونه یک سناریوی واقعی را پوشش میدهد: کاربر پیام به Webhook می‌فرستد، ایجنت آن را پردازش می‌کند، با یک API خارجی چک می‌کند، و نتیجه را ایمیل می‌کند. چهار نود ساده، مدل execution اتمی n8n را به‌خوبی نشان میدهد.
- Webhook node: payload شامل user message و metadata دریافت می‌کند.
- AI Agent node: LLM با system prompt تعریف میشود. Tool node به HTTP Request وصل است تا ایجنت بتواند API بزند.
- HTTP Request node: نتیجه‌ی ایجنت را با یک API داخلی (مثلاً CRM) تطبیق میدهد.
- Email node: پاسخ نهایی را برای کاربر ارسال می‌کند.
هر نود خروجی JSON نود قبلی را می‌خواند و یک JSON جدید تولید می‌کند. همین است که مدل execution اتمی را از stateless task جدا می‌کند.
مدیریت خطا و محدودیت‌های عملیاتی n8n#
مدیریت خطا در n8n با Error Trigger node انجام میشود، اما چون execution اتمی است و rollback ندارد، retry بدون idempotency (هم‌توانی) side effects تکراری ایجاد می‌کند. این نکته‌ای است که در اکثر آموزش‌های فارسی‌زبان غایب است و علت اصلی باگ‌های production است.
مثال عملی: یک workflow که ایمیل ارسال می‌کند و سپس در نود بعدی فیل میشود. اگر retry فعال باشد، ایمیل دوباره ارسال میشود. راه‌حل: idempotency key در API مقصد، یا قرار دادن نودهای side-effectful در انتهای workflow.
چه زمانی n8n مناسب نیست#
n8n مناسب نیست وقتی workflow بیش از 10 تا 15 نود دارد و conditional branching پیچیده نیاز است؛ در آن نقطه، نگهداری آن در n8n از نوشتن یک script Python ساده‌تر نیست. این آستانه‌ای است که در پروژه‌های اعضای کامیونیتی مکرر مشاهده شده و بهعنوان الگوی تصمیم‌گیری معرفی میشود.
علائم هشدار که n8n ابزار اشتباهی است:
- بیش از 3 سطح nested condition در workflow.
- نیاز به stateful execution بین چند workflow.
- منطق business که هر هفته تغییر می‌کند.
- نیاز به unit test روی منطق workflow.
الگوی تصمیم‌گیری: glue code بین APIها = n8n / business logic سنگین = script#
الگوی تصمیم‌گیری ساده است: glue code بین APIها = n8n، business logic سنگین = script. n8n برای کارهایی ساخته شده که یک endpoint را صدا بزنید، خروجی را transform کنید، و به endpoint بعدی بفرستید — 3 تا 5 نود. اما اگر منطق تصمیم‌گیری پیچیده‌ای دارید که هر هفته تغییر می‌کند، یک script Python یا TypeScript قابل‌تست و قابلmaintain بهتر است.
امنیت: Credential management، Encryption key، Access control#
امنیت n8n در self-hosted به سه نقطه‌ی بحرانی بستگی دارد: Credential management با encryption key، backup مستقل آن key، و Access control برای چند کاربر. اگر encryption key را گم کنید، تمام credentialها غیرقابل بازیابی‌اند و باید از صفر تعریفشان کنید.
نکات امنیتی عملی:
- encryption key را در password manager ذخیره کنید، نه در فایل plain text کنار docker-compose.yml.
- در cloud، API keyها را در credential manager n8n بگذارید، نه در Expression hardcode.
- برای multi-user، از n8n Enterprise با RBAC استفاده کنید یا self-hosted را پشت reverse proxy با authentication بگذارید.
مقایسه n8n با Zapier، Make، Activepieces و Pipedream#
مقایسه n8n با Zapier، Make، Activepieces و Pipedream باید بر اساس مدل execution باشد نه تعداد integration. n8n از نظر self-hosting و کنترل داده بی‌رقیب است. Zapier ساده‌تر ولی محدودتر؛ Make گران‌تر و پیچیده‌تر؛ Activepieces تازه‌نفس و محدود؛ Pipedream developer-first.
| معیار | n8n | Zapier | Make | Activepieces | Pipedream |
|---|---|---|---|---|---|
| مدل execution | Atomic JSON object بین نودها | Stateless task per step | Scenario-based با router | Atomic (مشابه n8n) | Code-first با workflow |
| Self-hosting | بله (Fair-Code) | خیر | خیر | بله (MIT) | بله (free tier) |
| AI Agent | AI Agent node با LangChain | AI Actions (محدود) | AI modules | AI blocks (محدود) | LLM SDK (کدنویسی) |
| تعداد integration | بیش از 400 | بیش از 6000 | بیش از 1500 | چند صد | چند صد + code |
| مناسب برای | Glue code + ایجنت ساده | اتوماسیون ساده بدون کد | Workflow پیچیده با router | شروع رایگان | توسعه‌دهنده‌ها |
مقایسه بر اساس model execution#
مقایسه بر اساس model execution تفاوت بنیادی را آشکار می‌کند: در n8n شما context کامل execution را در هر نود در اختیار دارید، اما در Zapier هر step مستقل است و باید داده را از طریق path و filter منتقل کنید. در سناریوهای چندمرحله‌ای، این تفاوت n8n را انعطاف‌پذیرتر می‌کند.
مقایسه بر اساس محدودیت rate limit و مدل pricing#
مقایسه بر اساس مدل pricing تفاوت هزینه‌ی عملیاتی را نشان میدهد: Zapier بر اساس task ماهانه، Make بر اساس operation، n8n cloud بر اساس execution، و Pipedream بر اساس compute time قیمت‌گذاری می‌کند. در self-hosted محدودیت pricing وجود ندارد و فقط hardware شما محدودیت است.
توصیه‌ی عملی بر اساس نیاز:
- اگر داده‌ی حساس دارید: n8n self-hosted یا Activepieces.
- اگر فقط اتوماسیون ساده می‌خواهید: Zapier (ساده‌ترین UI).
- اگر workflow با branching پیچیده دارید: Make (router و iterator قوی‌تر).
- اگر توسعه‌دهنده هستید: Pipedream (code-first، بدون محدودیت UI).
- اگر ایجنت AI + glue code می‌خواهید: n8n (AI Agent node + HTTP Request).
کدام ابزار برای چه استفاده‌ای مناسب‌تر است#
انتخاب ابزار بر اساس استفاده‌ی مورد نیاز باید از سؤال «مدل execution من stateless است یا اتمی» شروع شود، نه از «کدام ابزار بهتر است». اگر workflow شما چند مرحله‌ای است و هر مرحله خروجی مرحله‌ی قبل را نیاز دارد، n8n یا Make انتخاب منطقی‌تری هستند. اگر هر step مستقل است و فقط یک فیلد را پاس میدهید، Zapier ساده‌تر است.
برای ایجنت هوش مصنوعی، n8n یک مزیت عملی دارد: میتوانید یک workflow کامل را بهعنوان Tool node به ایجنت وصل کنید. ایجنت شما به‌جای صدا زدن یک API، یک workflow چندمرحله‌ای را اجرا می‌کند. این الگو در Zapier و Make به این سادگی ممکن نیست.
مهمترین نکته‌ای که در آموزش n8n یاد گرفتید: مدل execution اتمی را درک کنید، Expression را برای کارهای ساده نگه دارید، Code node را برای منطق پیچیده استفاده کنید، و workflow را تا آستانه‌ی 10 تا 15 نود نگه دارید. اگر از این فراتر رفتید، به script مهاجرت کنید.
اگر می‌خواهید ایجنت هوش مصنوعی بسازید و از n8n درآمد کسب کنید، دوره‌ی «ساخت Ai Agent با N8N» در اسکول دقیقاً همین مسیر را پوشش میدهد — از مدل execution تا deployment ایجنت واقعی.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.