AI Automation

Tạo Workflow tự động với n8n trên VPS Linux hiệu quả

BM BizMaC Team Sep 10, 2026 10 phút đọc

Đa số người mới dựng n8n trên VPS đều mắc cùng một lỗi: cài xong, mở trình duyệt, kéo thả vài node, thấy workflow chạy ngon trong lúc mở tab, rồi tắt laptop. Hôm sau mở lại thì job đã đứng từ lúc nào, hoặc dữ liệu từ lần chạy trước còn sót lại làm sai kết quả. Tạo workflow tự động với n8n trên VPS Linux không khó, cái khó là làm nó chạy nền ổn định, báo lỗi khi gãy, và không tự bóp chết VPS sau vài tuần. Bài này đi thẳng vào cách vận hành đó trên Ubuntu 24.04 LTS và Debian 12.

  • n8n nên chạy như một service systemd (hoặc container có restart policy), không phải session SSH đang mở.
  • Mỗi workflow cần Execute Workflow riêng biệt, không dùng chung biến global giữa các job chạy song song.
  • Workflow gãy âm thầm là kẻ thù hàng đầu, luôn bật Error Workflow báo về Telegram hoặc email.
  • VPS chạy automation nên có swap và giới hạn execution timeout, đừng để job treo ăn hết RAM.

Yêu cầu trước khi bắt đầu

Bạn cần một VPS Linux đã cài n8n. Nếu chưa có, bài cách cài n8n trên VPS bằng Docker đi từ số 0. Còn nếu đang cân nhắc cấu hình, xem cấu hình VPS phù hợp để chạy n8n.

  • VPS chạy Ubuntu 24.04 LTS hoặc Debian 12, quyền sudo hoặc root.
  • n8n đã cài (Docker Compose v2 hoặc bản npm). Bài giả định bạn dùng docker compose, không phải docker-compose cũ.
  • Một domain trỏ về VPS nếu bạn cần webhook công khai (đa số workflow automation sẽ cần).
  • Kiến thức cơ bản về systemd, Docker và cách đọc log bằng journalctl.

Vì sao workflow n8n hay gãy trên VPS

Ba nguyên nhân chiếm gần hết các ca mình từng gặp: n8n chạy trong session SSH nên chết theo khi bạn logout; workflow thiếu nhánh xử lý khi node trả lỗi HTTP 4xx/5xx; và dữ liệu tích tụ giữa các lần chạy vì dùng chung một biến hoặc một file tạm. Cả ba đều không phải lỗi của n8n, mà là lỗi vận hành.

Điểm khác biệt giữa "chạy được" và "chạy hiệu quả" nằm ở chỗ bạn có tin tưởng giao cho nó một việc lặp lại hằng ngày mà không cần mở dashboard kiểm tra hay không. Muốn vậy, workflow phải tự chạy nền, tự báo lỗi, và tự giới hạn tài nguyên.

Bước 1 - Chạy n8n như service systemd ổn định

Chạy n8n trong session SSH là sai lầm phổ biến nhất. Khi bạn đóng terminal hoặc mất kết nối, tiến trình bị SIGTERM và workflow đứng giữa đường. Cách đúng là để systemd quản lý.

Trước tiên tạo file service:

sudo nano /etc/systemd/system/n8n.service

Nội dung tối thiểu, giả định n8n cài bằng npm và project data nằm ở /home/n8n/.n8n:

[Unit]
Description=n8n workflow automation
After=network.target

[Service]
Type=simple
User=n8n
WorkingDirectory=/home/n8n
ExecStart=/usr/bin/n8n start
Restart=on-failure
RestartSec=10
Environment=N8N_HOST=n8n.example.com
Environment=N8N_PORT=5678
Environment=N8N_PROTOCOL=https
Environment=N8N_METRICS=true
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Ba dòng đáng chú ý: Restart=on-failure để n8n tự dậy khi crash, N8N_METRICS=true để sau này scrape Prometheus nếu cần, và LimitNOFILE nâng giới hạn file descriptor cho lúc nhiều workflow chạy song song. Nếu bạn dùng Docker thì tương đương là khai báo restart: unless-stopped trong file compose.

Kích hoạt và kiểm tra:

sudo systemctl daemon-reload
sudo systemctl enable --now n8n
systemctl status n8n

Kết quả mong đợi: dòng Active: active (running) và Loaded: ... enabled. Nếu thấy failed, chạy journalctl -u n8n -n 50 --no-pager để xem log khởi động.

Bước 2 - Thiết kế workflow sống sót qua lỗi

Một workflow chạy hiệu quả phải trả lời được câu hỏi: "Khi node thứ ba trả về lỗi, chuyện gì xảy ra với node thứ năm?". Nếu câu trả lời là "nó chạy với dữ liệu rác", bạn đang tạo ra quy trình sản xuất dữ liệu sai.

Với mỗi node có khả năng fail (HTTP Request, database, API bên thứ ba), bật Retry On Fail với 2-3 lần và khoảng chờ tăng dần. Với các node không được phép fail, dùng nhánh Continue On Fail sai chỗ sẽ khiến dữ liệu lệch mà không ai biết.

Ba mẫu xử lý lỗi nên dùng:

  • If node kiểm tra statusCode !== 200 rồi rẽ nhánh cảnh báo. Nhánh này gửi Telegram/Slack, nhánh còn lại mới xử lý dữ liệu.
  • Error Trigger ở workflow riêng, được tham chiếu trong Settings của mỗi workflow. Đây là lưới an toàn cuối cùng.
  • Wait node khi gọi API có rate limit, tránh bị chặn IP giữa chừng.

Kiểm tra workflow có thật sự báo lỗi: chủ động đổi một URL thành sai và chạy thử. Nhánh cảnh báo phải nổ trong vài giây. Nếu không, Error Trigger chưa được gắn đúng.

Bước 3 - Gắn Error Workflow báo lỗi về Telegram

Với sysadmin, job gãy mà không có thông báo là tệ hơn không có job. Mình luôn tạo một workflow riêng tên _error_handler để mọi workflow khác trỏ vào.

Các bước dựng nhanh:

  1. Tạo workflow mới, trigger riêng biệt là Error Trigger.
  2. Thêm node Telegram, cấu hình bot token và chat ID. Nội dung tin nhắn dùng expression:
{{ $json.workflow.name }} lỗi node
{{ $json.execution.lastNodeExecuted }}
ở URL {{ $json.execution.url }}

Sau đó vào từng workflow, mở Settings, phần Error Workflow chọn _error_handler. Làm một lần cho mọi workflow hiện có, và nhớ bật khi tạo workflow mới.

Để chắc chắn bot hoạt động, chạy một workflow cố tình gây lỗi (ví dụ node HTTP gọi một domain không tồn tại). Kết quả mong đợi: tin nhắn Telegram đến trong vòng 5-10 giây.

Bước 4 - Giới hạn tài nguyên để VPS không chết vì 1 workflow

Một workflow lỗi vòng lặp có thể đẩy RAM của VPS từ 40% lên rất cao trong vài phút. Đó là lý do n8n cần hai hàng rào: execution timeout và giới hạn tài nguyên ở container.

Đặt timeout toàn cục bằng biến môi trường:

Environment=N8N_EXECUTIONS_TIMEOUT=300
Environment=N8N_EXECUTIONS_TIMEOUT_MAX=900

Với Docker Compose, giới hạn thêm ở mức container:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    mem_limit: 1500m
    cpus: 1.5
    ports:
      - "5678:5678"

Chạy lại và kiểm tra:

docker compose up -d
docker stats --no-stream n8n

Dòng MEM LIMIT phải hiện 1.5GiB. Nếu thấy RAM container leo sát giới hạn, đó là dấu hiệu bạn cần rà lại workflow có node đọc cả bảng dữ liệu lớn hay không, chứ không phải nâng RAM vội.

Nếu VPS ít RAM, đừng quên cấu hình swap hợp lý. Bài cấu hình swap hợp lý cho VPS RAM thấp đã có công thức theo dung lượng RAM. Đây là lý do nhiều người chọn VPS Linux có NVMe và IPv4 Việt Nam để chạy automation liên tục: ổ NVMe giúp database n8n không bị nghẽn I/O khi nhiều workflow ghi log cùng lúc.

Bước 5 - Chống leak dữ liệu giữa các lần chạy

Đây là lỗi tinh vi nhất và cũng khó phát hiện nhất. Nếu workflow dùng Write Binary File ghi vào một đường dẫn cố định, hoặc ghi vào một bảng chung, dữ liệu lần trước sẽ nằm lại và mở đầu lần sau bằng dữ liệu cũ.

Cách chống, theo thứ tự ưu tiên:

  • Đặt tên file theo execution ID: dùng {{ $execution.id }} trong đường dẫn. Mỗi lần chạy có file riêng, không đè lên nhau.
  • Không dùng biến global trong Code node cho dữ liệu giữa các lần chạy. Mỗi execution có context riêng, đừng cố ghép chúng lại.
  • Dọn dữ liệu tạm định kỳ. Viết một workflow nhỏ chạy mỗi ngày, xóa các file có timestamp quá 7 ngày.

Kiểm tra: chạy workflow hai lần liên tiếp và đối chiếu kết quả đầu ra. Nếu lần hai trùng lặp dữ liệu lần một, bạn đang leak.

Bước 6 - Sao lưu và theo dõi workflow đang chạy

Workflow là tài sản, mất là làm lại từ đầu. Với bản Docker, dữ liệu nằm trong volume, còn encryption key nằm ở biến N8N_ENCRYPTION_KEY. Sao lưu thiếu key thì restore xong credential mở không được.

Backup tối thiểu:

docker exec n8n-db pg_dump -U n8n n8n > /backup/n8n_$(date +%F).sql
tar czf /backup/n8n_data_$(date +%F).tar.gz /var/lib/docker/volumes/n8n_data

Lưu ý cả .n8n/config chứa encryption key. Quy trình đầy đủ nằm ở bài backup n8n đúng cách, đọc kỹ phần key trước khi làm thật.

Về giám sát, mình dùng Uptime Kuma ping endpoint /healthz của n8n mỗi 60 giây và gửi cảnh báo Telegram khi down. Endpoint này trả {"status":"ok"}, nhanh và nhẹ. Nếu muốn theo dõi sâu hơn (số execution, queue size), bật Prometheus metrics như ở Bước 1 và scrape định kỳ.

Xử lý lỗi thường gặp

n8n restart liên tục mỗi vài phút. Thường do cạn RAM hoặc OOM killer. Kiểm tra bằng journalctl -u n8n -n 100 --no-pager, tìm dòng Killed process. Khắc phục: giảm N8N_EXECUTIONS_TIMEOUT, thêm swap, hoặc nâng cấu hình VPS.

Webhook không nhận request dù workflow đang active. Nếu chạy sau reverse proxy, kiểm tra header X-Forwarded-For và biến N8N_PROXY_HOPS. Thiếu N8N_PROXY_HOPS=1 khiến n8n không tin được IP client, đôi lúc chặn luôn webhook.

Workflow chạy chậm bất thường, latency tăng dần. Dấu hiệu database n8n phình to do log execution không được dọn. Đặt EXECUTIONS_DATA_PRUNE=true và EXECUTIONS_DATA_MAX_AGE=168 (giữ 7 ngày), rồi thêm workflow dọn định kỳ.

Câu hỏi thường gặp

n8n có cần chạy bằng Docker không, hay cài npm là đủ?

Cả hai đều chạy tốt. Docker dễ nâng cấp và dễ giới hạn tài nguyên hơn (mem_limit, cpus). Bản npm nhẹ hơn nhưng bạn tự quản version Node.js. Nếu chỉ có một workflow đơn giản, npm cài nhanh gọn; nếu chạy nhiều workflow và muốn rollback nhanh, dùng Docker Compose v2.

VPS 2GB RAM chạy được bao nhiêu workflow n8n?

Khoảng 5-10 workflow nhẹ, chạy tuần tự, mỗi execution vài giây. Con số này tụt nhanh nếu bạn có workflow xử lý file lớn hoặc dữ liệu API nặng. Bật swap và giới hạn mem_limit là cách an toàn để không sập VPS giữa chừng.

Làm sao biết workflow đã chạy mà không ngồi chờ mở dashboard?

Dùng Error Workflow báo lỗi qua Telegram và một node HTTP gửi heartbeat sau khi workflow hoàn tất. Nếu qua một khung giờ dự kiến mà không có heartbeat, đó chính là tín hiệu có vấn đề. Cách này độc lập với việc bạn có mở n8n hay không.

Có nên để n8n chạy queue mode với Redis ngay từ đầu không?

Không, chỉ khi bạn có nhiều workflow dài và cần chạy song song thật. Queue mode thêm Redis và tách worker, kéo theo nhiều thứ phải vận hành. Đa số dự án nhỏ chạy chế độ mặc định là đủ; xem bài queue mode khi nào cần tách worker để quyết định.

Sao lưu n8n tốn bao nhiêu dung lượng VPS?

Tuỳ số credential và dữ liệu execution giữ lại. Nếu bật prune 7 ngày, một VPS chạy vài chục workflow thường chỉ cần vài trăm MB cho backup database. Cộng thêm volume data có thể lên 1-2 GB. Đừng lưu tất cả execution vô thời hạn, vừa tốn ổ vừa chậm truy vấn.

Bài viết liên quan

Lưu ý: Bài viết mang tính tham khảo, tổng hợp kiến thức chung. Mỗi hệ thống, hạ tầng và nhu cầu có đặc thù riêng, nên kiểm thử trong môi trường an toàn và tham vấn kỹ sư trước khi triển khai thực tế.