نصب n8n روی سرور مجازی — اتوماسیون بدون کدنویسی با کنترل کامل

نصب n8n روی سرور مجازی یعنی برداشتن کارهای تکراری از دوش خودتان: اتوماسیون بدون کد، اما این‌بار روی ماشین خودتان و با داده‌هایی که هیچ‌وقت از دستتان خارج نمی‌شوند. در این راهنما از صفر جلو می‌رویم — اندازه‌ی سرور، فایل Docker Compose، دامنه و SSL، تله‌ی وب‌هوک پشت ریورس‌پراکسی، اولین ورک‌فلوی واقعی، و کاری که n8n اگر رهایش کنید بی‌سروصدا با دیسک سرورتان می‌کند.

n8n چیست و چرا خودتان میزبانش باشید؟

اگر می‌پرسید n8n چیست، کوتاه‌ترین پاسخ این است: جایگزین سلف‌هاست Zapier. ابزاری که با آن ورک‌فلو می‌سازید — «وقتی فلان اتفاق افتاد، این کارها را انجام بده» — با کشیدن و وصل‌کردن گره‌ها (Node) در یک بوم گرافیکی. فهرست رسمی اینتگریشن‌های n8n امروز بیش از دو هزار مدخل دارد (شامل گره‌های ساخته‌ی انجمن): تلگرام، جیمیل، گوگل‌شیت، دیتابیس‌ها، وب‌هوک، مدل‌های زبانی و هر API دلخواه دیگری از طریق گره HTTP Request.

اما چرا به‌جای سرویس ابری آماده، n8n را روی سرور خودتان نصب کنید؟ سه دلیل جدی:

• مالکیت داده: در سرویس ابری، داده‌ی مشتری‌ها و توکن‌های API شما از سرور یک شرکت خارجی عبور می‌کند. در نسخه‌ی سلف‌هاست همه‌چیز روی دیسک خودتان است و کلید رمزنگاری credentialها هم دست خودتان.
• بدون هزینه‌ی پله‌ای: سرویس ابری به ازای هر اجرا محدودیت دارد و ورک‌فلویی که هر پنج دقیقه اجرا شود ماهانه چند هزار اجرا می‌سازد؛ روی سرور خودتان ده اجرا و ده‌هزار اجرا هزینه‌ی یکسانی دارند.
• دسترسی به سرویس‌های داخلی: ابزار ابری خارجی به دیتابیسی که فقط از داخل شبکه‌ی شما در دسترس است راه ندارد؛ n8n روی سرور خودتان هم به آن می‌رسد و هم به هر API عمومی.

یک نکته‌ی صادقانه: رابط n8n فارسی نیست و منابع آموزشی فارسی هم کم‌اند — اما رابط آن‌قدر بصری است که زبان بعد از اولین ورک‌فلو مانع نیست.

لایسنس n8n: چرا گفتن «متن‌باز» دقیق نیست

خیلی از آموزش‌های فارسی n8n را «متن‌باز» معرفی می‌کنند و این دقیق نیست. کد روی گیت‌هاب در دسترس است، اما با لایسنس Sustainable Use License منتشر می‌شود که خودِ n8n آن را زیر مدل fair-code معرفی می‌کند. تفاوت عملی است، نه فلسفی: لایسنس استفاده و تغییر نرم‌افزار را فقط برای «مقاصد داخلی کسب‌وکار خودتان» یا استفاده‌ی شخصی و غیرتجاری مجاز می‌داند، بازتوزیع را فقط رایگان و غیرتجاری، و حذف اعلان‌های کپی‌رایت را ممنوع. یعنی راه‌اندازی n8n روی سرور شرکت خودتان و ساخت ورک‌فلو برای مشتری مجاز است؛ اما میزبانی n8n و فروش دسترسی به آن، یا عرضه‌ی آن با برند خودتان، نه. اگر مدل کسب‌وکارتان «پنل اتوماسیون اشتراکی» است، پیش از سرمایه‌گذاری متن لایسنس را بخوانید.

نکته‌ی دوم درباره‌ی نسخه‌هاست. نسخه‌ی رایگانی که خودتان میزبانی می‌کنید Community edition نام دارد و تقریباً کل قابلیت‌ها را دارد؛ آنچه ندارد مشخص و مستند است: SSO، کنترل نسخه با Git، پروژه‌ها و نقش‌های دسترسی، متغیرهای سفارشی، استریم لاگ و حالت multi-main. در مقابل صفحه‌ی مقایسه‌ی نسخه‌ها تصریح می‌کند که حالت صف (queue mode) در نسخه‌ی رایگان هست. با ثبت ایمیل هم کلیدی رایگان می‌گیرید که پوشه‌بندی ورک‌فلوها و دیباگ در ویرایشگر را باز می‌کند.

سرور n8n چقدر رم و پردازنده لازم دارد؟

خبر خوب: هسته‌ی n8n سبک است. مستندات رسمی برای یک نمونه بازه‌ی ۳۲۰ مگابایت تا ۲ گیگابایت رم و ۵۱۲ مگابایت تا ۴ گیگابایت دیسک دیتابیس را اعلام می‌کند و می‌گوید n8n پردازنده‌بر نیست؛ نمونه‌ی بی‌کار حدود ۱۰۰ مگابایت رم می‌گیرد. مصرف واقعی را حجم داده‌ای که هر اجرا در حافظه نگه می‌دارد تعیین می‌کند.

دیسک NVMe اینجا مهم‌تر از آن است که به‌نظر می‌رسد: هم SQLite و هم PostgreSQL برای هر اجرا رکورد می‌نویسند و تأخیر نوشتن مستقیماً روی زمان هر اجرا می‌نشیند. سرورهای ابری مهران هاست از نوع KVM با دیسک NVMe در دیتاسنتر داخل ایران‌اند.

نصب n8n روی سرور مجازی با Docker Compose

تمیزترین روش نصب n8n روی سرور، داکر است: نه وابستگی Node.js لازم دارید، نه دردسر آپدیت. اگر داکر نصب نیست، اول راهنمای نصب داکر روی سرور ابری را ببینید — همان‌جا گفته‌ایم که روی سرور ایران هم گام نصب و هم اولین docker pull به خطای ۴۰۳ می‌خورند و راه رد کردن هرکدام فرق دارد. حالا فایل compose.yaml را بسازید:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=Asia/Tehran
      - TZ=Asia/Tehran
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

بالا بیاورید:

docker compose up -d
docker compose logs -f n8n

n8n ready on ::, port 5678
Version: 2.38.1
Editor is now accessible via:
https://n8n.example.com

چند تصمیم در این فایل گرفته شده است. پورت 5678 — پیش‌فرض n8n — فقط روی 127.0.0.1 باز شده تا از اینترنت در دسترس نباشد. داده‌ها — ورک‌فلوها، credentialها، تاریخچه‌ی اجراها و کلید رمزنگاری — در volume به نام n8n_data روی مسیر /home/node/.n8n می‌نشینند تا با آپدیت کانتینر از بین نروند. و دو متغیر زمان: TZ ساعت سیستم کانتینر را می‌گذارد و GENERIC_TIMEZONE ساعتی است که گره‌هایی مثل Schedule Trigger با آن کار می‌کنند.

راه یک‌خطی، و خبری که باید بدانید

اگر نمی‌خواهید فایل بنویسید، n8n یک اسکریپت نصب رسمی دارد که داکر را بررسی می‌کند، فایل‌های پیکربندی را می‌سازد و سرویس را بالا می‌آورد:

curl -fsSL https://get.n8n.io | sh

این روش استکی کامل‌تر (شامل سندباکس دستیار هوش مصنوعی) بالا می‌آورد؛ برای سروری که خودتان کنترلش می‌کنید همان compose شفاف‌تر است. خبر مهم‌تر: نصب با npm در حال بازنشستگی است — مستندات رسمی اعلام کرده‌اند از نسخه‌ی ۳، n8n فقط از طریق داکر توزیع می‌شود.

اولین ورود، حساب مالک و متغیرهای منسوخ

در اولین ورود به رابط وب، n8n از شما می‌خواهد حساب مالک (Owner) بسازید؛ مدیریت کاربر داخلی است و متغیرهای قدیمی N8N_BASIC_AUTH_* از نسخه‌ی ۱ حذف شده‌اند. N8N_RUNNERS_ENABLED هم داستان مشابهی دارد: روی شاخه‌ی ۱ باید true می‌گذاشتیدش، اما از نسخه‌ی ۲ منسوخ شده. رمز حساب مالک را قوی انتخاب کنید؛ هرکس وارد شود، به همه‌ی توکن‌ها و ورک‌فلوهایتان دسترسی دارد.

اتصال دامنه: Nginx، وب‌سوکت و گواهی SSL

یک ساب‌دامین مثل n8n.example.com را با رکورد A به IP سرور وصل کنید — اگر با رکوردها راحت نیستید آموزش رکوردهای DNS را ببینید (کمترین TTL در پنل DNS مهران هاست ۶۰ ثانیه است). سپس در Nginx یک reverse proxy تعریف کنید:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

دو خط Upgrade و Connection حیاتی‌اند: رابط n8n از WebSocket استفاده می‌کند و مستند وب‌سوکت Nginx توضیح می‌دهد چرا این دو هدر «هاپ‌به‌هاپ»اند و باید صریحاً پاس داده شوند؛ بدون آن‌ها صفحه لود می‌شود ولی وضعیت اجراها زنده به‌روز نمی‌شود. بلوک map هم بی‌دلیل نیست: مقدار ثابت "upgrade" روی درخواست‌های معمولی هم فرستاده می‌شود، اما این نگاشت فقط وقتی آن را می‌فرستد که مرورگر واقعاً درخواست ارتقا داده باشد.

عدد proxy_read_timeout هم انتخابی نیست: پیش‌فرض Nginx ۶۰ ثانیه است و اگر بک‌اند در این مدت چیزی نفرستد اتصال بسته می‌شود. و یک تغییر تازه: از نسخه‌ی 1.29.7 که فروردین ۱۴۰۵ منتشر شد، پیش‌فرض proxy_http_version خودِ 1.1 است؛ روی نسخه‌های قدیمی‌تر باید خط proxy_http_version 1.1; را هم اضافه کنید وگرنه وب‌سوکت برقرار نمی‌شود.

گواهی رایگان بگیرید:

certbot --nginx -d n8n.example.com

مسیر صدور و تمدید خودکار در نصب گواهی SSL رایگان با Certbot آمده است. بعد از SSL فایروال را مرتب کنید — فقط پورت‌های ۲۲، ۸۰ و ۴۴۳ باز باشند؛ چک‌لیست کامل در ۱۰ قدم امنیت سرور لینوکس است. پورت ۵۶۷۸ نباید در این فهرست باشد: تنها راه ورود از بیرون، Nginx است.

چرا وب‌هوک پشت ریورس‌پراکسی خراب می‌شود؟

رایج‌ترین شکست تازه‌واردها این است: رابط باز می‌شود، اما آدرس وب‌هوکی که n8n نشان می‌دهد http://localhost:5678/webhook/… است و سرویس بیرونی هرگز چیزی نمی‌فرستد. n8n این آدرس را از ترکیب N8N_PROTOCOL و N8N_HOST و N8N_PORT می‌سازد که پیش‌فرضشان http، localhost و 5678 است: پشت پراکسی، n8n روی ۵۶۷۸ گوش می‌دهد ولی دنیا آن را روی ۴۴۳ می‌بیند.

مستند رسمی وب‌هوک پشت ریورس‌پراکسی سه کار را لازم می‌داند و هر سه در compose و بلوک Nginx بالا انجام شده‌اند: تعیین دستی آدرس با N8N_WEBHOOK_URL، تنظیم N8N_PROXY_HOPS روی تعداد پراکسی‌های مسیر (اینجا ۱، پیش‌فرضش صفر است)، و پاس‌دادن هدرهای X-Forwarded-For و X-Forwarded-Host و X-Forwarded-Proto.

یک تله‌ی نام‌گذاری هم اینجاست: متغیر قدیمی WEBHOOK_URL از نسخه‌ی 2.35 منسوخ شده و جایش را N8N_WEBHOOK_URL گرفته است. نسخه‌های فعلی هنوز نام قدیمی را می‌پذیرند اما هشدار منسوخ‌شدن در لاگ می‌نویسند. و اگر جلوی Nginx لایه‌ی دیگری هم دارید — مثلاً نود لبه‌ی CDN که در پنل با یک کلید کنار رکورد A روشن می‌شود — تعداد hopها یکی بیشتر می‌شود و مسیر وب‌هوک نباید در هیچ قانون ریدایرکتی گیر کند.

اولین ورک‌فلو: هشدار تلگرامی وقتی سایت از دسترس خارج می‌شود

کاربردی‌ترین نمونه برای صاحب یک سرور: هر پنج دقیقه سایت را صدا بزن و اگر جواب نداد، در تلگرام خبرم کن.

۱. ربات و شناسه‌ی چت

در تلگرام به BotFather پیام بدهید، با /newbot یک ربات بسازید و توکن را کپی کنید. سپس یک پیام به ربات بدهید و شناسه‌ی چت را از خروجی متد getUpdates بردارید؛ طبق مستندات Bot API همه‌ی فراخوانی‌ها روی HTTPS و با این قالب انجام می‌شوند:

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates"

{"ok":true,"result":[{"update_id":874250,
  "message":{"message_id":3,"from":{"id":123456789,"is_bot":false},
  "chat":{"id":123456789,"type":"private"},"text":"/start"}}]}

عدد chat.id همان چیزی است که گره تلگرام می‌خواهد. یک واقعیت شبکه‌ای را هم پیش از استقرار روشن کنید: ربات باید از خودِ سرور به api.telegram.org برسد و این مسیر در شبکه‌های مختلف یکسان نیست. به‌جای حدس، تست بگیرید:

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://api.telegram.org
200

۲. ورک‌فلوی پایش

در n8n یک ورک‌فلو با دو گره بسازید: گره اول Schedule Trigger با بازه‌ی هر پنج دقیقه (چون GENERIC_TIMEZONE را تهران گذاشته‌ایم، ساعت‌ها محلی‌اند) و گره دوم HTTP Request با متد GET روی آدرس سایتتان. همین؛ اگر سایت بالا باشد اجرا سبز تمام می‌شود.

۳. ورک‌فلوی خطا که پیام را می‌فرستد

حالا الگوی رسمی n8n برای هشدار را به کار می‌گیریم: ورک‌فلوی جداگانه‌ای بسازید که گره اولش Error Trigger و گره دومش Telegram → Send Message باشد؛ اسمش را Error Handler بگذارید. سپس در تنظیمات ورک‌فلوی پایش، همین را به‌عنوان Error workflow انتخاب کنید. از این پس هر بار اجرای پایش شکست بخورد، گره Error Trigger این داده را دریافت می‌کند:

[{
  "execution": {
    "id": "231",
    "url": "https://n8n.example.com/execution/231",
    "error": { "message": "Example Error Message", "stack": "Stacktrace" },
    "lastNodeExecuted": "Node With Error",
    "mode": "manual"
  },
  "workflow": { "id": "1", "name": "Example Workflow" }
}]

در متن پیام تلگرام به همین فیلدها ارجاع بدهید تا پیامی برسد که نام ورک‌فلو، متن خطا و لینک مستقیم اجرا را دارد. مزیت این الگو این است که یک ورک‌فلوی خطا را برای ده‌ها ورک‌فلوی دیگر هم می‌شود انتخاب کرد.

همین اسکلت (تریگر ← پردازش ← اقدام) ستون فقرات بیشتر ورک‌فلوهاست: فرم سایت به گوگل‌شیت، پایش قیمت، اعلان ثبت سفارش.

تاریخچه‌ی اجراها چقدر دیسک می‌گیرد و کِی سراغ PostgreSQL برویم؟

n8n برای هر اجرا داده ذخیره می‌کند و این داده روی دیسک جمع می‌شود. برخلاف چیزی که در آموزش‌های قدیمی می‌بینید، پاک‌سازی خودکار پیش‌فرض روشن است: EXECUTIONS_DATA_PRUNE پیش‌فرض true است، EXECUTIONS_DATA_MAX_AGE برابر ۳۳۶ ساعت (دو هفته) و EXECUTIONS_DATA_PRUNE_MAX_COUNT برابر ۱۰٬۰۰۰ اجرا. اگر دیسکتان کوچک است یا ورک‌فلوهای پرتکرار دارید، این دو عدد را پایین بیاورید:

      - EXECUTIONS_DATA_MAX_AGE=168
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=2000

دو تنظیم دیگر هم ارزش دانستن دارند و هر دو پیش‌فرضشان -1 یعنی «بی‌نهایت» است: EXECUTIONS_TIMEOUT که نبودش یعنی یک ورک‌فلوی گیرکرده تا ابد منابع می‌گیرد، و N8N_CONCURRENCY_PRODUCTION_LIMIT که روی سرور کوچک، محدودکردنش جلوی هم‌زمانی‌ای را می‌گیرد که رم را تمام می‌کند.

درباره‌ی دیتابیس: پیش‌فرض SQLite است و برای کار شخصی کاملاً بس، مخصوصاً روی NVMe. سراغ PostgreSQL وقتی بروید که چند کاربر هم‌زمان کار می‌کنند یا ورک‌فلوها شبانه‌روزی اجرا می‌شوند. یک هشدار مهاجرت: پس از تغییر DB_TYPE، n8n روی دیتابیس تازه از صفر شروع می‌کند و داده‌های SQLite خودبه‌خود منتقل نمی‌شوند — این مسیر برای نصب تازه است، نه ارتقای درجا. مرحله‌ی بعدی مقیاس هم حالت صف است که به Redis نیاز دارد.

بکاپ و آپدیت n8n بدون از دست دادن credentialها

سه چیز است که اگر از دست بروند بازگرداندن n8n دردناک می‌شود: فایل دیتابیس، کلید رمزنگاری و خودِ فایل compose. بکاپ سالم یعنی کانتینر را متوقف کنید تا فایل SQLite وسط نوشتن گرفته نشود، از volume آرشیو بگیرید و دوباره بالا بیاورید. یک تله: Compose نام volume را با نام پوشه‌ی پروژه پیشوند می‌زند، پس اول نام واقعی را پیدا کنید وگرنه از یک volume خالیِ تازه‌ساخته بکاپ می‌گیرید:

docker compose down
docker volume ls --format '{{.Name}}' | grep n8n_data
n8n_n8n_data

docker run --rm -v n8n_n8n_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/n8n-$(date +%F).tar.gz -C /data .
docker compose up -d

ls -lh n8n-2026-09-08.tar.gz
-rw-r--r-- 1 root root 4.6M Sep  8 09:12 n8n-2026-09-08.tar.gz

این آرشیو را روی همان سرور نگه ندارید؛ قانون ۳-۲-۱ در آموزش بکاپ‌گیری از سرور لینوکس آمده است. آپدیت هم سه دستور است و چون داده در volume می‌ماند، کانتینر تازه همان ورک‌فلوها را می‌بیند:

docker compose pull
docker compose down
docker compose up -d

پیش از هر آپدیت بکاپ بگیرید و بعد از بالا آمدن، سلامت نمونه را بررسی کنید. n8n دو نقطه دارد: /healthz فقط می‌گوید سرویس در دسترس است و /healthz/readiness وقتی ۲۰۰ می‌دهد که دیتابیس هم متصل و مهاجرت‌شده باشد:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:5678/healthz/readiness
200

n8n را روی سرور ایران بگذاریم یا خارج؟

این به آن بستگی دارد که ورک‌فلوهایتان با چه چیزی حرف می‌زنند و باید قبل از خرید سرور جوابش را بدانید. اگر n8n قرار است سراغ سرویس‌های داخلی برود — دیتابیس روی سرور دیگرتان، درگاه پرداخت، پنل پیامک، API فروشگاه خودتان — سرور داخل ایران هم سریع‌تر است و هم پایدارتر. اگر ورک‌فلوها به سرویس‌هایی وصل می‌شوند که به آی‌پی ایران پاسخ نمی‌دهند، سرور خارج انتخاب درست است؛ سرورهای خارج مهران هاست در دیتاسنترهای هتزنر با پرداخت ریالی از همان کیف پول ارائه می‌شوند و مقایسه‌ی کامل در راهنمای خرید سرور مجازی خارج از کشور آمده است. تصمیم را هم حدسی نگیرید: هر سرویسی را که ورک‌فلوها صدا می‌زنند، با همان تست ساده‌ای که بالا برای api.telegram.org زدیم امتحان کنید.

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

n8n بالا آمد ولی کار نمی‌کند؟ جدول عیب‌یابی

بعد از نصب n8n چه کار کنیم؟

نصب n8n روی سرور مجازی همین بود: یک فایل compose، یک بلوک Nginx، یک گواهی SSL و چند متغیر که تفاوتشان را حالا می‌دانید. یک سرور ساعتی بسازید و اولین ورک‌فلویتان را امروز فعال کنید — و چون n8n خانه‌ی توکن‌های شماست، بکاپ و چک‌لیست امنیتی را روز اول انجام دهید، نه روز بد.

سؤالات پرتکرار

برای نصب n8n روی سرور مجازی چه مشخصاتی لازم است؟

یک سرور با ۱ گیگابایت رم و ۱ هسته پردازنده برای شروع و ورک‌فلوهای شخصی کافی است؛ مستندات رسمی برای یک نمونه‌ی n8n بازه‌ی ۳۲۰ مگابایت تا ۲ گیگابایت رم را اعلام می‌کند و برای استفاده‌ی تیمی، ۲ گیگابایت انتخاب امن‌تری است. مصرف واقعی را حجم داده‌ای تعیین می‌کند که هر اجرا در حافظه نگه می‌دارد، نه تعداد ورک‌فلوها.

آیا n8n نرم‌افزار متن‌باز و رایگان است؟

کد n8n در دسترس عموم است اما لایسنس آن Sustainable Use License است که زیر مدل fair-code تعریف می‌شود، نه لایسنس متن‌باز متعارف. استفاده برای مقاصد داخلی کسب‌وکار خودتان و ارائه‌ی مشاوره و ساخت ورک‌فلو برای دیگران مجاز است؛ آنچه اجازه ندارید میزبانی n8n و فروش دسترسی به آن یا عرضه‌ی آن با برند خودتان است. نسخه‌ی Community رایگان است و تقریباً همه‌ی قابلیت‌ها را دارد.

چرا آدرس وب‌هوک n8n به سرویس‌های بیرونی جواب نمی‌دهد؟

چون n8n آدرس وب‌هوک را از ترکیب سه متغیر N8N_PROTOCOL و N8N_HOST و N8N_PORT می‌سازد و پیش‌فرض آن‌ها به آدرس محلی و پورت ۵۶۷۸ اشاره می‌کند. پشت ریورس‌پراکسی باید آدرس عمومی را با متغیر N8N_WEBHOOK_URL صریحاً تعیین کنید، مقدار N8N_PROXY_HOPS را برابر تعداد پراکسی‌های مسیر بگذارید و هدرهای X-Forwarded-Proto و X-Forwarded-Host را از پراکسی پاس بدهید.

اگر سرور n8n را پاک کنم، ورک‌فلوها و credentialها برمی‌گردند؟

ورک‌فلوها و credentialها در پوشه‌ی /home/node/.n8n داخل volume داکر ذخیره می‌شوند و تا وقتی این volume سالم باشد، حذف و ساخت دوباره‌ی کانتینر مشکلی ایجاد نمی‌کند. اما credentialها با کلیدی رمز شده‌اند که در همان پوشه است؛ اگر volume از بین برود، n8n کلید تازه می‌سازد و رمزگشایی نسخه‌های قبلی ممکن نیست. پس بکاپ از این پوشه اجباری است، نه اختیاری.

تاریخچه‌ی اجراهای n8n دیسک را پر می‌کند؟

پاک‌سازی خودکار به‌طور پیش‌فرض روشن است: n8n اجراهای قدیمی‌تر از ۳۳۶ ساعت را حذف می‌کند و سقف نگهداری را روی ۱۰٬۰۰۰ اجرا می‌گذارد. برای سرورهای کوچک یا ورک‌فلوهای پرتکرار، این دو عدد را با متغیرهای EXECUTIONS_DATA_MAX_AGE و EXECUTIONS_DATA_PRUNE_MAX_COUNT پایین بیاورید. ذخیره‌نکردن داده‌ی اجراهای موفق هم گزینه‌ای هست، اما عیب‌یابی را سخت می‌کند و بهتر است آخرین راه باشد.