底層架構好奇者向

誰該看這篇（多數人可以直接跳過）

如果你只是想用 Woow n8n 拉幾條 workflow 幫自己自動化，這篇你不用看。第 1 章已經給你「n8n 是什麼」的白話版；第 13 章教你 credentials；第 17 章教你錯誤處理。用起來就夠了。

這篇是寫給這幾種人的：

• 想幫公司評估「要不要改用 n8n Cloud」的人——需要知道自架 vs Cloud 的界線在哪。
• 想升 Enterprise 版的決策者——需要知道花錢買到的到底是什麼功能。
• 被叫去救 n8n 的 IT／DevOps——n8n 掛了、DB 爆了、想升級——需要知道每個 process 在做什麼、資料放哪、怎麼 backup。
• 想自己在家 self-host 一個 n8n 玩玩的技術控——需要知道 Docker 跑起來之後底下發生什麼。

Community vs Cloud vs Enterprise 三個版本

n8n 官方目前有三種版本，功能差別如下——這張表決定你要不要花錢：

Woow n8n 走的是哪個版本

Woow 內部的 n8n（n8n.woowtech.io）是 self-hosted Community 版——放在公司自己的 server 上，用 Docker 跑，Cloudflare tunnel 對外。

• 好處：免費、資料完全在公司內、想改什麼設定都能改、想開什麼實驗性 flag 就開。
• 代價：沒 SSO（現在用內建帳號密碼）、沒 audit log、升級要 IT 手動做、Fault 要自己 debug。
• 是否有 Enterprise license：依 Woow 目前規模與需求變動——想確認請直接問 IT。有 Enterprise 就會多出 SSO / RBAC / 環境切換等功能。

主要 process 架構：main / worker / webhook

n8n 跑起來時，底下不是「一個大程式」——它可以拆成不同角色的 process。這是為什麼可以 scale。

預設情況（Regular mode）下只有一個 main process，它一個人做完全部事情——UI、API、排程、執行 workflow、收 webhook。小型部署（<50 workflow、每天 <1000 executions）這樣就夠。

當你 workflow 變多、有某條 workflow 跑很久卡住整台，就該考慮切成 Queue mode（詳見下面 §Queue mode）：main process 只負責 UI 與排程調度，實際跑 workflow 交給 worker，webhook 接收拆給 webhook process。三種角色各自可以 horizontal scale。

資料庫選擇：SQLite / Postgres / MySQL

n8n 需要一個 DB 來存 workflow、credentials、executions。三種 DB 都支援：

設定 DB 靠環境變數：

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres.internal
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_user
DB_POSTGRESDB_PASSWORD=***

重要資料存在哪裡

知道資料放哪，你 backup、restore、debug 才有頭緒。以下是 n8n 主要資料的位置：

Executions 資料膨脹：不管會塞爆 DB

每次 workflow 跑一次就產生一筆 execution_entity——加上每個節點的 input / output 資料，一次執行可能就是幾百 KB。跑幾個月你的 DB 會膨脹到讓你嚇到。

第 17 章提過 EXECUTIONS_DATA_MAX_AGE，這裡把整組 pruning 環境變數列出來：

還可以在單一 workflow 的 Settings 裡蓋掉全域設定——例：某條每分鐘跑的 workflow 就設「成功不存 data」，只有錯誤才留紀錄，省超多空間。

Queue mode：進階 scaling

當你 workflow 越來越多、有某條 workflow 一跑就 5 分鐘、其他 workflow 都被卡——你就需要 Queue mode。

Queue mode 做了什麼

1. Main process 只負責 UI 與排程

   不再自己跑 workflow，改成把「要跑什麼」丟到 Redis queue。

2. Worker process 從 queue 拿工作、實際跑 workflow

   可以開 N 個 worker，工作會自動分配。一個 worker 跑久沒關係，其他 worker 繼續拿新工作。

3. Webhook process（可選）專門收 webhook

   把 webhook 從 main 拆出來，避免 UI 慢的時候 webhook 也慢。

開啟 Queue mode 需要什麼

• Redis（當 queue broker）——另外裝一台或用 managed。
• Postgres——SQLite 不能 shared，多個 worker 讀不到同一份資料。
• 環境變數：

# main
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis.internal
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
# ... 其他 DB 設定

# worker（另一個 container / process）
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis.internal
# ... 同樣的 DB 與 Redis 設定
# 啟動指令：n8n worker

Backup 與 restore 策略

n8n 的 backup 有三個層次，一起 backup 才算完整：

Restore 的正確順序

1. 先停掉 n8n

   docker compose stop n8n——避免 restore 過程有寫入。

2. Restore DB

   Postgres：psql n8n < backup.sql；SQLite：複製 database.sqlite 蓋回去。

3. 確認 N8N_ENCRYPTION_KEY 匹配

   這是 restore 最關鍵的一步——新環境的 encryption key 必須跟 backup 當時一模一樣，credentials 才解得開。改過就死。

4. 開 n8n、驗證

   docker compose up -d n8n，登入後打開一條 workflow 手動跑一次，確認 credentials 正常。有錯多半是 encryption key 對不上。

升級策略：不要在週五升級

n8n 版本迭代快（幾乎每週有小 release），升級雖然大多平順、但偶爾有 breaking change。步驟：

1. 先在 staging 環境試跑

   拉一份 production DB 到 staging，升級後跑所有主要 workflow 各一次。不要直接升 production。

2. 讀 changelog 有沒有 breaking change

   github.com/n8n-io/n8n/releases——特別注意 major version（0.x → 1.x 是大事）與標記 BREAKING 的項目。node 的 v1 → v2 也常有欄位改名。

3. Backup 一次（不管你多有信心）

   上面 §backup 那組全跑一遍。這是升級前的最後一道保險。

4. 停 workflow → 升級 → 開起來

   Docker 用戶：docker compose pull && docker compose up -d（如果 tag 是 latest）。手動裝的：npm install -g n8n@latest。

5. 檢查 UI、跑一條測試 workflow

   登入、打開 workflow、手動 Execute 一次。有錯先看 log（docker logs n8n）。

監控：怎麼知道 n8n 還活著

Production n8n 應該要有基本監控——不然半夜掛了沒人知道。幾種做法從簡單到複雜：

架構層常見卡關

不是 workflow 邏輯錯、而是 n8n 本身出問題時，最容易遇到這幾種：

常見問題