سه ادعای غلط در tutorials فارسیِ آموزش n8n وجود دارد: «کاملاً رایگان است»، «اصلاً کد لازم نیست» و «جایگزین کامل Zapier است». هر سه در عمل نادرست‌اند. این سه ادعا، هزینه‌ی پنهان تصمیم‌گیری را بالا می‌برند؛ چه برای فریلنسر که بعداً با محدودیت لایسنس مواجه شود، چه برای استارتاپی که workflow‌هایش وسط پروژه به بن‌بست expression‌های جاوااسکریپت می‌خورد.

n8n چیست و چرا «رایگان و متن‌باز» توصیف دقیق آن نیست#

n8n یک ابزار اتوماسیون نودمحور (Node-Based) است که workflow‌ها را به‌صورت بصری می‌سازید، اما تحت Sustainable Use License منتشر شده. این لایسنس استفاده‌ی داخلی را رایگان می‌کند، ولی فروش به‌عنوان سرویس یا جاسازی در محصول را محدود می‌سازد. تفاوتش با open-source واقعی دقیقاً همین محدودیت تجاری است، نه نقص فنی.

Jan Oberhauser بنیان‌گذار n8n در برلین، این ابزار را با فلسفه‌ی «اتوماسیون بدون قفل‌شدن به فروشنده (Vendor Lock-in)» ساخت. یعنی شما مالک داده‌ها و زیرساخت‌تان هستید، برخلاف Zapier که همه‌چیز روی سرورهای خودش اجرا می‌شود. ولی «مالکیت زیرساخت» به معنای «آزادی تجاری مطلق» نیست؛ و همین ظرافت را اکثر آموزش‌های فارسی رد می‌کنند.

تفاوت fair-code با open-source — چه چیزی می‌توانید رایگان انجام دهید و چه چیزی نمی‌توانید#

لایسنس fair-code (کد منصفانه) یک مدل میانه است. شما می‌توانید n8n را رایگان نصب کنید، برای شرکت خودتان workflow بسازید، حتی به‌صورت خودمیزبانی (Self-hosted) روی سرور خصوصی اجرا کنید. ولی اگر بخواهید n8n را به‌عنوان سرویس SaaS بفروشید، یا در محصول خودتان جاسازی کنید و به مشتری‌هایتان بدهید، باید نسخه‌ی Enterprise بخرید یا با تیم n8n مذاکره کنید.

برای بخش عمده‌ی استفاده‌های شخصی و داخلی، عملاً رایگان است. ولی همان مواردی که tutorials فارسی نادیده می‌گیرند، دقیقاً جایی‌اند که یک فریلنسر n8n را در محصولش جاسازی می‌کند یا یک استارتاپ آن را به‌عنوان لایه‌ی اتوماسیون مشتری‌محور استفاده می‌کند.

محدودیت‌های حقوقی Sustainable Use License برای جاسازی در محصول#

اگر یک SaaS دارید و می‌خواهید اتوماسیون داخلی‌اش را با n8n پیاده‌سازی کنید، لایسنس Sustainable Use License اجازه‌ی این کار را بدون مجوز تجاری نمی‌دهد. حتی اگر n8n را self-host کنید، تا زمانی که محصولتان به‌صورت چندمستأجری (Multi-tenant) اجرا می‌شود و n8n بخشی از سرویس‌دهی به مشتری است، در محدوده‌ی ممنوع قرار می‌گیرید.

برای استفاده‌ی تک‌مستأجری (Single-tenant) در یک پروژه‌ی سفارشی، معمولاً مشکلی نیست. ولی مرز دقیقش را باید با متن رسمی لایسنس چک کنید، نه با ترجمه‌ی یک blog post. این یکی از پرهزینه‌ترین اشتباهاتی است که در کلاس‌ها مکرر دیده می‌شود: کسی لایسنس را «رایگان» می‌خواند و بعد از فروش سرویس، با اخطار حقوقی مواجه می‌شود.

صدها integration داخلی و اکوسیستم built-in nodes#

n8n در نسخه‌ی اصلی‌اش صدها node داخلی دارد که سرویس‌های معروف مثل Gmail، Slack، Google Sheets، Airtable، Notion و ده‌ها API دیگر را پوشش می‌دهند (بر اساس مستندات n8n، این عدد در اوایل ۲۰۲۵ حدود ۴۰۰+ است و با هر release تغییر می‌کند). علاوه بر این، نودهای جامعه (Community Nodes) به‌صورت جداگانه توسعه پیدا می‌کنند. ولی کیفیت این community nodes قابل پیش‌بینی نیست؛ الگویی که در پروژه‌های اعضای کامیونیتی بارها گزارش شده و در بخش نصب self-hosted با جزئیات بیشتر می‌آید.

کدنویسی در n8n: آیا بدون JS می‌شود؟#

برای workflow‌های ساده واقعاً بدون کدنویسی می‌سازید. ولی به‌محض اینکه بخواهید داده‌ها را تبدیل کنید، شرط‌های چندشاخه بنویسید یا خروجی یک node را به ورودی node بعدی برسانید، باید expression جاوااسکریپت بنویسید. ادعای «صفر کد» فقط برای سناریوهای خطی و تک‌گامی درست است و همین محدودیت را tutorials فارسی هرگز نمی‌گویند.

الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: حتی ساده‌ترین workflow‌های چندگامی حداقل یک expression نیاز دارند. مثلاً وقتی می‌خواهید از خروجی یک HTTP Request فقط فیلد خاصی را استخراج کنید، باید بنویسید: {{ $json.data.items[0].name }}. این کدنویسی نیست، ولی بدون آشنایی با ساختار آبجکت و آرایه در JavaScript، گیج می‌شوید.

عبارات جاوااسکریپت در n8n (JS Expression) — حداقل‌های لازم#

شما به یک برنامه‌نویس کامل نیاز ندارید. ولی این چهار مفهوم را باید بشناسید:

  • دسترسی به فیلدها با نقطه و براکت: $json.field، $json["field"]
  • متدهای آرایه: map، filter، find — برای تبدیل لیست داده به ساختار مورد نیاز
  • عملگرهای منطقی: ternary (?:) برای شرط‌های ساده در فیلدهای configuration
  • template literal: `متن ${variable}` برای ساخت رشته‌های پویا

هر چیزی بیشتر از این — مثلاً async/await، class یا framework — در n8n لازم نیست. این لیست، حداقل واقعی است نه حداکثر؛ اگر کسی ادعا کرد بدون هیچ‌کدام از این چهار مورد می‌شود workflow چندگامی ساخت، یا سناریوی‌اش تک‌گامی بوده یا هنوز به مرحله‌ی دیباگ نرسیده.

نمونه‌ی عملی: تبدیل تاریخ شمسی به میلادی داخل Code node#

فرض کنید یک webhook از سیستم ایرانی می‌گیرید که تاریخ شمسی می‌فرستد و شما باید در Google Sheets ذخیره‌اش کنید. در Code node سه خط JavaScript کافی است:

import { toJalaali, toGregorian } from "jalaali-js"; const g = toGregorian(jy, jm, jd); return [{ json: { date: `${g.gy}-${g.gm}-${g.gd}` } }];

نکته‌ی مهم: n8n به‌صورت پیش‌فرض jalaali-js را ندارد. باید آن را با npm install داخل container اضافه کنید یا از Code node با require استفاده کنید. tutorials فارسی معمولاً این مرحله را جا می‌اندازند و خواننده در اولین اجرای واقعی با خطای «module not found» مواجه می‌شود.

چه سطحی از کدنویسی کافی است؟#

نه React، نه backend، نه database. فقط array method‌ها و object access. اگر با JSON آشنا باشید و بتوانید یک شیء را باز کنید، بخش عمده‌ی کار n8n را می‌فهمید. آنچه می‌ماند مربوط به درک flow داده بین node‌هاست، نه سینتکس جاوااسکریپت.

نصب self-hosted n8n با Docker: گام‌به‌گام#

سریع‌ترین روش نصب self-hosted، اجرای کانتینر Docker با یک دستور است. ولی مدیریت credentials، امنیت و community nodes چالش‌های واقعی بعدی‌اند. نصب یک‌ساعته تمام است؛ نگهداری، ماه‌ها. تفاوت اصلی با Cloud همینجاست: شما به‌جای پرداخت اشتراک، مسئولیت بکاپ، آپدیت و امنیت را به دوش می‌کشید.

لیست گام‌به‌گام شماره‌دار نصب با Docker#

  1. Docker و Docker Compose را روی سرور نصب کنید. حداقل RAM توصیه‌شده در مستندات n8n: ۲ گیگابایت؛ در عمل برای workflow‌های سنگین با AI، اعضای کامیونیتی ۴ گیگابایت را پیشنهاد می‌دهند.
  2. دستور docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n را اجرا کنید.
  3. بعد از بالا آمدن کانتینر، در مرورگر آدرس http://your-server:5678 را باز کنید.
  4. ایمیل و رمز عبور ادمین را تنظیم کنید. این اولین و تنها بار است که این فرم را می‌بینید.
  5. برای production، N8N_ENCRYPTION_KEY را به‌عنوان متغیر محیطی (Environment Variable) تنظیم کنید. بدون این کلید، credentials شما به‌صورت متن ساده (Plaintext) در database ذخیره می‌شوند.
  6. برای آپدیت، image را pull کنید و container را restart کنید. قبلش حتماً volume n8n_data را بکاپ بگیرید.

مدیریت credentials و امنیت داده‌ها در self-hosted#

اشتباه رایج: قرار دادن کلید API در environment variable بدون encryption. اگر N8N_ENCRYPTION_KEY تنظیم نشده باشد، تمام credentials (شامل token‌های OAuth، API key‌ها و رمزهای عبور) در فایل SQLite به‌صورت خوانا ذخیره می‌شوند. اگر سرور شما compromise شود، همه‌ی این‌ها لو می‌رود.

راه‌حل: کلید encryption را در یک فایل جداگانه با دسترسی ۶۰۰ نگه دارید و در .gitignore قرار دهید. هرگز آن را در docker-compose.yml به‌صورت plaintext تعریف نکنید. این یکی از اشتباهاتی است که در پروژه‌های اعضای کامیونیتی بارها تکرار شده — کسی سرور را روی GitHub public می‌کند و کلیدها با آن می‌روند.

Community nodes: کیفیت متغیر و ریسک‌های واقعی#

الگوی تکرارشونده از پروژه‌های واقعی: یک community node نصب می‌شود، چند ماه کار می‌کند، بعد از یک آپدیت n8n ازکار می‌افتد و توسعه‌دهنده‌ی آن node دیگر پاسخ نمی‌دهد. این الگو در گزارش‌های متعدد اعضای کامیونیتی تکرار شده است.

قبل از نصب هر community node، سه چیز را چک کنید: آخرین تاریخ update، تعداد star در GitHub، و اینکه آیا کسی غیر از توسعه‌دهنده‌ی اصلی به آن مشارکت کرده است. اگر node‌ای فقط یک star و آخرین update شش‌ماهه‌ی قدیمی دارد، در production استفاده نکنید. ریسک سکون (Stagnation) در اکوسیستم community nodes، بزرگ‌ترین تهدید پایداری workflow‌های self-hosted است.

ساخت اولین workflow در n8n: از trigger تا execution#

یک workflow در n8n از سه عنصر ساخته می‌شود: محرک (Trigger)، node‌های پردازش، و اتصال (Connection). مثال عملی: دریافت ایمیل → استخراج داده با AI → ذخیره در Google Sheets → ارسال نوتیفیکیشن Slack. این ساختار سه‌لایه، قلب هر اتوماسیون در n8n است و درک آن، تفاوت بین یک کاربر سطحی و کسی است که واقعاً workflow‌های قابل‌نگهداری می‌سازد.

زنجیره‌ای از بلوک‌های متصل که مسیر جریان کار از محرک تا اجرای نهایی را نشان می‌دهد
هر بلوک یک نود مستقل است که خروجی‌اش ورودی نود بعدی می‌شود

توصیف کامل workflow نمونه با ترتیب نودها#

Workflow نمونه: Email Trigger → AI Extract → Google Sheets → Slack Notification.

  • Email Trigger: نوع trigger را روی IMAP یا Gmail قرار می‌دهید. فیلتر موضوع (Subject Filter) را تنظیم می‌کنید تا فقط ایمیل‌های با موضوع مشخص trigger شوند.
  • AI Extract (AI Agent node): با استفاده از node داخلی AI، از بدنه‌ی ایمیل فیلدهای ساختاریافته استخراج می‌کنید. Prompt را طوری می‌نویسید که خروجی JSON باشد: {"name": "...", "amount": ..., "date": "..."}.
  • Google Sheets: داده‌ی استخراج‌شده را در یک شیت از پیش تعریف‌شده append می‌کنید. Mapping فیلدها را با expression انجام می‌دهید.
  • Slack Notification: یک پیام خلاصه به کانال مشخص ارسال می‌شود. اگر AI Extract خطا داد، این node اجرا نمی‌شود — مگر اینکه مدیریت خطا (Error Handling) اضافه کنید.

بررسی execution log و دیباگ#

هر execution در n8n یک log دارد که ورودی و خروجی هر node را نشان می‌دهد. در Cloud، این لاگ‌ها به‌صورت پیش‌فرض نگه‌داشته می‌شوند. در self-hosted، retention لاگ محدود است و بعد از مدتی پاک می‌شود.

برای workflow‌های چندشاخه (Multi-branch)، لاگ خارجی (مثلاً ELK Stack یا حتی یک database ساده) توصیه می‌شود. اولین قدم دیباگ: node خطا را جدا اجرا کنید (Execute Node) تا ورودی و خروجی دقیقش را ببینید، بدون اینکه کل workflow دوباره اجرا شود. این روش، سریع‌ترین راه شناسایی گلوگاه داده است.

اشتباهات رایج در ساخت workflow#

  • ساخت کل workflow یک‌باره بدون تست تدریجی (Incremental Testing). هر node را جدا اجرا و verify کنید قبل از اتصال به بعدی.
  • فراموش‌کردن error handling روی node‌های حساس. یک HTTP Request بدون retry و timeout، کل workflow را از پا می‌اندازد.
  • اتصال نادرست branch‌ها. وقتی IF node دو خروجی دارد و شما فراموش می‌کنید هر دو را وصل کنید، execution در یک مسیر گیر می‌کند.

n8n Cloud یا Self-hosted؟ هزینه‌ی واقعی هر کدام#

Cloud برای تیم‌های بدون DevOps ارزان‌تر تمام می‌شود چون هزینه‌ی پنهان نگهداری حذف می‌شود. Self-hosted فقط وقتی به‌صرفه است که workflow‌های حساس به داده یا تعداد بالای execution دارید. محاسبه‌ی درست، هزینه‌ی کل مالکیت (Total Cost of Ownership) است، نه فقط هزینه‌ی سرور. و این همان جایی است که tutorials فارسی، Cloud را صرفاً «گران‌تر» معرفی می‌کنند.

جدول مقایسه‌ای: n8n Cloud vs Self-hosted#

معیارn8n CloudSelf-hosted
هزینه‌ی مستقیماشتراک ماهانههزینه‌ی سرور + نگهداری
مدیریت زیرساختبر عهده‌ی n8nبر عهده‌ی شما (بکاپ، آپدیت، مانیتورینگ)
کنترل دادهداده روی سرور n8nداده کاملاً در سرور شما
مقیاس‌پذیریمحدود به پلننامحدود ولی نیاز به queue/worker
امنیتمسئولیت n8nمسئولیت شما (SSL، firewall، encryption)
Community nodesدسترسی محدودهر node‌ای که بخواهید نصب کنید

محدودیت‌های مقیاس‌پذیری n8n#

n8n به‌صورت پیش‌فرض single-process اجرا می‌شود. یعنی اگر workflow‌های هم‌زمان (Concurrent) زیاد دارید، CPU و RAM سرور گلوگاه می‌شود. برای حجم بالای execution، باید حالت صف (Queue Mode) فعال کنید: یک Redis + چند worker process. این پیچیدگی اضافه است و tutorials فارسی اصلاً به آن اشاره نمی‌کنند. اگر کسی بدون درک این محدودیت، n8n را برای حجم بالا توصیه می‌کند، یا خودش در production اجرا نکرده یا سناریوی‌اش تک‌کاربر بوده.

چه زمانی Cloud و چه زمانی Self-hosted؟#

Cloud انتخاب درست است اگر: تیم DevOps ندارید، workflow‌های زیر ۱۰ step دارید، و داده‌ها حساسیت قانونی ندارند. Self-hosted اجباری می‌شود اگر: داده‌های مالی یا بهداشتی در بازی است (GDPR، HIPAA)، تعداد execution روزانه بالاست، یا به community node خاصی نیاز دارید که Cloud آن را ساپورت نمی‌کند.

مقایسه‌ی n8n با Zapier و Make: چه زمانی کدام را انتخاب کنید#

n8n در workflow‌های ۱۰+ step، نیاز به self-host و integrations سفارشی می‌درخشد. Zapier در plug-and-play بودن با صدها SaaS کوچک هنوز جلوتر است. Make مدل قیمت‌گذاری per-operation دارد که برای workflow‌های کم‌تعداد ولی پرتکرار به‌صرفه‌تر است. انتخاب بین این سه، مسئله‌ی «بهتر» نیست؛ مسئله‌ی تطابق با محدودیت‌های فنی و حقوقی پروژه‌ی شماست.

جدول مقایسه‌ای: n8n vs Zapier vs Make vs Power Automate#

معیارn8nZapierMakePower Automate
مدل قیمت‌گذاریper-executionper-taskper-operationper-user/per-flow
Self-hostبلهخیرخیرخیر
کدنویسیJS expression + Code nodeفرم‌محور، کد محدودفرم‌محور + functionفرم‌محور
AI integrationLangChain node داخلیAI actionsAI moduleCopilot + AI Builder
تعداد integration۴۰۰+ داخلی + community۷۰۰۰+۱۵۰۰+۵۰۰+ (عمدتاً Microsoft)
یادگیریمتوسطآسانمتوسطآسان (در اکوسیستم MS)

چه زمانی n8n گزینه‌ی اشتباه است#

اگر workflow شما زیر ۵ step است و فقط به Slack و Google Sheets نیاز دارید، n8n بیش از حد پیچیده است. Google Apps Script رایگان است و همین کار را می‌کند. Zapier هم بدون هیچ تنظیمی وصل می‌شود. n8n را وقتی انتخاب کنید که به کنترل، self-host، یا workflow‌های چندشاخه نیاز دارید. این را بیشتر آموزش‌ها نمی‌گویند چون مخاطب‌شان «کاربر n8n» است نه «کسی که در حال انتخاب ابزار است».

تفاوت مدل قیمت‌گذاری Make (per-operation) با n8n (per-execution)#

در Make، هر عملیات (هر API call) جدا محاسبه می‌شود. یک workflow با ۵ node، پنج operation مصرف می‌کند. در n8n، یک execution (اجرای کامل workflow) محاسبه می‌شود، فارغ از تعداد node‌ها. یعنی workflow‌های طولانی در n8n به‌صرفه‌ترند، ولی workflow‌های کوتاه و پرتکرار در Make ارزان‌تر تمام می‌شوند. در سناریوی مثلاً هزار اجرای روزانه‌ی workflow سه‌node‌ای، تعداد واحدهای محاسبه‌شده در Make سه برابر n8n است؛ هزینه‌ی نهایی به نرخ هر واحد بستگی دارد. اگر روزی صد بار یک workflow پانزده‌node‌ای اجرا می‌کنید، n8n برنده است.

ساخت ایجنت هوش مصنوعی با n8n: واقعیت پشت tutorials#

AI Agent node و LangChain integration در n8n ابزار قدرتمندی هستند، ولی tutorials فقط سناریوی مسیر موفق (Happy Path) نشان می‌دهند. در پروژه‌های واقعی ایجنت بیشتر در tool calling و memory شکست می‌خورد. ادعای «مثل ChatGPT Plugin ساده است» گمراه‌کننده است و همین ادعا، هزینه‌ی آزمون‌وخطای پنهانی برای تیم‌هایی می‌سازد که بدون آمادگی وارد این حوزه می‌شوند.

مفاهیم ضروری قبل از ساخت ایجنت#

سه مفهوم را باید درک کنید، وگرنه ایجنت شما در حالت‌های لبه (Edge Case) شکست می‌خورد:

  • Tool calling: ایجنت باید بداند چه ابزاری را کِی صدا بزند. اگر prompt شما مبهم باشد، ایجنت ابزار را صدا نمی‌زند و صرفاً از دانش مدل پاسخ می‌دهد — که برای داده‌ی realtime بی‌فایده است.
  • Memory: ایجنت به‌صورت stateless اجرا می‌شود مگر اینکه memory type را تنظیم کنید. بدون memory، هر execution مثل اولین بار است و context قبلی را فراموش می‌کند.
  • Chain: ترتیب اجرای ابزارها. اگر ایجنت اول tool A را صدا بزند و بعد tool B، ولی خروجی A برای B لازم باشد و شما این ترتیب را تعریف نکرده باشید، ایجنت خودش حدس می‌زند.

الگوی شکست رایج: ایجنت tool را صدا نمی‌زند#

این خطای n8n نیست؛ خطای prompt engineering است. الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: یک ایجنت ساخته می‌شود با tool database query، ولی در prompt ذکر نمی‌شود که «حتماً قبل از پاسخ، داده را از دیتابیس بگیر». نتیجه: ایجنت از حافظه‌ی مدل پاسخ می‌دهد و داده‌ی قدیمی یا توهم‌آمیز (Hallucinated) برمی‌گرداند.

راه‌حل: در system prompt صریح بنویسید که ایجنت موظف است برای هر درخواست داده، ابزار را صدا بزند. و در output format هم مشخص کنید که پاسخ باید شامل منبع داده باشد. بدون این دو شرط، ایجنت عملاً یک چت‌بات با دسترسی به ابزار است، نه یک ایجنت.

Human-in-the-loop در n8n#

برای ابزارهای حساس (مثلاً حذف رکورد از دیتابیس یا ارسال ایمیل به مشتری)، یک node تأیید انسانی (Human-in-the-Loop) قبل از اجرای ابزار اضافه کنید. در n8n این کار با Wait node + Webhook callback انجام می‌شود. ایجنت منتظر تأیید می‌ماند و بعد از approve شدن، tool را اجرا می‌کند.

نمونه‌ی ایجنت واقعی#

Workflow: دریافت درخواست مشتری از Webhook → ایجنت با tool database query → پاسخ با context قبلی → ذخیره در CRM.

ایجنت در این workflow دو tool دارد: یکی برای query دیتابیس سفارشات و یکی برای جستجوی history مشتری. Memory type روی conversation تنظیم شده تا context مکالمه‌های قبلی حفظ شود. اگر ایجنت نتواند داده را از دیتابیس بگیرد، به‌جای حدس زدن، پیام «نیاز به بررسی انسانی» برمی‌گرداند.

جمع‌بندی عملی: n8n ابزار قدرتمندی است، ولی نه آن‌قدر ساده که tutorials فارسی می‌گویند و نه آن‌قدر پیچیده که بدون آموزش قابل استفاده نباشد. سه چیز را یاد بگیرید — لایسنس واقعی، حداقل JS expression، و الگوی دیباگ در self-hosted — و بیشتر مشکلات حل می‌شود. اگر می‌خواهید ایجنت هوش مصنوعی با n8n بسازید و از آن درآمد داشته باشید، دوره‌ی ساخت AI Agent با n8n در کامیونیتی اسکول دقیقاً همین شکاف‌ها را پوشش می‌دهد.