很多人看到 n8n 可以自架，第一反應是：「那我是不是不用付 n8n Cloud 月費？」這個想法很合理，但也很容易讓人踩坑。
真正的問題不是「自架可不可以」，而是你有沒有準備好承擔這些事：
- Webhook 要對外收資料，網域、SSL、反向代理誰設定？
- n8n 更新後 workflow 壞掉，誰回滾、誰看 log？
- VPS 壞掉或資料庫爆掉，credentials、workflow、execution data 有沒有備份？
- 你用 SQLite 跑正式流程，哪一天資料壞了或搬家時怎麼辦？
- workflow 變多、排程變多、AI 任務變慢時，要不要上 Postgres、Redis、Queue mode？
自架不是免費，它只是把費用從月費換成另一組成本：VPS、資料庫、備份、SSL、監控、更新、資安、故障排查，以及你或工程團隊的時間。對技術團隊來說，自架很有價值；對完全沒有伺服器經驗的人來說，一開始硬上 Docker 反而可能讓你還沒做出 workflow，就先卡在網域、憑證、資料庫和權限。
這篇會幫你做選型：什麼時候用 n8n Cloud、什麼時候用本機 Docker、什麼時候該上 VPS + Postgres、什麼情況才需要 Queue mode。目標不是鼓吹你自架，而是讓你知道每個選項背後的代價。
如果你還沒做過第一條 workflow，先看 n8n 完整教學；如果你正在做正式串接，建議也讀 n8n Webhook 教學。
先用 5 個問題決定要不要自架
| 問題 | 如果答案是「否」 | 如果答案是「是」 |
|---|---|---|
| 你已經有明確 workflow 要長期跑嗎？ | 先用 Cloud 或本機測試 | 可以評估 VPS |
| 你需要接內網、私有 API 或內部資料庫嗎？ | Cloud 通常比較省事 | 自架會比較有彈性 |
| 團隊有人會 Linux、Docker、DNS、SSL 嗎？ | 不建議一開始自架正式環境 | 可以用 Docker Compose 起步 |
| 你能接受自己處理備份、更新和故障嗎？ | 用 Cloud 比較安全 | 自架成本才有意義 |
| workflow 執行量很大、需要 worker 擴充嗎？ | 暫時不需要 Queue mode | 再研究 Redis、worker、Queue mode |
先用白話分清楚：Cloud 和自架差在哪？
| 問題 | n8n Cloud | 自架 n8n |
|---|---|---|
| 誰負責主機？ | n8n 官方 | 你 |
| 誰負責更新？ | n8n 官方 | 你 |
| 誰處理 SSL / 網域 / 反向代理？ | 多數由平台處理 | 你 |
| 資料在哪裡？ | 依官方方案與設定 | 你選的主機、資料庫、備份位置 |
| 能不能接內網？ | 看網路限制 | 通常比較自由 |
| 出問題誰排查？ | 先看官方服務與支援 | 你看 log、主機、資料庫、網路 |
| 適合誰？ | 新手、營運團隊、快速驗證 | 工程團隊、內部系統、資料控管需求 |
如果只是想確認 n8n 對你有沒有用，我會先用 Cloud 或本機測試，不要第一天就把自己丟進自架。
部署方式怎麼選？
| 方式 | 適合誰 | 優點 | 代價 |
|---|---|---|---|
| n8n Cloud | 新手、非工程團隊、快速驗證 | 開箱快、省維運 | 方案、資料位置、網路限制要看官方條款 |
| 本機 Docker | 學習、測試、短期 demo | 成本低、可快速試 | 不適合正式對外 webhook |
| VPS + Docker Compose | 小型正式內部流程 | 可控、容易接自家系統 | 要管 SSL、更新、備份、監控 |
| VPS + Docker + Postgres | 正式營運起點 | 資料庫較適合長期保存 | 要管理資料庫、備份、遷移 |
| Queue mode | 高流量、多 worker、需要擴充 | 可加 worker 分攤執行 | 要 Redis、Postgres、worker、更多 DevOps |
| Enterprise / 私有部署 | 金融、醫療、大企業 | 權限、稽核、合規與支援較完整 | 採購與導入成本較高 |
簡單說：
- 想先學會 n8n：用 Cloud 或本機。
- 已經有固定內部流程：VPS + Docker Compose。
- 會處理客戶資料與長期營運：Postgres + 備份。
- 流量高、執行多、不能卡住：Queue mode。
我會怎麼建議不同讀者選
| 你的狀態 | 建議選擇 | 原因 |
|---|---|---|
| 還沒做出第一條 workflow | n8n Cloud 或本機 Docker | 先驗證 n8n 是否真的能解決你的流程問題 |
| 行銷、營運、顧問團隊想快速導入 | n8n Cloud | 少掉主機、SSL、備份、更新維護，時間比較值錢 |
| 有工程能力，想接內部 API | VPS + Docker Compose | 彈性夠，複雜度還能控制 |
| 會長期跑客戶資料、CRM、訂單同步 | VPS + Postgres + 備份 | 資料不能只靠預設測試型配置硬撐 |
| workflow 很多、執行時間長、排程密集 | Queue mode | 用 worker 分攤執行，但要接受 Redis 和監控成本 |
| 有合規、稽核、權限、支援需求 | Enterprise / 私有部署評估 | 這時候問題不是省錢，而是治理與責任歸屬 |
最務實的路線通常是：先用 Cloud 或本機做出有價值的 workflow，再決定要不要把正式環境搬到 VPS。不要為了「自架感覺比較專業」而自架。
什麼時候該自架？
自架適合下面這些情況：
- 需要接公司內網、私有 API、內部資料庫。
- 資料政策要求你控制主機、資料庫、備份位置。
- 有工程或 DevOps 能力管理更新、SSL、監控、備份。
- workflow 很多，且需要客製化執行環境。
- 要安裝或管理特殊 community nodes。
- 需要更細的網路、權限、log 和資料保存策略。
不適合自架的情況：
- 你只是想試試 n8n。
- 團隊沒有任何 Linux / Docker / DNS / SSL 經驗。
- 沒有人負責更新與資安。
- 出問題時無法接受停機。
- 你還不知道要自動化哪個流程。
VPS + Docker Compose 最少要準備什麼？
正式放到 VPS 上，至少要準備：
| 項目 | 為什麼需要 |
|---|---|
| 網域 / 子網域 | Webhook 和 OAuth callback 需要穩定 URL |
| SSL | 對外服務必備，很多 SaaS webhook 也要求 HTTPS |
| Docker / Docker Compose | 管理 n8n、資料庫、反向代理 |
.env | 管理網域、時區、資料庫、encryption key |
| Postgres | 正式資料庫，比 SQLite 更適合長期營運 |
| 備份 | workflow、credentials、execution data 都可能很重要 |
| 更新流程 | n8n 更新頻繁，要知道何時升級、如何 rollback |
| log / monitoring | 出錯時要能追 |
官方 Docker Compose 文件也提醒，自架需要伺服器、容器、資源、資安與 n8n 設定知識；如果沒有管理伺服器經驗，官方也建議使用 n8n Cloud。
SQLite、Postgres、Redis 差在哪？
| 元件 | 用途 | 什麼時候需要 |
|---|---|---|
| SQLite | 輕量資料庫 | 本機測試、小型 demo |
| Postgres | 正式資料庫 | 長期營運、多人使用、重要 workflow |
| Redis | Queue mode 的佇列 | 需要 worker 擴充或高併發 |
如果你只是學習，不必一開始就上 Postgres + Redis。但如果你要正式跑客戶資料、金流、CRM 更新或公司內部流程，請不要把資料庫當成小事。
Queue mode 是什麼？
Queue mode 是 n8n 的擴充模式。它的概念是把「接收任務」和「執行任務」拆開：
- main instance 接收 trigger、timer、webhook。
- main instance 產生 execution ID。
- Redis 負責排隊。
- worker 從 Redis 拿任務。
- worker 從資料庫讀 workflow，執行後把結果寫回資料庫。
- 你可以增加或減少 worker 來調整處理能力。
這很適合高流量或大量執行，但不是新手第一天該碰的東西。Queue mode 至少要理解 Redis、Postgres、worker、encryption key、log、併發與部署架構。
另外，官方文件提醒 queue mode 不支援把 binary data 存在 filesystem 的模式；如果流程需要保存 binary data，要考慮 S3 這類 external storage。
自架最容易忽略的 8 個坑
| 坑 | 後果 | 避免方式 |
|---|---|---|
沒固定 N8N_ENCRYPTION_KEY | credentials 可能解不開 | 第一次正式部署就設定並備份 |
| 沒備份資料庫 | 主機壞掉 workflow 全沒 | 定期備份 Postgres 和重要檔案 |
| 用 Test URL 接正式 webhook | 上線後收不到事件 | 使用 Production URL 並啟用 workflow |
| 沒設 SSL | OAuth / webhook / 瀏覽器安全問題 | 使用 HTTPS 和有效憑證 |
| 隨便升級 beta | workflow 可能出問題 | 正式環境用 stable，先測再升 |
| 沒監控 execution failure | 流程壞了沒人知道 | Error Trigger + 外部告警 |
| 把 admin token 塞進節點 | 權限過大、難稽核 | credentials 最小權限 |
| 沒限制 webhook 來源 | 任何人可打入口 | auth、secret header、IP whitelist |
建議導入順序
第 1 階段：Cloud 或本機驗證
先做一條小流程，例如表單進線、客服分類、Google Sheets 同步。目標是確認 n8n 真的能省時間，不是先研究部署。
第 2 階段：VPS + Docker Compose
當流程開始有固定價值，再搬到 VPS。這時要處理網域、SSL、.env、資料持久化、備份和更新。
第 3 階段：Postgres 與正式備份
只要 workflow 開始影響客戶資料、內部營運或金流，就要把資料庫和備份當正式系統管理。
第 4 階段：Queue mode
當單機執行不夠、排程多、webhook 多、執行時間長，才考慮 Queue mode。這不是省錢方案，而是擴充方案。
常見問題
n8n 自架真的比較便宜嗎？
如果你有工程能力、流量穩定、維運成本可控，可能比較划算。但對新手來說，自架常常只是把月費變成時間成本、故障成本和資安責任。
可以用 SQLite 正式跑嗎？
小型個人流程可以，但正式團隊、重要資料、queue mode 或高流量流程不建議把 SQLite 當長期方案。正式營運通常應評估 Postgres。
Queue mode 是不是一開始就該開？
不是。Queue mode 是擴充和高併發用的架構，會增加 Redis、worker、部署和監控複雜度。先把單機流程跑穩，再談 queue。
自架就代表資料完全安全嗎？
不代表。自架只是讓你掌控環境；如果沒有更新、備份、權限、SSL、log、credentials 管理，反而可能更危險。
下一步
如果你還沒做出第一條流程，先回到 n8n 教學 hub。如果你要讓外部系統打進自架 n8n，請先看 n8n Webhook 教學，確認 Production URL、反向代理、SSL 和 webhook 驗證都設好。