n8n 搬家教學：Zeabur 遷移 Railway，Workflow 與 Credentials 怎麼轉移？

Zeabur 出現資安事件或平台異動，原本架在上面的 n8n 要搬去哪裡？

如果只是重新部署一套 n8n，其實不算最麻煩

真正讓人頭痛的是：Workflow 搬過去後，原本連好的 Telegram、Google Sheets 和 API 授權，還能不能繼續用？

尤其已經有自動化流程在運作，總不能換一台主機，就全部從頭設定一次吧 😂

n8n 從 Zeabur 搬到 Railway，除了匯入 Workflow，也要轉移 Credentials、更新 Webhook 和 OAuth 回呼網址，再確認新環境正常運作

這篇整理的是怎麼把原本的流程和授權一起搬走，而不是只教你建立空白 n8n

我先拿幾條自己平常會用的流程測試，確認新環境能接住原本的操作，再把備份、部署、授權轉移和切換順序整理下來

如果你還在比較替代平台，可以先看 Zeabur 停運後搬去哪？4 個替代方案比較

Zeabur 資安事件後，我重新調整了 n8n 的使用方式

Zeabur 發生資安事件後，我開始重新思考自動化服務應該放在哪裡

以前比較在意部署方便、費用合理，能跑就好 😂

但這次讓我重新考慮一件事：如果自動化已經牽涉商業營運或重要資料，主機的安全維護和後續管理就不能只看價格

所以我現在把 n8n 分成兩種使用方式

涉及商業營運、客戶資料或重要業務流程的自動化，我會優先考慮 n8n Cloud

由官方負責基礎設施、平台更新與相關安全維護，對我來說可以減少不少自行管理的負擔

自己使用的小工具、測試專案，或不涉及敏感資訊的自動化，我則會選擇 Railway 自架 n8n

保留更多設定彈性，也方便測試不同服務

這不代表 Railway 不適合商業用途，而是我現在會依照資料敏感程度、營運重要性，以及願意承擔多少維護責任來選擇部署方式

這次 Zeabur 搬到 Railway，就是我把自用與測試環境轉移出去的過程，下面分享實際怎麼搬

搬家前，先確認哪些東西一定要帶走

如果替客戶搬遷，請先取得授權、確認備份保存位置與可接受的停機窗口，不要把憑證、資料庫或 Token 貼到一般聊天視窗

先備份、確認備份能讀，再建立新環境，不要急著刪掉 Zeabur

第一步：在 Zeabur 備份 Workflow、資料庫與 Encryption Key

先在 n8n 匯出需要搬遷的 Workflow JSON，並依目前使用的資料庫方式保存完整備份

我原本的環境使用 PostgreSQL，也另外備份了資料庫與原始 Encryption Key

注意：Workflow JSON 不會把所有可以直接使用的 API Key、OAuth Token 一起帶過去

如果只匯入 Workflow，畫面可能看起來完整，但節點仍無法正常連線

Encryption Key 也應安全離線保存，避免直接放進 GitHub、公開雲端資料夾或文章截圖

如果有把備份檔下載到自己的電腦，也可以比對傳輸前後的 SHA-256 檢查碼，確認檔案內容沒有在傳輸過程中改變

不過檢查碼一致不代表備份一定能成功還原，正式切換前還是要實際測試

第二步：在 Railway 建立新的 n8n

先從 Railway 建立專案，選擇 Docker Image 服務

我使用官方 n8n Docker Image 部署，實測版本為 n8nio/n8n:2.4.6

第一次部署可搭配 Railway 官方 n8n 部署文件 查看平台設定，這篇則著重原有流程與授權的轉移

部署前先準備好持久化 Volume、固定 Encryption Key 與 n8n 的環境變數，避免服務啟動後才臨時更換金鑰

這次使用的關鍵設定如下，不是每個環境都必須照抄所有值：

接著為 n8n 加入持久化 Volume，先選擇要掛載的服務

掛載位置設為 /home/node/.n8n，避免新部署時遺失存放在該目錄的資料

如果還在評估是否適合自己管理 n8n，也可以先看我整理的 n8n 自架成本、限制與使用心得

這次 Railway 使用 SQLite 作為新環境資料庫，因此 Zeabur 的 PostgreSQL dump 不能直接匯入 SQLite

如果你的需求是完整保留執行紀錄、使用者或其他資料庫狀態，應另行評估資料庫層級遷移，不要把本篇的 Workflow／Credentials 搬法當成完整資料庫還原

遇到 Volume 權限錯誤怎麼辦？

我第一次啟動時，日誌出現：

EACCES: permission denied, open '/home/node/.n8n/config'

這次在 Railway 增加 RAILWAY_RUN_UID=0 後成功啟動

不過這會讓程序以 root 身分執行，權限較高，屬於這次環境的相容性處理，不應當成所有部署的預設安全設定

正式使用前仍應評估 Volume 所有權與最小權限配置

Railway 顯示 Online，網址卻打不開？

先確認 Deploy Logs 有出現 n8n 啟動完成訊息，例如：

Editor is now accessible via:
http://localhost:5678

再檢查 Railway 的 Public Networking HTTP Target Port 是否為 5678，並確認 N8N_LISTEN_ADDRESS=0.0.0.0

HTTP Target Port 不是 TCP Proxy，不需要為了打開 n8n 網站而另外新增 TCP Proxy

第三步：匯入 Workflow，但先不要啟用 Trigger

新 n8n 能登入後，從編輯器匯入原本的 Workflow JSON

我先挑幾條自己會用的流程匯入測試，確認節點與結構存在，但沒有立刻啟用 Telegram Trigger

原因很簡單：舊 Zeabur 如果還在接收訊息，新 Railway 又搶著使用同一個 Bot Webhook，切換過程就可能混亂

先確認授權與 Webhook，再安排正式切換

第四步：Credentials 不一定要逐一重建

這是我覺得整次搬遷最值得記下來的一段

n8n 官方 CLI 支援匯出 Credentials，如果新舊環境使用不同 Encryption Key，可以透過 --decrypted 匯出，再讓新環境匯入並使用自己的 Encryption Key 加密儲存

n8n 官方也整理了 匯出與匯入 CLI 指令，可以先對照自己使用的版本，再決定採用哪種 Credentials 轉移方式

先在 Zeabur 的 n8n Terminal 確認指令：

n8n export:credentials --help

若要先保存加密備份，可以執行：

(umask 077; n8n export:credentials --all --output=/tmp/n8n-credentials-encrypted.json)

匯出成功後，先確認 CLI 顯示的 Credentials 數量與預期一致，不需要在文章或截圖中公開授權內容

注意：上面是加密備份，不是跨不同 Encryption Key 時可以直接使用的解密搬遷檔

不同金鑰的搬遷，實際使用的是官方 --decrypted 方式：

(umask 077; n8n export:credentials --all --decrypted --output=/tmp/n8n-credentials-transfer.json)

這個檔案含有明文 Token、密碼與 OAuth 授權資訊，只能在受控環境中短暫保存，絕對不要公開、上傳 GitHub 或傳給不必要的人

我這次是透過 SSH 將解密匯出檔安全傳到 Railway，再在 Railway 的 n8n 執行：

n8n import:credentials --input=/tmp/n8n-credentials-transfer.json

匯入後由 Railway 這個 n8n instance 使用自己的 Encryption Key 重新加密儲存

實際執行時，請依你使用的 Railway SSH 傳輸方式與容器檔案路徑調整，並確認匯入指令適用於當前 n8n 版本

不要在舊環境還沒備份完成時就刪除 Credentials，也不要為了方便把兩邊的金鑰直接貼在公開 Terminal 紀錄裡

另外，Credentials 成功匯入不保證每一種 OAuth 都永遠不需要重新授權，還是要逐項測試

第五步：換成 Railway 的 HTTPS Webhook，再切換舊流程

Railway 網站能開啟後，要讓 n8n 產生正確的公開 Webhook 網址

以實際 Railway HTTPS 網域設定 WEBHOOK_URL，例如：

WEBHOOK_URL=https://你的-railway-網域/

這裡的網址是示意，請使用自己真正的 HTTPS 網域，不要照抄別人的部署網址

匯入 Credentials 後，還有兩個地方要特別檢查，因為換了網域，原本的第三方服務不一定會自動認得新環境

Telegram：確認新的 HTTPS Webhook

先確認 Railway 的公開網址與 WEBHOOK_URL 設定一致

停用 Zeabur 原本使用該 Bot 的 Trigger，再啟用 Railway 上對應的 Workflow，讓 Telegram 的 Webhook 指向新環境

接著送一則測試訊息，確認 Railway 收得到、流程有執行，而且舊環境沒有重複接收

Google OAuth：更新回呼網址並重新授權

Google 的 Credentials 即使成功匯入，也可能因為新 n8n 網域不同而需要重新授權

在 Railway 的 n8n 開啟對應的 Google OAuth Credential，確認畫面顯示的 OAuth Redirect URL

到 Google Cloud Console，找到該 OAuth Client，將 Railway 的完整回呼網址新增到 Authorized redirect URIs

儲存後回到 Railway 的 n8n 重新連線授權，再用一條實際會讀取或寫入 Google Sheets 的流程測試

這裡要使用 n8n 畫面顯示的完整 Redirect URL，不要只填 Railway 網域，也不要把 OAuth Client Secret 放進文章或截圖

最後再切換正式流程

這次我先拿幾條自己會用的流程測試，確認 Workflow、Credentials 和 Webhook 能正常配合

如果是正式營運或客戶環境，建議依序完成備份、測試、停用舊 Trigger、啟用新流程與實際驗收，再關閉舊服務

不要讓新舊環境同時接管同一個 Telegram Bot 的 Webhook

第六步：確認資料保留與安全收尾

正式關閉舊環境前，我建議至少逐項確認：

• 每條要保留的 Workflow 都已匯入，節點設定正確
• Credentials 不只匯入成功，也實際能連線
• Telegram／Webhook 不會由兩個環境重複接收
• Google Sheets 寫入正確，沒有寫到錯誤表單或帳號
• Railway 重新部署後，Volume、Credentials 與 Workflow 仍然存在
• 已建立新環境的備份與復原方法
• 明文 Credentials 暫存檔已在傳送端與接收端安全清理

資安事件後，別忘了檢查舊授權

這次我透過 n8n 官方指令，把原本的 Credentials 一起搬到 Railway，省下逐一重新設定的麻煩

但 Credentials 成功匯入，不代表原本的 API Key 和 Token 就自動變安全

如果舊環境的授權可能受到資安事件影響，還是應該依照各平台提供的方式撤銷或輪替舊 Token，必要時重新完成 OAuth 授權

Workflow 裡如果有直接寫入 API Key 或 Token，也要一併檢查

畢竟搬家只是換個地方繼續運作，授權安全是另一件事

常見問題

Google OAuth 匯入後，為什麼還要重新授權？

因為新的 Railway 網域可能改變 n8n 的 OAuth Redirect URL，原本 Google Cloud Console 裡的授權回呼設定不一定包含新網址

先新增 Railway n8n 畫面顯示的完整 Redirect URI，再回到 Credential 重新授權並測試

只匯出 Workflow JSON 就能搬家嗎？

不行，JSON 能保留流程結構，但 Credentials、資料庫、Webhook 與環境變數還需要另外確認

一定要重新找回全部 API Key 嗎？

不一定，n8n 官方 CLI 支援 Credentials 匯出與匯入

這次實測已成功轉移 Credentials，不需要逐一重建授權，但解密匯出會接觸明文敏感資料，務必限制存取並做好清理

原本是 PostgreSQL，Railway 可以改用 SQLite 嗎？

可以建立使用 SQLite 的新 n8n，但不是直接把 PostgreSQL dump 匯進 SQLite

這篇使用 Workflow JSON 加 Credentials 匯入來搬遷核心流程，不等於完整搬走 PostgreSQL 的所有資料

搬家最重要的不是換主機，是流程還能繼續跑

這次從 Zeabur 搬到 Railway，最有用的經驗就是把 Workflow、Credentials 與切換驗收拆開處理

不用急著一次搬完所有東西，先讓需要的流程在新環境正常運作，再慢慢確認資料保留、授權與備份

畢竟搬家最重要的不是換了一台主機，而是原本的自動化還能繼續幫你做事 😂

想比較更多平台，可以回頭看 Zeabur 停運後搬去哪？