سرور n8n چیست و چرا برای Self-Hosted به VPS نیاز داریم؟
n8n یک ابزار اتوماسیون Workflow است که میتواند سرویسها، APIها، دیتابیسها، مدلهای هوش مصنوعی و ابزارهای کاری را به هم متصل کند. اگر از نسخه Cloud استفاده کنید، زیرساخت توسط خود n8n مدیریت میشود؛ اما در حالت Self-Hosted میتوانید n8n را روی سرور خودتان اجرا کنید و کنترل بیشتری روی داده، IP، منابع، شبکه، Backup و اتصال سرویسهای داخلی داشته باشید.
عبارتهایی مثل سرور n8n، هاست n8n و n8n روی VPS معمولاً به همین مدل Self-Hosted اشاره دارند؛ یعنی یک سرور لینوکسی که n8n روی آن دائماً فعال است، Webhook دریافت میکند و Workflowها را بدون وابستگی به کامپیوتر شخصی اجرا میکند.
در این آموزش چه میسازیم؟ یک n8n Self-Hosted واقعی روی Ubuntu با Docker Compose، PostgreSQL، دامنه، Nginx، HTTPS، Backup و تنظیمات Production. در ادامه هم Queue Mode، Redis، Worker، امنیت و عیبیابی را بررسی میکنیم.
n8n چیست و چه کاری انجام میدهد؟
n8n یک پلتفرم Workflow Automation است که طبق مستندات رسمی میتواند برنامههایی که API دارند به هم متصل کند، داده را بین آنها جابهجا کند و روی داده پردازش انجام دهد. علاوه بر صدها Integration، ابزارهایی برای HTTP Request، Webhook، Code، دیتابیس، فایل، AI Agent، RAG و MCP هم دارد.
برای مثال با n8n میتوانید این Workflowها را بسازید:
- دریافت فرم سایت و ثبت خودکار در CRM
- ارسال پیام تلگرام بعد از ثبت سفارش
- اتصال WooCommerce به حسابداری یا انبار
- دریافت اطلاعات از API و ذخیره در PostgreSQL
- خلاصهسازی ایمیل با مدل هوش مصنوعی
- ساخت AI Agent با Toolهای مختلف
- اتوماسیون تولید و انتشار محتوا
- اجرای Workflowهای زمانبندیشده بدون روشن بودن کامپیوتر
هاست n8n با سرور n8n چه تفاوتی دارد؟
در بازار ممکن است هر دو عبارت «هاست n8n» و «سرور n8n» استفاده شوند، اما از نظر فنی تفاوت مهمی دارند. n8n برای اجرای پایدار به Process دائمی، دیتابیس، Port داخلی و در بسیاری از سناریوها Docker نیاز دارد. به همین دلیل VPS معمولاً انتخاب منعطفتری از هاست اشتراکی سنتی است.
| نوع سرویس | مناسب n8n؟ | توضیح |
|---|---|---|
| هاست اشتراکی PHP | معمولاً خیر | Process دائمی و Docker معمولاً در دسترس نیست |
| هاست Node.js مدیریتشده | بسته به محدودیت سرویس | باید Persistence، Database و Webhook بررسی شود |
| VPS لینوکس | بله | کنترل کامل روی Docker، DB، Nginx، Backup و شبکه |
| n8n Cloud | بله | زیرساخت توسط n8n مدیریت میشود |
برای n8n چقدر RAM و CPU لازم است؟
n8n برای همه Workflowها مصرف یکسانی ندارد. Workflow سادهای که فقط چند API Call دارد با Workflow پردازش فایل، AI، Browser Automation یا چند هزار Execution در روز قابل مقایسه نیست. بنابراین جدول زیر فقط برای شروع است، نه تضمین ظرفیت.
| نوع استفاده | RAM شروع | CPU شروع | سناریو |
|---|---|---|---|
| تست و شخصی | 2GB | 1 تا 2 vCPU | Workflowهای سبک و کمتعداد |
| کسبوکار کوچک | 4GB | 2 vCPU | PostgreSQL + n8n + Workflow متوسط |
| Workflow سنگین / AI | 8GB+ | 4 vCPU+ | Execution همزمان، فایل، AI، چند سرویس |
| Queue Mode | بسته به Workerها | بسته به Workerها | Main + Redis + PostgreSQL + Worker |
نکته: مصرف RAM را فقط بر اساس خود n8n محاسبه نکنید. PostgreSQL، Redis، Reverse Proxy، Workerها، فایلهای Binary و تعداد Executionهای همزمان هم منابع مصرف میکنند.
پیشنیاز نصب n8n روی VPS
در این راهنما از Ubuntu 24.04، Docker Compose، PostgreSQL و دامنهای مثل n8n.example.com استفاده میکنیم.
قبل از شروع باید داشته باشید:
- VPS لینوکسی با دسترسی sudo
- حداقل 2GB RAM برای محیط سبک
- یک دامنه یا Subdomain
- DNS نوع A که به IP سرور اشاره کند
- Portهای 80 و 443 باز
- Backup قبل از هر Upgrade
مرحله ۱: آمادهسازی Ubuntu
sudo apt update
sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg nginx ufw
Firewall را فعال کنید:
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status
مرحله ۲: نصب Docker و Docker Compose
Docker را از Repository رسمی نصب کنید تا Compose Plugin نیز در دسترس باشد. بعد از نصب وضعیت نسخهها را بررسی کنید:
docker --version
docker compose version
اگر Docker را تازه نصب کردهاید و میخواهید بدون sudo اجرا کنید، User را به گروه Docker اضافه کنید. توجه کنید عضویت در گروه Docker عملاً سطح دسترسی بسیار بالایی روی سرور ایجاد میکند؛ بنابراین فقط برای User مورد اعتماد استفاده شود.
مرحله ۳: ساخت پوشه پروژه n8n
sudo mkdir -p /opt/n8n
sudo chown -R $USER:$USER /opt/n8n
cd /opt/n8n
مرحله ۴: ساخت کلید رمزنگاری n8n
n8n Credentialها را رمزنگاری میکند. در Self-Hosted بهتر است N8N_ENCRYPTION_KEY را خودتان مشخص و در Backup امن نگه دارید. اگر این کلید را بعداً از دست بدهید، بازیابی Credentialهای رمزنگاریشده مشکلساز میشود.
openssl rand -hex 32
خروجی را ذخیره کنید.
مرحله ۵: ساخت فایل .env
nano .env
نمونه:
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
GENERIC_TIMEZONE=Asia/Tehran
TZ=Asia/Tehran
N8N_ENCRYPTION_KEY=YOUR_LONG_RANDOM_KEY
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=CHANGE_THIS_TO_A_LONG_RANDOM_PASSWORD
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=CHANGE_THIS_TO_THE_SAME_PASSWORD
دسترسی فایل را محدود کنید:
chmod 600 .env
چرا WEBHOOK_URL مهم است؟ وقتی n8n پشت Reverse Proxy قرار دارد، باید URL عمومی واقعی Webhook را بداند؛ در غیر این صورت ممکن است Triggerها URL اشتباه تولید کنند. در همین سناریو N8N_PROXY_HOPS=1 به n8n میگوید یک Proxy قابل اعتماد جلوی آن قرار دارد.
مرحله ۶: ساخت Docker Compose با PostgreSQL
فایل زیر را بسازید:
nano compose.yml
محتوا:
services:
postgres:
image: postgres:16-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
depends_on:
postgres:
condition: service_healthy
env_file:
- .env
ports:
- "127.0.0.1:5678:5678"
volumes:
- n8n_data:/home/node/.n8n
volumes:
postgres_data:
n8n_data:
در این تنظیم Port 5678 فقط روی 127.0.0.1 Bind میشود؛ یعنی از اینترنت مستقیماً قابل دسترسی نیست و فقط Nginx به آن وصل میشود.
برای Production نسخه را Pin کنید. استفاده از :latest در مثال آموزشی ساده است، اما برای محیط واقعی بهتر است قبل از Upgrade نسخه مشخص و تستشده n8n را در Compose بنویسید تا Restart ناخواسته باعث جهش نسخه نشود.
مرحله ۷: اجرای n8n
docker compose pull
docker compose up -d
docker compose ps
برای بررسی Log:
docker compose logs -f n8n
از خود سرور تست کنید:
curl -I http://127.0.0.1:5678
مرحله ۸: اتصال دامنه با Nginx
sudo nano /etc/nginx/sites-available/n8n
نمونه:
server {
listen 80;
server_name n8n.example.com;
client_max_body_size 50m;
location / {
proxy_pass http://127.0.0.1:5678;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600;
}
}
فعال کنید:
sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/n8n
sudo nginx -t
sudo systemctl reload nginx
مرحله ۹: فعالسازی SSL
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d n8n.example.com
بعد از موفقیت، آدرس زیر را باز کنید:
https://n8n.example.com
در اولین ورود، حساب Owner بسازید و رمز قوی استفاده کنید.
Webhook در n8n چگونه کار میکند؟
Node وبهوک معمولاً دو URL دارد: Test و Production. URL تست برای زمانی است که Workflow را در Editor به حالت Listen میبرید؛ URL Production زمانی کار میکند که Workflow فعال باشد.
اگر Webhook شما از بیرون کار نمیکند، این موارد را بررسی کنید:
- Workflow فعال باشد.
- دامنه از اینترنت Resolve شود.
- HTTPS معتبر باشد.
WEBHOOK_URLدقیقاً URL عمومی باشد.- Reverse Proxy Headerها را درست ارسال کند.
- Firewall فقط 80/443 را باز داشته باشد.
PostgreSQL چرا بهتر از SQLite است؟
برای تست شخصی میتوان با تنظیمات سادهتر شروع کرد، اما در سرور Production استفاده از PostgreSQL انتخاب مناسبتری است؛ مخصوصاً زمانی که Execution زیاد میشود یا میخواهید Queue Mode راهاندازی کنید.
مزیتهای عملی PostgreSQL:
- مدیریت بهتر بار چند کاربر و چند Worker
- Backup استاندارد با
pg_dump - مناسبتر برای Queue Mode
- تفکیک داده n8n از Container اصلی
Queue Mode در n8n چیست؟
در نصب ساده، همان Process اصلی n8n Workflowها را اجرا میکند. در Queue Mode، Process اصلی Taskها را داخل Queue قرار میدهد و Workerهای جدا آنها را اجرا میکنند. این معماری برای افزایش ظرفیت و مقیاسپذیری کاربرد دارد.
Queue Mode معمولاً به این اجزا نیاز دارد:
- Main n8n Instance
- PostgreSQL
- Redis
- یک یا چند Worker
Environment Variableهای پایه Queue Mode
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
Workerها باید دقیقاً همان N8N_ENCRYPTION_KEY Instance اصلی را داشته باشند، چون Credentialها بین اجزای n8n مشترک هستند.
نمونه Worker در Compose
redis:
image: redis:7-alpine
restart: unless-stopped
n8n-worker:
image: docker.n8n.io/n8nio/n8n:YOUR_PINNED_VERSION
command: worker
restart: unless-stopped
env_file:
- .env
depends_on:
- postgres
- redis
Queue Mode را بیدلیل فعال نکنید. اگر یک VPS و تعداد Workflow محدود دارید، نصب ساده نگهداری آسانتری دارد. Queue Mode زمانی ارزش دارد که Execution همزمان و Worker مستقل واقعاً نیاز باشد.
n8n ایران یا سرور خارج؟
انتخاب محل سرور به Workflow شما بستگی دارد. اگر بخش عمده Workflow با APIهای ایرانی، سایتهای داخلی، CRM سازمانی یا سرویسهای داخل کشور کار میکند، سرور ایران میتواند انتخاب منطقی باشد. اگر بخش اصلی Workflow به سرویسهای خارجی وابسته است، کیفیت مسیر خارجی باید دقیق بررسی شود.
در بعضی سناریوها معماری Hybrid بهتر است: n8n روی سرور خارج و یک سرویس داخلی برای APIهای ایران، یا برعکس. اگر چنین سناریویی دارید، مقاله سرور مجازی خارج برای Agentic AI و n8n Self-Hosted با معماری Hybrid را بخوانید.
n8n برای AI Agent و اتوماسیون هوش مصنوعی
n8n فقط ابزار اتصال API نیست. نسخههای جدید آن بخش Advanced AI، AI Agent، Chat Model، Memory، Vector Store، MCP Client و MCP Server را هم در اکوسیستم خود دارد. بنابراین میتوانید Workflowهایی بسازید که Agent از Toolها استفاده کند، اطلاعات را از دیتابیس برداری بگیرد و خروجی را وارد سیستم کسبوکار کند.
اگر هدفتان ساخت Agent همیشهروشن است، راهنمای پیادهسازی AI Agent روی VPS را هم ببینید.
برای اتوماسیون تولید محتوا نیز مقاله اتوماسیون تولید محتوا با هوش مصنوعی روی VPS مکمل همین موضوع است.
امنسازی n8n Self-Hosted
n8n به Credentialهای حساس دسترسی دارد؛ بنابراین امنیت آن باید جدی گرفته شود.
- Port 5678 را مستقیم روی اینترنت باز نکنید.
- فقط از HTTPS استفاده کنید.
- حساب Owner رمز قوی داشته باشد.
- 2FA را در صورت امکان فعال کنید.
- Credentialها را داخل Workflow متن ساده نگذارید.
- فایل
.envدسترسی 600 داشته باشد. - Community Node ناشناس نصب نکنید.
- Execute Command و Nodeهای پرریسک را فقط در صورت نیاز فعال نگه دارید.
- Docker، OS و n8n را بهصورت برنامهریزیشده آپدیت کنید.
- Backup خارج از همان VPS نگهداری شود.
Security Audit داخلی n8n
n8n ابزار Security Audit دارد که میتواند مواردی مثل Credentialهای بلااستفاده، Nodeهای پرریسک، Webhookهای محافظتنشده و تنظیمات امنیتی ناقص را گزارش کند.
docker compose exec n8n n8n audit
Backup کامل n8n چگونه انجام میشود؟
برای Backup واقعی حداقل سه بخش را نگه دارید:
- PostgreSQL Database
N8N_ENCRYPTION_KEY- Volume یا دادههای موردنیاز n8n و فایلهای Binary
Backup دیتابیس PostgreSQL
docker compose exec -T postgres \
pg_dump -U n8n -d n8n > n8n-db-$(date +%F).sql
فایل Backup را روی همان VPS رها نکنید؛ نسخه دوم را در Storage یا سرور دیگری نگه دارید.
تست Restore
Backupی که Restore آن تست نشده، Backup قابل اعتماد نیست. برای تست در محیط جدا:
cat n8n-db-YYYY-MM-DD.sql | \
docker compose exec -T postgres psql -U n8n -d n8n
Restore را روی Production زنده اجرا نکنید مگر دقیقاً میدانید چه میکنید. Restore میتواند داده فعلی را تغییر دهد. ابتدا روی Instance آزمایشی اعتبار Backup را بررسی کنید.
آپدیت n8n با Docker بدون از دست دادن Workflowها
اگر Volume و PostgreSQL درست نگهداری شوند، Container قابل تعویض است. روند امن Update:
- Backup دیتابیس و Encryption Key.
- Release Note و Breaking Change نسخه مقصد را بخوانید.
- در صورت امکان روی Staging تست کنید.
- نسخه Image را در Compose تغییر دهید.
- Image جدید را Pull کنید.
- Container را بالا بیاورید.
- Log و Workflowهای مهم را تست کنید.
docker compose pull
docker compose up -d
docker compose logs --tail=100 n8n
در نسخههای جدید n8n بعضی تنظیمات و Validationها سختگیرانهتر شدهاند؛ بنابراین Update کورکورانه به latest روی Production توصیه نمیشود.
خطاهای رایج نصب n8n روی VPS
خطای 502 Bad Gateway
معمولاً Nginx به n8n دسترسی ندارد.
docker compose ps
curl -I http://127.0.0.1:5678
sudo nginx -t
sudo tail -n 100 /var/log/nginx/error.log
Webhook آدرس localhost تولید میکند
WEBHOOK_URL را روی URL عمومی HTTPS قرار دهید و Container را Restart کنید:
WEBHOOK_URL=https://n8n.example.com/
Webhook تست کار میکند ولی Production نه
بررسی کنید Workflow واقعاً Active شده باشد و از Production URL استفاده کنید.
PostgreSQL وصل نمیشود
docker compose ps
docker compose logs postgres
docker compose exec postgres pg_isready -U n8n -d n8n
n8n بعد از Restart Credentialها را باز نمیکند
یکی از اولین مواردی که باید بررسی شود تغییر یا از دست رفتن N8N_ENCRYPTION_KEY است. این کلید باید در همه Containerها و Workerهای همان Instance ثابت باشد.
حافظه سرور پر میشود
free -h
docker stats
docker system df
Execution History، فایل Binary، Workflowهای حجیم و Execution همزمان را بررسی کنید. اضافهکردن RAM بدون پیدا کردن علت اصلی همیشه راهحل نیست.
Permission denied روی Volume
ابتدا مسیر و Owner فایلها را بررسی کنید. بهجای اجرای Container با Root، Permission صحیح Volume را تنظیم کنید.
n8n Cloud یا Self-Hosted؛ کدام بهتر است؟
| معیار | n8n Cloud | Self-Hosted VPS |
|---|---|---|
| مدیریت سرور | با n8n | با شما |
| کنترل شبکه | محدودتر | بیشتر |
| Backup زیرساخت | مدیریتشدهتر | مسئولیت شما |
| اتصال سرویس داخلی | وابسته به شبکه | قابل طراحی |
| نگهداری | سادهتر | نیازمند DevOps |
چکلیست Production برای سرور n8n
- PostgreSQL بهجای وابستگی به دیتابیس موقت
- Encryption Key ثابت و Backup شده
- HTTPS معتبر
- Port 5678 فقط روی localhost
- Firewall فعال
- Backup روزانه یا متناسب با اهمیت داده
- Restore آزمایششده
- نسخه n8n Pin شده
- مانیتورینگ RAM، Disk و Container
- بررسی Executionهای Failed
- Security Audit دورهای
- عدم نصب Community Node ناشناس
- Queue Mode فقط در صورت نیاز واقعی
سؤالات متداول درباره سرور n8n
سرور n8n چیست؟
VPS یا سروری است که n8n بهصورت Self-Hosted روی آن اجرا میشود و Workflowها، Webhookها و Automationها را ۲۴ ساعته مدیریت میکند.
آیا n8n روی هاست اشتراکی نصب میشود؟
روی هاست اشتراکی سنتی معمولاً خیر، چون n8n به Runtime دائمی و تنظیمات سروری نیاز دارد. VPS یا سرویس مدیریتشده n8n انتخاب مناسبتری است.
برای n8n چند گیگ RAM لازم است؟
برای استفاده سبک 2GB میتواند نقطه شروع باشد، اما برای PostgreSQL، Workflowهای متعدد و AI بهتر است 4GB یا بیشتر در نظر بگیرید و مصرف واقعی را مانیتور کنید.
آیا n8n به Redis نیاز دارد؟
در نصب ساده خیر. Redis بیشتر در Queue Mode برای توزیع Execution بین Workerها استفاده میشود.
برای n8n PostgreSQL بهتر است یا SQLite؟
برای Production و مخصوصاً Queue Mode، PostgreSQL انتخاب مناسبتری است. SQLite برای تست و استفاده بسیار سبک سادهتر است.
Webhook n8n پشت Nginx چرا کار نمیکند؟
معمولاً WEBHOOK_URL، Proxy Headerها، HTTPS، DNS یا فعال نبودن Workflow مشکل دارد. URL عمومی باید در تنظیمات n8n مشخص باشد.
آیا n8n برای AI Agent مناسب است؟
بله. n8n ابزارهای AI Agent، Chat Model، Memory، Vector Store و MCP دارد و میتواند AI Workflow را با سرویسهای کسبوکار ترکیب کند.
سرور ایران برای n8n بهتر است یا خارج؟
به APIها و سرویسهای Workflow بستگی دارد. برای سرویسهای عمدتاً ایرانی، VPS ایران میتواند مناسب باشد؛ برای وابستگی خارجی سنگین باید کیفیت مسیر خارجی هم بررسی شود.
منابع و مستندات رسمی
جمعبندی
اگر دنبال «سرور n8n» یا «هاست n8n» هستید، برای Self-Hosted معمولاً VPS لینوکسی بهترین انعطاف را میدهد. ترکیب Ubuntu + Docker Compose + PostgreSQL + Nginx + HTTPS برای بسیاری از پروژهها نقطه شروع مناسبی است. در بار بالاتر میتوانید Redis و Worker را با Queue Mode اضافه کنید. مهمتر از نصب اولیه، Backup، Encryption Key، امنیت، Webhook صحیح و Upgrade کنترلشده است؛ چون n8n معمولاً به Credentialهای حساس و سرویسهای حیاتی کسبوکار متصل میشود.
برای انتخاب VPS مناسب n8n مطمئن نیستید؟
تعداد Workflowها، تعداد Execution روزانه، استفاده از AI، حجم فایل و نیاز یا عدم نیاز به Queue Mode تعیین میکند چه منابعی مناسبتر است. قبل از انتخاب پلن میتوانید سناریوی خود را با پشتیبانی ایرانیکاسرور مطرح کنید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467

دیدگاهها (۰)