最近 n8n 正式推出 v2.0 大版本更新 🚀,這次更新在安全性、穩定性與整體效能上都有明顯提升
同時前端 Web UI 的 Canvas 介面也有一定幅度的視覺與互動變化
如果你想了解完整的官方更新細節,建議直接閱讀 n8n 官方 Blog 👉 Introducing n8n 2.0
n8n Self‑host
n8n 2.0 釋出時,官方依然維持 Self‑host 的彈性,這點對技術使用者來說非常重要 👍
官方也同步持續更新 Docker Image,讓升級流程相對平滑
這篇文章會分享我在升級到 n8n 2.0 之後,實際使用的:
- Docker Compose 架構
- Task Runners 新架構設定
- Redis 搭配使用方式
- Caddy Server 反向代理與 HTTPS 設定
整體目標是:穩定、好維護、安全、設定不複雜
Docker Compose 架構說明
本次的 Docker Compose 主要包含三個核心服務:
- n8n(主節點):
- 負責 Web UI、Webhook 接收、Workflow 管理
- task‑runners(Worker 節點):
- 專門負責執行實際的 workflow 任務
- Redis:
- 作為狀態儲存與跨 workflow / node 的輕量資料存取
這樣的拆分方式,是 n8n 近期引入的新一代執行架構
另外因為我跑 n8n 是自用的小服務,資料庫直接用內建的 SQLite
如果你使用場景是高流量高併發的話,n8n 官方是建議使用 Postgres 資料庫,才不會遇到高併發 SQLite 檔案鎖死的效能瓶頸 ☠️
Docker Compose 範例
services:
n8n:
image: n8nio/n8n
container_name: n8n
restart: always
ports:
- "5678:5678" # Web UI 端口
volumes:
- n8n-data:/home/node/.n8n
depends_on:
n8n-redis:
condition: service_healthy
environment:
# --- 基本設定 & 時區 ---
- GENERIC_TIMEZONE=Asia/Taipei
- TZ=Asia/Taipei
# --- 資料庫維護 (SQLite) ---
- DB_SQLITE_VACUUM_ON_STARTUP=true # 啟動時清理資料庫,用於防止 SQLite 資料庫過大導致效能下降
- DB_SQLITE_POOL_SIZE=1 # 啟用 SQLite WAL 模式效能較高較可靠
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=168 # 保留 168 小時內的執行紀錄,視需求可上下調整
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000 # 最多保留 5000 筆紀錄,視需求可上下調整
# --- 網路與安全 (反向代理設定) ---
# 開啟後,必須透過 HTTPS 存取,否則無法登入,內網 HTTP 使用就設定為 false
- N8N_SECURE_COOKIE=true
- WEBHOOK_URL=https://n8n.example.com/ # 根據自己網域修改,內網無網域這行可以換成內網 IP
- N8N_PROXY_HOPS=1 # 告訴 n8n 前面有一層 Proxy (如 Nginx/Caddy),如內網使用這行可以刪除
- N8N_TRUSTED_PROXIES=0.0.0.0/0 # 信任所有來源的 Proxy 標頭,如內網使用這行可以刪除
# --- 權限與安全性 ---
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
- N8N_GIT_NODE_DISABLE_BARE_REPOS=true
- N8N_BLOCK_ENV_ACCESS_IN_NODE=false # false 代表允許 Node 節點讀取環境變數
# --- Task Runners 設定 ---
# 這是主節點設定,負責派發任務給 task-runners
- N8N_RUNNERS_ENABLED=true
- N8N_RUNNERS_MODE=external # 使用外部 Runner 模式
- N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 # 監聽來自 Docker 內網的連線
- N8N_RUNNERS_AUTH_TOKEN=Your1-awEsome-P0ssWorD # 請務必更改為強密碼
- N8N_NATIVE_PYTHON_RUNNER=true # 啟用 Python 支援
task-runners:
image: n8nio/runners # 如有指定版號,runners 版本需與 n8n 本體對齊
container_name: n8n-runners
restart: always
depends_on:
- n8n
environment:
# --- Task Runners 設定 (Worker 端) ---
# 設定主節點的連線位置 (Docker 內部通訊)
- N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
- N8N_RUNNERS_AUTH_TOKEN=Your1-awEsome-P0ssWorD # 需與上方 n8n 主節點內的一致
- N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=0 # 設定為 0 可避免冷啟動延遲
redis:
image: redis:alpine
container_name: n8n-redis
restart: always
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5
volumes:
- n8n-redis-data:/data
volumes:
n8n-data:
n8n-redis-data:
Task Runners 架構簡介 🧩
Task Runners 是 n8n 近期非常重要的一個架構調整,核心概念是:
將「管理 / 接收請求」與「實際執行任務」完全分離
這樣帶來幾個實際好處:
- 🔐 安全性提升:Workflow 執行環境可被隔離
- 🧯 穩定性提升:單一任務異常不易影響整體系統
- ⚡ 效能與擴充性更好:未來可水平擴充 Runner
對於有一定 workflow 數量或較複雜任務的使用者來說,非常值得啟用
Redis 在這裡的角色
Redis 在我 n8n 架構中主要用途是:
- 快速存取 workflow 執行狀態
- 跨 workflow / node 的簡單資料共享
- 搭配 Code Node 或自訂邏輯使用
如果你有用過我之前分享的 PTT Monitor 新文章通知 - n8n 模版 範例,應該會熟悉這種用法 😉
Caddy Server(反向代理)設定
以下是我實際使用的 Caddyfile 範例:
# 域名請自行修改
https://n8n.example.com {
# 排除 n8n 的 SSE 即時推播路徑
@no-sse {
not path /rest/push*
}
# 僅針對非 SSE 路徑啟用 zstd (更快) 和 gzip 壓縮
encode @no-sse zstd gzip
reverse_proxy 127.0.0.1:5678 {
# 關閉緩衝,讓 n8n 的執行進度條能即時跳動
flush_interval -1
}
header {
# 安全性標頭
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
# 增加參照位址策略,保護使用者隱私
Referrer-Policy "strict-origin-when-cross-origin"
# 隱藏伺服器資訊 (移除 Server: Caddy)
-Server
}
}
為什麼我偏好使用 Caddy? ☁️
我自己在跑這類「小型但長期運作」的服務時,非常偏好 Caddy Server,因為它預設就有以下特性:
🔒 自動處理 Let’s Encrypt SSL 憑證
🔐 合理的 TLS 設定、自動處理 OCSP、現代加密套件
🔄 SSL 憑證更新續期完全自動化
尤其未來(預計 2029 年)SSL 憑證有效期限將縮短到 47 天,幾乎每個月都要更新一次
對這類個人小服務來說,用 Caddy 設定好之後就可以「放著不管」😌,不需要額外寫 cron 或腳本處理續期
當然,如果是更大型或企業級架構,Nginx、HAProxy 等方案依然很值得評估,對個人或中小型服務來說,Caddy 真的是省心好選擇 🖖
