嗨各位，
我開始管理一個更大型的 n8n 設置，包含多個環境：開發 → 預發布 → 生產
我想找出最佳的工作流部署/版本控制策略。
目前，變更是直接在編輯器中進行，但這變得很危險，因為：
• 很難追蹤工作流變更
• 回滾很麻煩
• 環境間的認證/配置不同
• 小編輯可能會意外破壞生產環境
我已經研究過：
• 將工作流匯出到 Git
• 使用 n8n API 進行部署
• 使用環境變數進行配置分離
• 每個環境使用單獨的 n8n 實例
我苦惱的是：
• 團隊如何安全地從開發 → 預發布 → 生產推廣工作流
• 如何處理認證而不硬編碼
• 人們是否使用 CI/CD 搭配 n8n 或主要使用手動部署
描述問題/錯誤/問題
哪個部署/版本控制工作流效果最好？
有建議的安全發佈和回滾實踐嗎？
錯誤訊息是什麼（如果有的話）？
請分享您的工作流
(在畫布上選擇節點，使用鍵盤快速鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 複製和貼上工作流。)
分享最後一個節點返回的輸出
關於您的 n8n 設置的資訊
- n8n 版本：
- 資料庫（預設：SQLite）：
- n8n EXECUTIONS_PROCESS 設置（預設：own, main）：
- n8n 運行方式（Docker、npm、n8n cloud、桌面應用）：
- 作業系統：
對我來說最有效的方法是以管理應用程式發佈的方式來管理 n8n 工作流程，而不是直接在生產環境中進行變更。
Hi @Kabrooks
大多數生產團隊使用：分別為開發、預上線和生產環境設置獨立的 n8n 實例
而不是直接在生產環境中編輯工作流。
你將在開發環境中建置和測試
在預上線環境中再次測試，只有當所有功能都正常運作時才移至生產環境
然後將工作流保存/匯出至 Git 以保持版本歷史記錄
使用環境變數來管理 API 金鑰、URL 和資料庫設定
為每個環境保持不同的認證資料
這個方法效果最好且更容易追蹤變更
更安全的更新
如果出現問題可輕鬆回滾
降低破壞生產工作流的風險
值得指出的是 n8n 的內建原始碼控制功能（設定 > 原始碼控制）- 它可以直接連接到 Git 儲存庫，並讓你從 UI 推送/拉取工作流程，無需手動匯出。每個環境都有自己的分支（dev、staging、prod），而升級只需在目標實例上進行合併 + 拉取。憑證在設計上被排除在儲存庫之外，因此你需要按環境分別處理。對於 CI/CD，你可以通過 API（POST /source-control/pull）觸發 n8n 從 Git 拉取，讓 GitHub Actions 管道可以自動化升級步驟。
遇到完全相同的問題。Source Control 功能會有幫助，但對於使用 Community Edition 的大多數團隊來說，€667/月的價格根本不可行。我還沒找到解決方案的部分是如何在不手動複製 10+ 個工作流程的情況下為每位開發者提供隔離環境。你也有這個問題，還是主要是測試環境 → 正式環境的升級問題？
Hi @Kabrooks
我使用的一個輕量級方法是透過命名和匯出備份來進行手動工作流版本控制。
例如，我會匯出重要的工作流版本，並在其中包含：
-
版本號碼
-
有時在工作流描述或檔案名稱中包含相關的票證參考
我通常遵循結構化的編號風格（例如：0.100），其中不同的數字代表不同層級的變更，例如功能更新與除錯修復版本。
這是個簡單的方法，但它幫助我快速識別哪個版本需要還原（如果需要的話）。這種做法某種程度上受到了軟體版本控制實踐的啟發，即使在引入完整的 Git 原始碼控制工作流程之前也適用。