2026 上半年我們連續接到三通類似電話：「n8n 自架跑了兩年，上個月 minor version 一升上去，credentials 整批變亂碼，60 個 workflow 倒了 11 個——是不是該搬到 cloud？」這已經是當季第三個一模一樣的問題。

這篇文章把我們協助 6 家客戶完成 n8n self-host 與 cloud 之間雙向遷移的實戰 SOP 整理出來——含資料庫匯出、encryption key 處理、雙跑切流，以及我們踩過、客戶不該再踩的 5 個雷。

1. 何時該搬：自架的痛閾值

我們先講「self-host 轉 cloud」的場景。下列訊號出現任何 2 個，就值得認真評估：

  • 過去 6 個月內，n8n 升級造成 workflow 損壞 > 1 次
  • VPS 磁碟爆過、execution_data 沒人清
  • credentials 因為升級加密邏輯出現整批變空白
  • 團隊縮編，沒有人會看 docker compose
  • 連續 3 個月維運時數 > 5 小時

反向訊號（cloud → self-host）：月費 > $200 USD、客戶要求 SOC2 / 在地化、execution payload 含個資不希望出境，這時 self-host 仍是正解。

案例 A：一家跨境電商客戶，3 人團隊，n8n self-host 撐了 14 個月。最後一次 minor version 升級時 60 個 workflow 倒了 11 個，我們花 18 小時才修完。他們改 cloud 後月費 $54 USD，運維時數從每月 6 小時歸零，半年 ROI 已回本。

2. 三種遷移方案比較

方案 A：手動 export / import workflow JSON

適合 < 10 個 workflow、credentials 不多、可接受 4–6 小時停機的小規模情境。在原機 UI 一個一個下載 JSON，到新環境再上傳；credentials 全部手動重建。優點：零腳本依賴。缺點：scheduler 要逐一 enable，OAuth 重新授權，肉眼容易漏。

方案 B：CLI 全量匯出（推薦的主流方案）

20–50 個 workflow 的標準做法，用 n8n CLI：

  • 匯出 workflow：n8n export:workflow --all --output=./bk/wf --separate
  • 匯出 credentials：n8n export:credentials --all --output=./bk/cred --decrypted=false
  • 新環境匯入：n8n import:workflow --separate --input=./bk/wf 與對應的 credentials 指令

注意：不要直接 pg_dump 整庫然後在 n8n cloud 還原——cloud 不開資料庫權限給你。整庫 dump 只能用在 self-host 之間或反向遷移。

方案 C：API + script 全自動同步

> 50 個 workflow，或要做變數替換（例如 staging URL → production URL），我們會寫一支 TypeScript script 走 n8n REST API：拉 workflow、拉 credentials metadata、拉 variables，做字串替換後 push 上去。第一次寫腳本約 1 天，但之後 reuse 給其他客戶幾乎零成本。

3. 資料庫遷移實作

n8n self-host 預設用 SQLite。我們建議所有可能未來會遷移的客戶，初次部署時就改用 Postgres——彈性高十倍。SQLite 客戶遷移前，我們會先做一次 SQLite → Postgres 的內部搬遷，避免後面被資料庫鎖死。

Postgres 之間的搬遷可以走 pg_dump，但需要在新機先把 n8n 跑起來建好 schema，再 restore 資料表：

  • pg_dump --data-only --table=workflow_entity --table=credentials_entity ...
  • psql ... < dump.sql 進新庫
  • 啟動 n8n，讓它跑一次 migration 對齊版本

關鍵：兩邊 n8n 版本必須一致，至少在同一個 minor。我們有客戶因為 self-host 是 1.42、cloud 是 1.58，node_type schema 變過，import 完直接整批 error。

4. credentials 處理：最常翻車的環節

n8n 把 credentials 加密寫進 DB，金鑰存在環境變數 N8N_ENCRYPTION_KEY。遷移時忘了帶這把 key，credentials 全部變亂碼，無法回復。

我們的 SOP：

  1. 在原機 echo $N8N_ENCRYPTION_KEY 抄下來（或翻 .env / docker-compose.yml）
  2. 新環境部署前，先把這把 key 寫進 env，再啟動 n8n
  3. 啟動後再 import credentials
  4. 進 UI 一個一個點開 credentials，確認連線測試通過
  5. OAuth 類（Google / Microsoft / Slack）即使 key 帶對了，redirect URI 變了就必須重新授權——這是第二常見坑

n8n cloud 的 encryption key 由平台管理、看不到。從 self-host 搬進 cloud 時，credentials 要走 UI 重新建（或用 API 重新塞），不能直接複製 DB row 過去。

5. 切流策略：雙跑七天，不要英雄主義

過去我們也試過「週末熬夜整批切」，結果週一早上電話炸滿信箱。現在的 SOP 是強制雙跑 7 天：

  • Day 1–2：新環境所有 workflow 設為 inactive，手動觸發跑一輪，逐個比對輸出與舊環境差異
  • Day 3–5：切 10% 流量過去（透過 webhook 前面的 reverse proxy 分流，或時段切流）
  • Day 6：切 50%
  • Day 7：切 100%，舊環境保留但 disable trigger，當 hot standby
  • D+14：原機關機，正式退役

案例 B：教育 SaaS 客戶，48 個 workflow，第一次合作時客戶堅持當天 100% 切過去。結果 cloud 預設 timezone 是 UTC、原本自架是 Asia/Taipei，所有「每天早上 9 點」的 cron 變成「下午 5 點」。我們連夜把 Schedule node 全部加上 timezone 參數。從那次後，雙跑七天變成我們合約裡寫死的條款。

6. 我們踩過的 5 個避坑

  1. Encryption key 沒帶：credentials 整批變亂碼，無法解密。先抄 key，再 export。
  2. Timezone 預設值不同：cloud 預設 UTC、self-host 看 OS。Schedule node 一律明寫 timezone 參數，不要靠預設。
  3. Webhook URL 沒換：第三方系統的 callback 還指向原機。切流前先用 reverse proxy 或自家網域當 alias，否則切完幾小時內掉訊息。
  4. Redis queue 沒清：queue mode 的客戶，原機未跑完的 job 還在 queue 裡，cloud 又跑一次，可能造成重複扣款 / 重複寄信。切流前一定要把 queue drain 乾淨。
  5. Static IP 改變：cloud 沒有固定 IP，客戶端的 IP whitelist 必須改成 webhook secret 或 HMAC 驗證。這在金流、ERP、銀行 API 上特別痛。

案例 C：一家 B2B 服務商遷移完三天後客訴量爆炸，我們追進 log 才發現是 Redis queue 沒清，cloud 上的 worker 拿到舊 job 又跑一次，導致同一封通知信寄了兩次給 4,000 個用戶。事後賠了一張道歉信和一個月 SLA 折讓。從此 queue drain 進 SOP 第一條。

結語：搬不是目的，穩才是

很多客戶以為搬到 cloud 就一勞永逸，但 cloud 也有它的限制：execution log 保留期短、custom node 走 community edition、無法跑需要 binary 的場景（例如本機 OCR、ffmpeg、Puppeteer）。

我們協助過的客戶裡，最終留在 self-host 的有 4 家、搬到 cloud 的有 5 家、搬完又搬回去的 1 家。沒有絕對答案，只有「現在這個團隊、這個流量、這個合規要求」適不適合。我們的工作是幫客戶把「適不適合」算清楚，再把該做的 SOP 做到位——而不是把客戶推到任一個極端。

如果你正在卡在「該不該搬、怎麼搬」的決定，加 LINE 一對一聊 30 分鐘，我們會根據你的 self-host 版本、workflow 數量、客戶屬性、合規需求給具體建議——不收諮詢費，這通常是合作起點。