آموزش n8n فقط یادگیری رابط کاربری نیست. تفاوت یک workflow اسباب‌بازی با یک workflow عملیاتی در سه تصمیم معماری مشخص خلاصه میشود: تجزیه‌ی منطق با sub-workflow، اجتناب از تله‌ی HTTP Request node، و درک سقف latency ذاتی پلتفرم. بدون این سه تصمیم، هر اتوماسیونی که بسازید در مرحله‌ی production فرو می‌پاشد.
آموزش n8n از صفر: معماری workflow-based چیست؟#
معماری workflow-based در n8n یعنی هر جریان کاری از سه عنصر ساخته میشود: trigger node (نقطه‌ی شروع)، action node (مراحل پردازش)، و connection (مسیر جریان داده به‌صورت JSON). این سه‌گانه، تمام منطق اتوماسیون را بدون کدنویسی سنگین پوشش می‌دهد و debugging را به بررسی خروجی تک‌تک نودها تقلیل می‌دهد.
هر نود یک تابع مستقل است: ورودی مشخص، خروجی مشخص. نودها با connection به هم متصل میشوند و داده به‌صورت آبجکت JSON از یک نود به نود بعدی جریان می‌یابد. همین ساختار، n8n را از ابزارهایی که منطق را در یک بلوک سیاه پنهان می‌کنند متمایز می‌سازد.
اجزای ساختاری: Trigger Node، Action Node و Connection#
Trigger node نقطه‌ی شروع workflow است. سه نوع اصلی دارد: Webhook Trigger (دریافت درخواست HTTP)، Schedule Trigger (اجرای زمان‌بندی‌شده)، و App Trigger (رویداد از سرویس خارجی مثل Gmail یا Slack). هر workflow حداقل یک trigger دارد — بدون آن، نودها هرگز اجرا نمی‌شوند.
Action node وظیفه‌ی پردازش را بر عهده دارد: ارسال درخواست HTTP، خواندن و نوشتن در Google Sheets، فراخوانی OpenAI API، یا اجرای منطق شرطی با IF node. n8n بیش از 400 integration آماده دارد که هر کدام به‌صورت action node قابل استفاده‌اند.
Connection، مسیر جریان داده بین نودهاست. هر connection یک آبجکت JSON منتقل میکند که شامل تمام فیلدهای خروجی نود قبلی است. در نود بعدی، این آبجکت با expression قابل دسترسی است.
جریان داده بین نودها: JSON Expression و data mapping#
داده در n8n به‌صورت آبجکت JSON بین نودها منتقل میشود. برای دسترسی به فیلدهای خروجی نود قبلی، از expression استفاده می‌کنید. مثال: اگر نود Webhook فیلدی به نام email دریافت کرده، در نود بعدی با {{ $json.email }} به آن دسترسی دارید.
Set node ابزار اصلی data mapping است. با آن فیلدهای خروجی را بازچینی می‌کنید، مقادیر ثابت اضافه می‌کنید، یا چند فیلد را به یک فیلد جدید نگاشت می‌کنید. در اکثر workflowهای عملیاتی، Set node بین trigger و action قرار می‌گیرد تا ساختار داده را نرمال‌سازی کند.
اولین workflow عملی: از Webhook Trigger تا Google Sheets#
یک workflow عملیاتی واقعی با ترتیب نودهای زیر ساخته میشود:
- Webhook Trigger: دریافت درخواست POST از فرم تماس وب‌سایت. فیلدهای email، name و message در body درخواست ارسال میشوند.
- Set node: بازچینی فیلدها — افزودن timestamp، فرمت‌دهی name، و استخراج domain از email.
- HTTP Request node: ارسال درخواست به OpenAI API برای دسته‌بندی موضوعی پیام (مثلاً «پشتیبانی» یا «فروش»). در این مرحله از API key در credentials استفاده میشود.
- IF node: بررسی نتیجه‌ی دسته‌بندی. اگر «فروش» بود، مسیر A؛ اگر «پشتیبانی» بود، مسیر B.
- Google Sheets node: ثبت ردیف جدید در شیت با فیلدهای name، email، category و timestamp.
این workflow در محیط development حدود 15 دقیقه ساخته میشود. نسخهی عملیاتی آن — با error handling، retry logic و logging — به 45 تا 60 دقیقه نیاز دارد. این شکاف، همان فاصله‌ی بین کسی که «n8n بلد است» و کسی که «n8n را در production استفاده میکند» است.
n8n در برابر Zapier و Make: مقایسه‌ای که مزیت اصلی را پنهان میکند#
تفاوت بنیادی n8n با Zapier و Make در self-hosting و مدل هزینهی متغیر است. مقایسه‌ی صرف بر پایه‌ی تعداد integration، این مزیت را نادیده می‌گیرد. n8n را میتوان روی سرور خودتان اجرا کرد؛ Zapier و Make فقط cloud هستند. این یعنی داده‌ها از زیرساخت شما خارج نمی‌شود.
برای سازمان‌هایی که با داده‌ی حساس (سلامت، مالی، دولتی) کار می‌کنند، self-hosting یک الزام است نه ترجیح. اما برای فریلنسری که 200 execution در ماه دارد، این مزیت عملاً بی‌فایده است و n8n Cloud ساده‌تر جواب می‌دهد.
جدول مقایسه‌ای: n8n vs Zapier vs Make vs Node-RED#
| معیار | n8n | Zapier | Make | Node-RED |
|---|---|---|---|---|
| مدل استقرار | Self-hosted + Cloud | فقط Cloud | فقط Cloud | Self-hosted |
| مدل هزینه | رایگان (community) یا Cloud با pricing بر اساس executions | ماهانه بر اساس task count | ماهانه بر اساس operations | رایگان (Apache 2.0) |
| پشتیبانی کد سفارشی | JavaScript در Code node و custom node | محدود (Python/JS در Code step) | محدود | محدود (Function node) |
| بهترین کاربرد | اتوماسیون سازمانی + ایجنت AI | اتوماسیون سادهی SaaS-to-SaaS | اتوماسیون چندمرحله‌ای با visual builder | اتوماسیون IoT و edge computing |
چرا self-hosting فقط یک آپشن فنی نیست؟#
سه پیامد عملی self-hosting در n8n وجود دارد که در مقایسه‌های معمول نادیده گرفته میشوند:
کنترل داده: تمام payloadها، credentials و لاگ‌ها روی سرور شما ذخیره میشوند. برای GDPR یا مقررات محلی داده، این الزامی است.
هزینهی اجرا: در مدل self-hosted community، هزینهی اجرای workflow صفر است. فقط زیرساخت (VPS، RAM، Redis) هزینه دارد. Zapier و Make بر اساس تعداد task یا operation قیمتگذاری میشوند؛ حجم بالای اجرا هزینهی تصاعدی ایجاد میکند.
Vendor lock-in: workflowهای n8n به‌صورت JSON export میشوند. اگر روزی تصمیم بگیرید پلتفرم را تغییر دهید، منطق workflow قابل انتقال است. در Zapier، workflowها در اکانت شما قفل هستند.
Node-RED و n8n: تفاوت در IoT و اتوماسیون سازمانی#
Node-RED توسط IBM ساخته شده و برای سناریوهای IoT و edge computing بهینه است. مصرف RAM پایین، latency کم، و پشتیبانی native از پروتکل‌های MQTT و Modbus آن را برای دستگاه‌های محدود منابع مناسب میکند. n8n برای اتوماسیون سازمانی با integrationهای SaaS و ایجنت AI طراحی شده. این دو رقیب نیستند؛ ابزارهای متفاوت برای مسئله‌های متفاوت‌اند.
چطور با n8n ایجنت هوش مصنوعی بسازم؟#
با LangChain nodes در n8n میتوان ایجنت هوش مصنوعی (AI Agent) ساخت. اما ایجنت‌های عملیاتی به معماری چندمرحله‌ای شامل router node، memory node و tool calling نیاز دارند، نه صرفاً یک Agent node. یک Agent node تنها برای نمونه‌های آموزشی کافی است و در production سه مشکل دارد: بدون memory، بدون routing، و بدون fallback.
n8n از نسخهی 1.x به بعد، مجموعه‌ای از LangChain nodes را به‌صورت native ارائه می‌دهد. این nodes شامل Agent، Memory، Tools، Model و Chain هستند. ترکیب این اجزا، ایجنت‌هایی می‌سازد که می‌توانند تصمیم بگیرند، ابزار فراخوانی کنند، و مکالمه را به یاد داشته باشند.
ایجنت ساده: یک LangChain Agent node با tool calling#
ساده‌ترین ایجنت n8n یک Agent node است که به یک LLM (مثلاً GPT-4) متصل شده و دو tool به آن داده‌اید: Calculator و Google Search. ایجنت خودش تصمیم می‌گیرد کدام tool را برای هر سوال فراخوانی کند. این الگو برای demo مناسب است.
اما در production، همین سادگی تبدیل به ضعف میشود. بدون memory، هر درخواست از صفر شروع میشود. بدون routing، تمام سوالات به یک LLM می‌روند. بدون fallback، اگر یک tool خطا بدهد، کل workflow می‌میرد.
ایجنت چندمرحله‌ای: الگوی Router + Memory + Tools#
ایجنت عملیاتی n8n با ترتیب نودهای زیر ساخته میشود:
- Trigger node: دریافت پیام کاربر (از Webhook، Telegram، یا Chat UI).
- Router node (IF یا Switch): دسته‌بندی نوع درخواست — «سوال اطلاعاتی»، «عملیات روی داده»، یا «مکالمه‌ی عمومی».
- Memory node: بازیابی context مکالمه‌ی قبلی. n8n از Redis Memory و Postgres Memory پشتیبانی میکند.
- Tool nodes: فراخوانی ابزارهای مشخص بر اساس مسیر router. Tool 1: جستجوی وب. Tool 2: کوئری به دیتابیس. Tool 3: ارسال ایمیل.
- Output node: تجمیع نتیجه و ارسال پاسخ به کاربر.
این الگو در پروژه‌های متعدد اعضای کامیونیتی n8n تکرار شده است. نکته‌ای که آموزش‌های معمولی نمی‌گویند: router node را نباید به LLM بسپارید. یک IF node ساده با keyword matching، هم سریع‌تر است هم قابل‌پیش‌بینی‌تر. ایجنت‌هایی که router را به LLM می‌سپارند، گاهی درخواست‌های واضح را هم اشتباه دسته‌بندی می‌کنند.
اتصال به OpenAI API و مدیریت context window#
برای اتصال ایجنت به OpenAI، از OpenAI Chat Model node استفاده می‌کنید. API key در credentials ذخیره میشود و در هیچ نود دیگری قابل‌مشاهده نیست. مدیریت context window (پنجره‌ی بافت) با تنظیم max tokens در model node و استفاده از memory node با window size مشخص انجام میشود.
اگر context window پر شود، n8n قدیمی‌ترین پیام‌ها را از memory حذف میکند. برای ایجنت‌هایی که مکالمه‌ی طولانی دارند، از Postgres Memory استفاده کنید تا context خارج از RAM ذخیره شود.
نصب n8n: Cloud یا Self-hosted؟ تصمیم‌گیری با معیارهای مشخص#
انتخاب بین n8n Cloud و self-hosted به سه معیار بستگی دارد: حجم اجرای ماهانه، حساسیت داده‌ها، و بودجه‌ی زیرساخت. «رایگان بودن» نسخهی community یک فریب ذهنی است؛ هزینهی واقعی self-hosting در زیرساخت و نگهداری است.
اگر تیم DevOps ندارید و حجم اجرای ماهانه‌تان زیر چند هزار execution است، n8n Cloud منطقی‌تر است. اما اگر داده‌ها حساس‌اند یا حجم اجرا بالاست، self-hosted هم ارزان‌تر تمام میشود هم کنترل بیشتری می‌دهد.
نصب با Docker: حداقل RAM و تنظیمات ضروری#
حداقل RAM مورد نیاز برای اجرای n8n در Docker، 1 گیگابایت است. برای workflowهای سنگین با AI agent، 4 گیگابایت به بالا توصیه میشود. تنظیمات ضروری شامل تعیین N8N_ENCRYPTION_KEY (برای رمزنگاری credentials)، GENERIC_TIMEZONE (برای schedule trigger)، و N8N_HOST است.
یک نکته که در مستندات کمتر تأکید میشود: encryption key را حتماً در environment variable ذخیره کنید. اگر آن را فراموش کنید یا سرور را ریست کنید، تمام credentials ذخیره‌شده غیرقابل بازیابی میشوند. این اشتباه، در کلاس‌های آموزشی و گفتگوهای کامیونیتی بارها تکرار شده و هزینه‌اش از دست دادن کل زیرساخت احراز هویت است.
نصب با npm: مناسب توسعه‌ی محلی#
برای development و تست سریع، نصب با npm ساده‌تر است. با npm install n8n -g نصب میشود و با n8n start اجرا. محدودیت اصلی: بدون Docker، مدیریت version و rollback دشوار است. این روش فقط برای محیط محلی مناسب است.
n8n Cloud: چه زمانی منطقی است؟#
n8n Cloud زمانی منطقی است که سه شرط همزمان برقرار باشد: حجم اجرای ماهانه پایین است، داده‌ها حساس نیستند، و تیم DevOps برای نگهداری زیرساخت ندارید. در غیر این صورت، self-hosted گزینهی بهتری است.
نسخهی community self-hosted تحت مجوز Sustainable Use License منتشر میشود. این مجوز فروش مجدد n8n بهعنوان سرویس رقابتی را ممنوع میکند اما استفادهی داخلی و اتوماسیون سازمانی را آزاد می‌گذارد.
اشتباهات رایج در ساخت workflow با n8n#
سه اشتباه پرهزینه در workflowهای n8n بارها تکرار میشوند: استفاده از HTTP Request node به‌جای native node برای سرویس‌هایی که node اختصاصی دارند، ساخت workflow تکپارچه‌ی بیش از 10 نود بدون تجزیه، و نادیده گرفتن credential management در محیط self-hosted. هر سه، هزینه‌اش را در production می‌پردازید.
تله‌ی HTTP Request node: چرا native node امن‌تر و قابل‌نگهداری‌تر است#
HTTP Request node قدرتمند است اما یک مشکل پنهان دارد: وقتی با آن به سرویسی مثل Slack یا Notion وصل می‌شوید، n8n دیگر credential management خودکار را اعمال نمی‌کند. API token را در header دستی وارد می‌کنید، روتیشن token را خودتان مدیریت می‌کنید، و error handling اختصاصی سرویس را از دست می‌دهید.
Native node (مثلاً Slack node) این کارها را به‌صورت داخلی انجام می‌دهد: credential در vault ذخیره میشود، retry logic دارد، و فیلدهای ورودی با schema سرویس validate میشوند. اگر سرویسی native node دارد، HTTP Request node یک گام به عقب است.
workflow 30 نودی و راه‌حل sub-workflow با Execute Workflow node#
وقتی یک workflow به بیش از 10-15 نود می‌رسد، debugging عملاً غیرممکن میشود. Execute Workflow node اجازه می‌دهد منطق را به workflowهای مستقل تجزیه کنید. هر sub-workflow یک مسئولیت مشخص دارد، ورودی و خروجی تمیز دارد، و مستقل قابل تست است.
الگوی مشاهده‌شده در پروژه‌های عملیاتی: workflow اصلی فقط routing و orchestration انجام می‌دهد (3-5 نود). منطق واقعی در sub-workflowهاست. این معماری، تغییر یک بخش بدون شکستن بقیه را ممکن میکند.
مدیریت رازها (credentials) و environment variables در self-hosted#
در self-hosted، credentials در دیتابیس داخلی n8n ذخیره میشوند و با encryption key رمزنگاری هستند. اما environment variables (مثل API keys برای سرویس‌های external) اگر مستقیم در workflow hard-code شوند، در export/import workflow قابل‌مشاهده میشوند.
راه‌حل: از environment variables در سطح instance استفاده کنید و با {{ $env.MY_API_KEY }} در workflow به آن‌ها دسترسی پیدا کنید. این‌طور secrets از workflow JSON جدا می‌مانند.
زمان‌هایی که n8n گزینهی اشتباه است#
n8n برای اتوماسیون‌های بلادرنگ با تأخیر زیر 100 میلی‌ثانیه، اتوماسیون‌های بسیار سادهی تک‌مرحله‌ای، و سناریوهای IoT با محدودیت سخت‌افزاری شدید مناسب نیست. معماری آن poll-based یا webhook-based است و latency ذاتی دارد.
هرچه بیشتر ابزار را تحسین کنید، بیشتر از این واقعیت فاصله می‌گیرید: n8n یک platform اتوماسیون است، نه یک runtime بلادرنگ.
سقف latency ذاتی: چرا poll-based و webhook-based بودن n8n مانع بلادرنگی است#
هر workflow در n8n حداقل یک round-trip کامل نیاز دارد: دریافت درخواست → اجرای نودها → ارسال پاسخ. حتی با یک Webhook Trigger ساده، latency در حد چند صد میلی‌ثانیه تا چند ثانیه است. این سقف ذاتی معماری event-driven n8n است و با hardware قوی‌تر حذف نمی‌شود.
اگر پروژه‌ی شما به پاسخ زیر 100 میلی‌ثانیه نیاز دارد (مثلاً trading system، real-time bidding، یا control loop صنعتی)، n8n ابزار اشتباهی است. در این موارد باید به سمت کد native یا frameworkهای low-latency بروید.
اتوماسیون‌های تک‌مرحله‌ای: Zapier یا Make ساده‌ترند#
اگر فقط می‌خواهید یک ایمیل جدید در Gmail را به یک ردیف در Google Sheets اضافه کنید، Zapier با 3 کلیک تمام میشود. n8n برای همین کار نیاز به ساخت workflow، نصب، و مدیریت سرور دارد. سادگی Zapier در سناریوهای تک‌مرحله‌ای، مزیت واقعی است.
سناریوهای IoT با محدودیت RAM: Node-RED سبک‌تر است#
روی یک Raspberry Pi Zero با 512 مگابایت RAM، اجرای n8n عملاً غیرممکن است. Node-RED با مصرف RAM پایین‌تر، گزینهی مناسب‌تری برای edge devices است. n8n حداقل به 1 گیگابایت RAM نیاز دارد و این برای IoT devices با منابع محدود، مانع جدی است.
مقیاس‌پذیری n8n: queue mode و worker architecture#
برای حجم بالای اجرا، n8n از معماری queue mode با Redis و worker nodeها استفاده میکند. بدون این تنظیمات، تمام workflowها در یک process واحد اجرا میشوند و عملکرد به‌شدت افت میکند. queue mode را نه برای زیبایی، بلکه برای بقا در ترافیک بالا لازم دارید.
معماری queue mode: Redis + worker + main process#
در queue mode، سه نوع process وجود دارد:
- Main process: UI، API، و مدیریت workflowها. درخواست‌های اجرا را در صف Redis قرار می‌دهد.
- Worker processes: workflowها را از صف برمی‌دارند و اجرا می‌کنند. هر worker یک process مستقل است.
- Redis: صف پیام و storage موقت بین main و workers.
این معماری به شما اجازه می‌دهد تعداد workers را با حجم اجرا افزایش دهید. هر worker می‌تواند روی یک CPU core جداگانه اجرا شود.
چه زمانی queue mode لازم است؟#
الگوی مشاهده‌شده در پروژه‌های عملیاتی: اگر در یک workflow همزمان چندین execution دارید (مثلاً Webhook که همزمان 10+ درخواست دریافت میکند) یا اگر workflowهای طولانی‌مدت دارید که execution timeشان بیش از چند ثانیه است، queue mode ضروری میشود. برای workflowهای سبک با اجرای تک‌نفره، حالت default کافی است.
تنظیمات Docker Compose برای production#
یک Docker Compose فایل production-ready شامل سه service است: n8n-main، n8n-worker (با replicas)، و redis. متغیرهای کلیدی: EXECUTIONS_MODE=queue، QUEUE_BULL_REDIS_HOST، و N8N_ENCRYPTION_KEY. حتماً Redis را در شبکه‌ی داخلی ایزوله کنید و access آن را محدود به n8n services نگه دارید.
یک نکته که در مستندات کمتر گفته میشود: اگر workerها را افزایش ظرفیت دهید، باید مطمئن شوید که workflowهای stateful (مثل Agent با memory) روی همان worker ادامه پیدا می‌کنند. برای این موارد، sticky session یا external memory (Redis/Postgres) لازم است.
آموزش n8n یک مسیر عملی است: ابتدا معماری workflow-based را بفهمید، سپس با اولین workflow واقعی شروع کنید، و در نهایت اشتباهات پرهزینه‌ی production را بشناسید. سه تصمیمی که در ابتدای این متن نام بردم — sub-workflow، native node، و درک سقف latency — مرز بین کسی که «n8n بلد است» و کسی که «n8n را در production استفاده میکند» را مشخص می‌کنند.
اگر می‌خواهید ایجنت هوش مصنوعی (AI Agent) با n8n بسازید و از آن درآمد داشته باشید، دوره‌ی «ساخت Ai Agent با N8N» در کامیونیتی N8N اسکول دقیقاً همین مسیر را از صفر تا پروژه‌ی عملیاتی پوشش می‌دهد. 51 جلسه، 41 ساعت، و 10 فصل — بدون وعده‌ی توخالی.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.