最近 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 主要包含三個核心服務:

  1. n8n(主節點)
    • 負責 Web UI、Webhook 接收、Workflow 管理
  2. task‑runners(Worker 節點)
    • 專門負責執行實際的 workflow 任務
  3. 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 真的是省心好選擇 🖖