我們只有一個 n8n 實例用於開發和生產環境，我們該如何分別管理機密資訊，以及如何在工作流中使用它們？
單一個由開發和生產共用的實例無法真正區隔機密，因為其中只有一個機密上下文。n8n 的預期模式是兩個實例，一個用於開發，一個用於生產，它們的工作流透過原始碼控制進行同步。
對於機密，你想要的功能是外部機密（企業版）。你可以連接像 AWS Secrets Manager、Azure Key Vault 或 HashiCorp Vault 這樣的保管庫，然後將開發實例指向開發保管庫，將生產實例指向生產保管庫。在認證欄位中，你可以將值參考為 $secrets.yourVaultName.secretName，這樣機密就永遠不會存在於工作流本身中。
如果你必須保留單一實例，實際的解決方案是使用分開的開發和生產認證，但那並不是真正的隔離。
我同意 @achamm 的看法，「乾淨」的做法是分開開發/正式環境——這是獲得秘密和執行真正隔離的唯一方式。
如果目前你只能使用單一實例，但你的方案支援外部秘密，你可以做一件額外的事情至少邏輯上分開數值：
-
在你的秘密後端建立兩個保管庫，例如
dev和prod -
在 n8n 的設定 → 外部秘密中連接兩者
-
然後在你的憑證/表達式中明確引用它們，例如：
-
{{ $secrets.dev.MY_API_KEY }}用於開發 -
{{ $secrets.prod.MY_API_KEY }}用於正式
-
這不會像兩個實例那樣給你硬隔離，但可以避免使用單一「混合」憑證，並清楚地表明工作流程與哪個環境通訊。
如果你多分享一些關於你設定的資訊（雲端 vs 自託管，以及哪個方案），這裡的人可能可以建議符合你限制的具體做法。
如果您有企業雲端方案，可以使用外部機密功能為每個環境連接分開的保管庫；若為自託管部署，您可以透過環境變數或 REST 端點使用認證覆寫；但如果使用雲端社群版本，一個實用的解決方案是為開發和生產環境建立分開的認證，將 URL/配置儲存在資料庫或 Google Sheets 中，並在每次工作流程啟動時根據環境變數 ENV=dev 或 ENV=prod 來擷取正確的配置
在一個實例上同時執行兩個環境是有風險的，因為測試工作流程中的一個錯誤可能會導致整個系統崩潰。如果你的業務嚴重依賴這些自動化，最安全的長期做法是設置兩個完全獨立的 n8n 安裝——一個用於實驗，一個用於實際生產環境。
為了回答您的問題,我們使用自主託管的設置,搭配企業方案,目前只有一個實例在運行
既然你是自主託管企業版但仍在單一執行個體上，分開的 vault 值有助於憑證衛生，但它們不會讓開發和生產環境真正隔離。測試工作流仍可在與生產相同的執行/運行時路徑中執行。
完整的分離仍然是兩個 n8n 執行個體共享源代碼控制的工作流，各自指向自己的 vault/env。如果暫時無法分離，保持短期規則簡單：生產憑證僅在生產工作流上，開發憑證在複製的開發工作流上，且它們之間沒有共享的憑證名稱。阻礙因素只是憑證分離，還是你也需要防止開發運行/webhook 觸及生產系統？
由於你的自託管 Enterprise 在單個實例上運行，Credential Overwrites 是最簡潔的模式。通過在 Docker 設定中使用 CREDENTIALS_OVERWRITE_DATA 在環境層級注入機密，這樣機密就永遠不會出現在 UI 或資料庫中：
environment:
- CREDENTIALS_OVERWRITE_DATA={“ProdDB”:{“host”:“prod-db.internal”,“password”:“prod-secret”},“DevDB”:{“host”:“dev-db.internal”,“password”:“dev-secret”}}
工作流程建構者在 UI 中建立名為 ProdDB / DevDB 的憑證，敏感欄位留空，n8n 在執行時靜默注入實際值。
配合外部 Secrets 後端中的兩個 vault 路徑（/n8n/dev/ 和 /n8n/prod/），並在工作流程中明確參考它們，如 $secrets.dev.API_KEY 與 $secrets.prod.API_KEY。
@oimrqs_ops 提到的執行時隔離風險在單個實例上仍然存在。透過在未主動測試時保持開發工作流程停用來降低風險。