n8n چیست؟ نصب امن با Docker Compose و PostgreSQL

n8n یک پلتفرم اتوماسیون Workflow با مجوز fair-code است که سرویس‌های دارای API را به هم متصل می‌کند، داده را تغییر می‌دهد و فرایندهای تکراری را با کدنویسی کم یا سفارشی‌سازی کامل اجرا می‌کند. می‌توانید نسخه Cloud را بخرید یا آن را روی زیرساخت خودتان میزبانی کنید. در حالت self-hosted، کنترل بیشتری روی داده و شبکه دارید؛ در مقابل، امنیت، به‌روزرسانی، مانیتورینگ و پشتیبان‌گیری هم مسئولیت شماست.

این راهنما یک نصب آزمایشی با فرمان تک‌خطی نیست. هدف، ساخت پایه‌ای قابل نگه‌داری با Docker Compose، PostgreSQL، HTTPS و فضای ذخیره‌سازی پایدار است. نمونه‌ها برای یک سرور Linux نوشته شده‌اند؛ پیش از استفاده در Production، نسخه Imageها، سیاست شبکه و الزامات سازمان خود را بازبینی کنید.

چرا نصب n8n با Docker اکنون موضوع مهمی است؟

در بررسی رابط واقعی Google Trends ایران در ۹ سپتامبر ۲۰۲۶، میانگین علاقه ۹۰روزه برای n8n برابر ۴۸ بود؛ Zapier عدد ۱ و Make.com داده کافی نداشت. در بازه ۱۲ماهه نیز n8n با میانگین ۵۰ فاصله زیادی با دو گزینه دیگر داشت. نمودار n8n نوسان دارد، اما تقاضای آن در ماه‌های اخیر پایدار مانده و نمی‌توان آن را یک جهش یک‌روزه دانست.

سیگنال مهم‌تر، نیت جست‌وجو است: عبارت n8n docker install در Related Queries بازه ۹۰روزه وضعیت Breakout داشت. پیشنهادهای واقعی Google نیز n8n docker، n8n workflows، n8n automation و n8n ai را نمایش دادند. بنابراین این مقاله بر زیرموضوعی متمرکز است که هم تقاضای عملی دارد و هم در حال رشد است؛ بدون ادعای اغراق‌آمیز درباره «وایرال شدن» کل بازار.

پیش‌نیازهای نصب self-hosted

• یک سرور Linux به‌روز با دسترسی مدیریتی و منابع متناسب با تعداد Workflow و Executionها
• Docker Engine و افزونه Docker Compose از منبع رسمی
• یک دامنه یا زیردامنه مانند automation.example.com با رکورد DNS صحیح
• Reverse Proxy مانند Caddy، Traefik یا Nginx برای TLS و محدودسازی ورودی
• فضای بکاپ مستقل از همان سرور و برنامه آزمون بازیابی
• SMTP یا سرویس ایمیل معتبر برای اعلان‌ها و مدیریت کاربران، در صورت نیاز

پورت n8n را مستقیم روی اینترنت باز نکنید. معماری ساده این راهنما چنین است: اینترنت فقط به Reverse Proxy می‌رسد، Proxy ارتباط HTTPS را خاتمه می‌دهد و درخواست را از شبکه داخلی Compose به n8n می‌فرستد. PostgreSQL نیز هیچ Port عمومی ندارد.

انتخاب روش نصب: Cloud، npm یا Docker

Docker Compose برای Deployment تک‌سرور انتخاب متعادلی است. خود مستندات Docker نیز Compose را برای Production روی یک Host پشتیبانی می‌کند، اما پیشنهاد می‌دهد تنظیمات Production، Restart Policy و شیوه مدیریت Secretها را صریح کنید.

ساخت فایل تنظیمات امن

ابتدا پوشه پروژه را بسازید و سطح دسترسی فایل حاوی Secretها را محدود کنید. فایل .env نباید در Git Commit شود. مقادیر زیر نمونه‌اند؛ همه Placeholderها را با مقدار واقعی و تصادفی جایگزین کنید.

# Generate unique secrets; never copy these placeholders to production.N8N_HOST=automation.example.comN8N_ENCRYPTION_KEY=replace-with-at-least-32-random-bytesPOSTGRES_DB=n8nPOSTGRES_USER=n8nPOSTGRES_PASSWORD=replace-with-a-long-random-passwordGENERIC_TIMEZONE=Asia/Tehran

N8N_ENCRYPTION_KEY را مثل کلید گاوصندوق نگه دارید. n8n از آن برای رمزنگاری Credentialهای ذخیره‌شده استفاده می‌کند. اگر دیتابیس را بازیابی کنید اما این کلید را نداشته باشید، Credentialها قابل استفاده نخواهند بود. کلید را در Secret Manager و بکاپ رمزگذاری‌شده نگه دارید، نه فقط روی دیسک همان سرور.

فایل Docker Compose برای n8n و PostgreSQL

نمونه زیر n8n را فقط روی Loopback میزبان Publish می‌کند تا Reverse Proxy همان سرور به آن دسترسی داشته باشد. دیتابیس فقط در شبکه داخلی Compose است. برای Production بهتر است Tag نسخه n8n را پس از آزمون Pin کنید و ارتقا را خودکار و بدون بازبینی انجام ندهید.

services:  postgres:    image: postgres:17-alpine    restart: unless-stopped    environment:      POSTGRES_DB: ${POSTGRES_DB}      POSTGRES_USER: ${POSTGRES_USER}      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}    volumes:      - postgres_data:/var/lib/postgresql/data    healthcheck:      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]      interval: 10s      timeout: 5s      retries: 10  n8n:    image: docker.n8n.io/n8nio/n8n:latest    restart: unless-stopped    ports:      - "127.0.0.1:5678:5678"    environment:      DB_TYPE: postgresdb      DB_POSTGRESDB_HOST: postgres      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}      DB_POSTGRESDB_USER: ${POSTGRES_USER}      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}      N8N_HOST: ${N8N_HOST}      N8N_PROTOCOL: https      WEBHOOK_URL: https://${N8N_HOST}/      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}      N8N_SECURE_COOKIE: "true"      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}      TZ: ${GENERIC_TIMEZONE}    volumes:      - n8n_data:/home/node/.n8n    depends_on:      postgres:        condition: service_healthyvolumes:  postgres_data:  n8n_data:

در نمونه آموزشی از latest استفاده شده تا مسیر خوانا بماند، اما روی سرور واقعی ابتدا Release Notes را بخوانید، یک نسخه مشخص را در Staging امتحان کنید و سپس همان Tag یا Digest تأییدشده را قرار دهید. Tag متحرک می‌تواند رفتار Deployment را بدون تغییر فایل شما عوض کند.

اجرای اولیه و اتصال Reverse Proxy

قبل از Start، Compose نهایی را Validate کنید. این فرمان متغیرها و Merge را Resolve می‌کند و اشتباه‌های ساختاری را زود نشان می‌دهد؛ خروجی ممکن است Secretهای Resolveشده را نشان دهد، پس آن را در Log عمومی منتشر نکنید.

cp .env.example .envchmod 600 .envdocker compose config --quietdocker compose pulldocker compose up -ddocker compose psdocker compose logs --tail=100 n8n

Reverse Proxy باید درخواست عمومی https://automation.example.com را به http://127.0.0.1:5678 بفرستد، گواهی معتبر داشته باشد و Headerهای Forwarded را درست تنظیم کند. مقدار WEBHOOK_URL باید دقیقاً URL عمومی HTTPS باشد؛ در غیر این صورت Triggerهای Webhook ممکن است آدرس داخلی یا اشتباه تولید کنند.

اولین ورود و کنترل دسترسی

پس از بالا آمدن سرویس، فقط از دامنه HTTPS وارد شوید و حساب Owner را بسازید. رمز عبور یکتا و طولانی انتخاب کنید، در صورت پشتیبانی تنظیمات احراز هویت قوی‌تر را فعال کنید و دسترسی پنل را به کاربران لازم محدود نگه دارید. Credentialهای سرویس‌ها را با کمترین Scope ممکن بسازید؛ یک Token ادمین همه‌کاره، ریسک هر Workflow را چند برابر می‌کند.

ساخت اولین Workflow بدون به خطر انداختن Production

1. یک Trigger زمان‌بندی‌شده یا Manual Trigger بسازید.
2. یک Node کم‌خطر مانند HTTP Request به Endpoint آزمایشی اضافه کنید.
3. داده ورودی و خروجی هر Node را مشاهده و فیلدهای حساس را حذف کنید.
4. Error Workflow و Timeout را پیش از فعال‌سازی تنظیم کنید.
5. Workflow را با داده ساختگی اجرا کنید و سپس Credential محدود Production را متصل کنید.
6. پس از فعال‌سازی، چند Execution اول و نرخ خطا را زیر نظر بگیرید.

Nodeهای اجرای Shell، دسترسی فایل و Community Nodeها سطح خطر بیشتری دارند. n8n یک Security Audit داخلی دارد که Credentialهای بلااستفاده، Webhookهای محافظت‌نشده، تنظیمات امنیتی مفقود و Nodeهای پرریسک را گزارش می‌کند. Audit جایگزین بازبینی انسانی نیست، اما کنترل دوره‌ای خوبی است.

بکاپی که واقعاً قابل بازیابی باشد

وجود Volume به معنی بکاپ نیست. حداقل سه جزء را نگه دارید: Dump سازگار PostgreSQL، داده Volume مربوط به n8n در صورت نیاز و مقدار دقیق N8N_ENCRYPTION_KEY. فایل Compose و نسخه Image نیز باید ثبت شوند تا محیط قابل بازسازی باشد.

mkdir -p backupsdocker compose exec -T postgres pg_dump -U n8n -d n8n -Fc > backups/n8n.dumpdocker compose config --images > backups/images.txtsha256sum backups/n8n.dump > backups/n8n.dump.sha256

این اسکریپت فقط نقطه شروع است: بکاپ را رمزگذاری کنید، به فضای مستقل بفرستید، دوره نگه‌داری تعریف کنید و بازیابی را روی یک محیط جداگانه تمرین کنید. خروجی موفق Cron اثبات نمی‌کند فایل واقعاً قابل Restore است.

به‌روزرسانی n8n با کمترین ریسک

1. Release Notes و Breaking Changeها را بخوانید.
2. از دیتابیس و کلید رمزنگاری بکاپ بگیرید و صحت آن را بررسی کنید.
3. نسخه جدید را با کپی داده در Staging اجرا کنید.
4. Workflowهای حیاتی، Webhookها و Credentialها را Smoke Test کنید.
5. Tag تأییدشده را در Compose قرار دهید و Deployment کنترل‌شده انجام دهید.
6. Log، نرخ خطا و Queue را بررسی کنید و مسیر Rollback داشته باشید.

Docker توصیه می‌کند برای Production تنظیمات مجزا، Restart Policy و شیوه Deployment روشن داشته باشید. اجرای خودکار pull برای هر نسخه جدید، بدون تست سازگاری، نگه‌داری نیست؛ انتقال ریسک به ساعت نامعلوم است.

اشتباه‌های رایج در راه‌اندازی n8n

انتشار مستقیم پورت 5678

Bind کردن 0.0.0.0:5678 پنل را مستقیماً در معرض اینترنت قرار می‌دهد. Port را روی Loopback یا شبکه خصوصی نگه دارید و ورودی را از Proxy دارای HTTPS و سیاست دسترسی عبور دهید.

گم‌کردن Encryption Key

بکاپ دیتابیس بدون کلید رمزنگاری برای Credentialها ناقص است. کلید را در Secret Manager، نسخه پشتیبان رمزگذاری‌شده و فرایند بازیابی مستند نگه دارید.

استفاده از Credential پرقدرت

برای هر اتصال، حساب سرویس جدا و Scope حداقلی بسازید. Workflow دریافت فاکتور نباید مجوز حذف همه فایل‌ها یا مدیریت کاربران را داشته باشد.

نگه‌داری نامحدود Execution Data

Executionها می‌توانند شامل داده شخصی، Payload و فایل باشند و حجم دیتابیس را بالا ببرند. سیاست Pruning و Retention را بر اساس نیاز عیب‌یابی و مقررات حریم خصوصی تنظیم کنید.

اعتماد به هر Community Node

Community Node کدی است که در محیط شما اجرا می‌شود. ناشر، Source، دسترسی و سابقه نگه‌داری را بررسی کنید و Node ناشناخته را فقط برای راحتی نصب نکنید. همان‌طور که Docker هشدار می‌دهد، فایل Compose و وابستگی‌های آن نیز ورودی قابل اجرا و مورد اعتماد محسوب می‌شوند.

چک‌لیست آماده‌سازی Production

• DNS و گواهی TLS معتبر هستند و HTTP به HTTPS هدایت می‌شود.
• پورت n8n و PostgreSQL دسترسی عمومی ندارند.
• کلید رمزنگاری و رمز دیتابیس تصادفی، یکتا و خارج از Git هستند.
• Volumeهای پایدار و بکاپ خارج از سرور وجود دارند.
• بازیابی دیتابیس و Credentialها آزمایش شده است.
• Tag نسخه پس از آزمون Pin شده و مسیر Rollback ثبت است.
• Credentialها کم‌اختیار و برای هر سرویس جدا هستند.
• Security Audit، Log و هشدار خطا دوره‌ای اجرا می‌شوند.
• Retention اجرای Workflow و داده‌های شخصی تعریف شده است.
• مالک هر Workflow و روش توقف اضطراری آن مشخص است.

جمع‌بندی

نصب n8n با Docker Compose ساده است؛ نگه‌داری امن آن به تصمیم‌های بیشتری نیاز دارد. PostgreSQL پایدار، Encryption Key قابل بازیابی، URL عمومی درست، TLS، Credential حداقلی و بکاپ آزموده‌شده تفاوت میان Demo و سرویس قابل اعتماد را می‌سازند. از یک Workflow کم‌خطر شروع کنید، معیار موفقیت و مسیر خطا را بسازید و سپس اتوماسیون را مرحله‌ای گسترش دهید.

اگر در طراحی Workflow از عامل‌های هوش مصنوعی کمک می‌گیرید، مقاله وایب کدینگ چیست؟ از نمونه سریع تا کد امن را بخوانید تا مرز تولید سریع و استقرار قابل اتکا را بهتر مشخص کنید.

برای یادگیری Docker، طراحی API و ساخت اتوماسیون‌های واقعی، دوره‌ها و مسیرهای آموزشی خانه برنامه‌نویسان البرز را بررسی کنید.