Cài n8n trên Synology bằng Container Manager: quên Portainer đi, DSM tự lo hết rồi

Vì sao không cần Portainer nữa

Đa số hướng dẫn tiếng Anh về n8n trên Synology, kể cả mấy bài search nhiều nhất, đều bảo cài Portainer trước rồi mới chạy container qua đó. Cách này đúng ở thời DSM 7.1 trở về trước, khi Docker package của Synology còn cùi, không hỗ trợ compose file tử tế.

Từ DSM 7.2, Synology đổi tên package "Docker" thành Container Manager, và điểm khác biệt lớn nhất là nó có luôn tính năng Project — dán thẳng docker-compose.yml vào GUI, không cần công cụ thứ ba chen vào giữa. Cài thêm Portainer lúc này chẳng khác gì rước thêm một ông hàng xóm về ở chung: tự nó cũng đòi update, đòi vá lỗi bảo mật, đòi nhớ mật khẩu đăng nhập riêng — trong khi chẳng làm được việc gì mà Container Manager chưa làm.

Vậy nên bài này đi thẳng theo hướng: Container Manager, tính năng Project, không vòng vo.

Cảnh báo trước khi đọc tiếp: Container Manager chỉ chạy trên NAS nền x86 (Intel/AMD), DSM 7.2 trở lên. Các dòng ARM và entry-level như DS223j, DS224+, DS124... phần lớn không cài được package này. NAS bạn thuộc nhóm đó thì dừng lại ở đây — đọc tiếp chỉ tổ mất thời gian. Model tương thích phổ biến: DS920+, DS923+, DS1522+, DS1621+, DS1821+, và dòng RS/SA.

So sánh nhanh các cách chạy n8n trên NAS

| Cách làm                    | Độ phức tạp | Update                | Overhead     | Phù hợp                  |
| --------------------------- | ----------- | --------------------- | ------------ | ------------------------ |
| Container Manager (Project) | Thấp        | Dễ                    | Không        | Đa số người dùng         |
| Portainer                   | Trung bình  | Phải tự maintain      | +1 container | Ai quản nhiều NAS/server |
| Native (SSH, PM2)           | Cao         | Dễ gãy sau update DSM | Thấp         | Không khuyến nghị        |
| Virtual Machine Manager     | Cao         | Phải vá cả OS khách   | Nặng         | Không cần thiết cho n8n  |

Native package qua SSH không được Synology hỗ trợ chính thức, dính một bản update DSM là có khả năng gãy. VM thì quá tay — cấp riêng vCPU/RAM cho một app Node.js đơn giản là phí tài nguyên. Container Manager thắng vì nhẹ, chính chủ, và không bắt học thêm công cụ nào.

Chuẩn bị trước khi làm

• NAS x86, DSM 7.2 trở lên (kiểm tra ở Control Panel > Info Center)
• Đã cài Container Manager từ Package Center (tìm đúng tên này, không phải "Docker" cũ nữa)
• Một domain DDNS dạng *.synology.me nếu định public ra ngoài — mục này làm sau, LAN test trước đã

Bước 1: Tạo thư mục dữ liệu

Mở File Station, tạo cấu trúc thư mục sau trong docker shared folder:

/volume1/docker/n8n/data
/volume1/docker/n8n/filesdata là nơi n8n lưu workflow, credentials, database SQLite. files là thư mục tuỳ chọn, dùng khi n8n cần đọc/ghi file trực tiếp (resize ảnh, đổi tên file trong một shared folder có sẵn...). Không cần thì bỏ qua, không sao.

Bước 2: Tạo Project trong Container Manager

Vào Container Manager > Project > Create. Đặt tên project (vd n8n), chọn đường dẫn project là /volume1/docker/n8n, rồi chọn "Create docker-compose.yml" và dán nội dung sau:

services:
n8n:
image: docker.n8n.io/n8nio/n8n:1.81.0
container_name: n8n
restart: unless-stopped
ports:
- "5678:5678"
environment:
- GENERIC_TIMEZONE=Asia/Ho_Chi_Minh
- TZ=Asia/Ho_Chi_Minh
- N8N_ENCRYPTION_KEY=doi-thanh-chuoi-random-cua-ban
- N8N_RUNNERS_ENABLED=true
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
volumes:
- /volume1/docker/n8n/data:/home/node/.n8n
- /volume1/docker/n8n/files:/filesVài điểm cần để ý ngay từ compose file này:

• Pin version cụ thể (:1.81.0) thay vì :latest. n8n cập nhật khá nhanh và thỉnh thoảng có breaking change giữa các bản — dùng latest nghĩa là mỗi lần Container Manager tự pull ảnh mới, bạn đang tự nguyện làm chuột bạch.
• Volume mount đúng đường dẫn: container n8n chạy bằng user node, UID 1000, không phải root. Thư mục data của nó nằm ở /home/node/.n8n, không phải /root/.n8n. Đây là lỗi hay gặp nhất — chi tiết cách nhận biết và xử lý ở phần dưới.
• N8N_ENCRYPTION_KEY tự đặt một chuỗi random đủ dài, lưu lại ở chỗ nào đó ngoài NAS (password manager chẳng hạn). Đây là khoá mã hoá toàn bộ credentials n8n lưu — Google account, API key ngân hàng, token Telegram. Mất khoá này thì coi như phải nhập lại từ đầu hết credentials, không có nút "quên mật khẩu" nào cứu được.

Bấm Build/Deploy. Container Manager sẽ pull image và khởi động project.

Bước 3: Chạy thử trong LAN trước

Trước khi động gì tới reverse proxy, mở trình duyệt trong mạng nội bộ, gõ http://<IP-NAS>:5678. Lần đầu truy cập n8n sẽ hiện màn hình setup, yêu cầu tạo tài khoản owner (email, mật khẩu). Làm xong bước này để chắc container chạy ổn, trước khi lo chuyện public ra ngoài.

Bước 4: DDNS và chứng chỉ Let's Encrypt

Vào Control Panel > External Access > DDNS, đăng ký một hostname dạng n8n.tenban.synology.me nếu chưa có. Sau đó vào Control Panel > Security > Certificate, request chứng chỉ Let's Encrypt cho domain này. Nhớ vào Control Panel > Network > Network Interface bật HTTP/2 luôn, vì editor n8n cần độ trễ thấp khi tương tác real-time.

Bước 5: Reverse Proxy — chỗ 90% người bỏ sót WebSocket

Vào Control Panel > Login Portal > Advanced > Reverse Proxy, tạo rule mới:

• Source: Protocol HTTPS, Hostname n8n.tenban.synology.me, Port 443, bật HSTS
• Destination: Protocol HTTP, Hostname localhost, Port 5678

Đến phần Custom Header là chỗ ai cũng dễ lướt qua vì tưởng reverse proxy nào cũng giống nhau: phải thêm header WebSocket (Upgrade và Connection). n8n dùng WebSocket để editor cập nhật trạng thái execution real-time — thiếu header này, trang vẫn load bình thường, đăng nhập vẫn được, nhưng bấm "Execute workflow" là màn hình đứng hình, chẳng thấy log chạy tới đâu. Nhìn cứ như bug to đùng, hoá ra chỉ thiếu đúng 2 dòng header.

Bước 6: Bổ sung WEBHOOK_URL và restart

Quay lại Container Manager, sửa Project, thêm 2 biến môi trường:

N8N_PROXY_HOPS=1
WEBHOOK_URL=https://n8n.tenban.synology.me/Chú ý dấu / ở cuối URL — thiếu nó n8n vẫn chạy nhưng sinh webhook URL sai định dạng. Sau khi sửa biến môi trường, phải rebuild lại project (không chỉ restart container thường) để n8n đọc giá trị mới. Bước này nghe hiển nhiên mà lại là chỗ hay bị bỏ quên nhất: sửa xong env var, tưởng lưu là xong, ai ngờ webhook vẫn trả về localhost:5678 vì n8n chưa hề đọc lại config.

Bước 7: Test từ mạng ngoài thật sự

Đừng test webhook bằng tab ẩn danh trong cùng mạng LAN — vậy chưa chứng minh được gì. Tắt wifi, bật 4G, truy cập domain từ ngoài xem có vào được editor không, tạo một webhook test node rồi gọi thử bằng curl hoặc Postman từ máy khác mạng. Chỉ khi việc này chạy được mới coi là xong.

Bước 8: Bật tự khởi động lại

Trong Container Manager, đảm bảo policy restart của container/project là unless-stopped (đã set trong compose ở trên). Vậy n8n tự sống lại sau khi NAS mất điện hoặc reboot, khỏi phải nhớ vào bật tay.

Lỗi thường gặp và cách xử lý

• Mount nhầm /root/.n8n — container chạy user node UID 1000, không phải root. Mount vào /root/.n8n nhìn có vẻ chạy được lúc đầu, nhưng dữ liệu ghi vào đó sẽ mất khi container restart hoặc update image, vì thư mục thật của n8n là /home/node/.n8n.
• EACCES: permission denied khi ghi file — shared folder Synology thường gán UID từ 1024 trở lên cho user, trong khi container chạy UID 1000. SSH vào NAS, chạy chown -R 1000:1000 /volume1/docker/n8n/data để n8n có quyền ghi.
• Webhook trả về localhost:5678 — thiếu WEBHOOK_URL hoặc N8N_PROXY_HOPS, hoặc đã set nhưng quên rebuild project (xem lại bước 6).
• Editor treo, không thấy log execution chạy real-time — thiếu header WebSocket trong rule Reverse Proxy, xem lại bước 5.
• Schedule Trigger chạy lệch giờ — quên set GENERIC_TIMEZONE và TZ, container mặc định chạy UTC nên lệch 7 tiếng so với giờ Việt Nam.
• Update n8n xong workflow cũ chạy lỗi — do nhảy version quá xa, dính breaking change. Luôn pin version cụ thể, và trước khi đổi tag, backup nguyên thư mục /volume1/docker/n8n/data qua Hyper Backup.

Bảo mật: n8n ôm rất nhiều credentials, đừng chủ quan

n8n là nơi lưu credentials của gần như mọi dịch vụ bạn kết nối vào — tài khoản Google, API ngân hàng, token Telegram, Notion. Tuyệt đối không mở port 5678 thẳng ra internet qua port-forward, luôn đi qua reverse proxy HTTPS như đã làm ở trên.

Chỉ dùng cá nhân thì cân nhắc không public ra internet luôn — dùng Synology VPN Server hoặc Tailscale để vào n8n riêng tư. Ít bề mặt tấn công hơn nhiều so với mở domain công khai cho một app chứa toàn credentials nhạy cảm.

Backup định kỳ cả N8N_ENCRYPTION_KEY lẫn thư mục data qua Hyper Backup. Cái ổ cứng nào rồi cũng có ngày dở chứng, chỉ là nó chọn đúng hôm bạn chưa backup hay không thôi — và với n8n, mất khoá mã hoá nghĩa là mất luôn khả năng đọc lại mọi credentials đã lưu, không cách nào khôi phục. Đừng dùng QuickConnect cho webhook chạy production, độ trễ cao và giới hạn kết nối đồng thời không hợp với workload tự động hoá. Chỉ truy cập từ vài địa điểm cố định thì giới hạn IP qua Firewall của DSM và bật 2FA cho tài khoản Synology luôn thể.

Vọc gì với n8n sau khi cài xong

Cài xong rồi để đó thì phí. Vài use case đáng làm ngay:

• Giám sát backup: dùng Schedule Trigger gọi API hoặc SSH trigger Hyper Backup, sau đó gửi thông báo qua Telegram hoặc Synology Chat báo backup xong hay lỗi — khỏi phải mở DSM kiểm tra tay mỗi ngày.
• Tự động hoá file: mount một shared folder cần xử lý vào container, dùng node đọc/ghi file để tự resize ảnh, đổi tên hàng loạt, hoặc đẩy lên cloud khi có file mới.
• Kết nối và cảnh báo: nối NAS với Google Sheets, Notion, Telegram để nhận cảnh báo khi dung lượng ổ đĩa gần đầy, log SMART bất thường, hoặc nhận webhook từ dịch vụ ngoài rồi xử lý tự động.

NAS chạy 24/7 sẵn rồi. Để n8n làm mấy việc lặp đi lặp lại này thay bạn — vậy mới đáng đồng tiền bát gạo đã bỏ ra mua nó.