n8n 2.38.5 升級怎麼做？先處理安全修補，再隔離測 2.39.1

先用 dist-tags 判斷該裝哪個版本#

不要只看 GitHub release 列表最上方，也不要把文章日期當成目前版本。先從 npm registry 讀取 n8n 的 dist-tags：

1
npm view n8n dist-tags --json

本次在 2026 年 9 月 10 日查到的狀態如下：

dist-tag 是頻道指標，不是「數字越大就越適合 production」的排序。更新 Docker image 或 package 時不要把 latest、beta、next 混在同一條部署流程：

1
# 穩定頻道：先固定明確版本
2
npm install [email protected]
3

4
# 預覽頻道：只在隔離環境測試
5
npm install [email protected]

固定明確版本比使用 dist-tag 更容易回溯；如果團隊選擇使用 tag，也應把執行日期、實際解析出的版本和 lockfile 一起記錄。

2.38.5 與 2.39.1 的頻道邊界要分開看#

n8n 的 npm dist-tags 顯示，2.38.5 同時位於 latest、stable 與 rc；2.39.1 位於 beta 與 next。tag 是發布頻道指標，不代表兩個版本可以共用同一套 production 回滾假設：

這裡要分清楚「release note 有修正」和「可以直接放進 production」。即使兩個版本出現相似的 bug fix，也不能推論所有 workflow 都沒有相容性風險；正式環境仍應先以 stable 做基準。

2.37.7／2.38.2 安全修補要先完成#

2026 年 9 月 2 日，n8n 新增高嚴重度公告 GHSA-hh89-3r9w-qj3j：OAuth Dynamic Client Registration 在特定情境可能造成 persistent storage exhaustion，受影響版本低於 2.37.7 或 2.38.2，修補基線是 2.37.7 或 2.38.2。本文原本列出的 legacy expression engine 與 Instance AI workflow summary prototype pollution 也要一併維持在修補版本之上，因此 2.38.5 與 2.39.1 都高於目前列出的 2.x 安全基線。

正式環境至少應升到目前 stable 的 2.38.5，或在隔離環境測試 2.39.1 後再切換。若暫時無法更新，官方列出的緩解方向包含將 expression engine 設為 vm、限制可登入與可執行 workflow 的使用者，以及移除或 unset Instance AI model 相關環境變數；這些只是降低風險的過渡措施，不能取代升級。修改環境變數後要重啟所有 main、worker、webhook 與 runner process，並檢查現有 credential 和 execution log。

從舊版升級前，先備份可以回復的狀態#

跨過多個 minor 版本時，最怕的是只更新 image tag，卻沒有保存可以回復的狀態。自架 n8n 至少先記錄：

• PostgreSQL 或 SQLite 資料庫備份。
• n8n 持久化 volume 或資料夾。
• N8N_ENCRYPTION_KEY，以及它的保存位置與輪替責任。
• 目前 image tag、Node.js 版本、external task runner 和 community nodes。
• main、worker、webhook processor、runner 的部署清單。

如果啟用了 Queue Mode 或多個執行元件，不能只升級一個 container。先在測試環境用相同拓樸和資料副本跑一次，確認 migration、queue、credential 和 webhook 都能啟動，再安排正式切換。

Docker Compose 用固定 tag 做升級回歸#

不要在正式環境直接使用 latest。先把所有 n8n 執行元件固定在同一個版本：

1
services:
2
  n8n-main:
3
    image: docker.n8n.io/n8nio/n8n:2.38.5
4

5
  n8n-worker:
6
    image: docker.n8n.io/n8nio/n8n:2.38.5
7

8
  n8n-webhook:
9
    image: docker.n8n.io/n8nio/n8n:2.38.5

升級流程可以先在測試環境執行：

1
docker compose pull
2
docker compose up -d
3
docker compose ps
4
docker compose logs --tail=200 n8n-main

接著檢查資料庫 migration 是否完成、Editor 能否登入，以及 workflow 的 webhook URL、schedule 和 credential 連線。不要只看 container 是 Up；n8n 能啟動不代表每條 workflow 都與新的 node、execution data 和 AI 設定相容。

OAuth、AI、MCP 與 Webhook 要做針對性回歸#

版本更新後，credential 不應只測「節點畫面打得開」。可以把測試分成幾組：

測試資料應固定，並對照輸入、輸出筆數、欄位型別、credential 使用和 execution 狀態。你可以保留既有的 n8n 節點排錯文章作為下一層檢查，例如 Code 節點資料過濾沒有生效 或 Merge 搭配 Loop 的資料合併問題。

若是新版本才出現的錯誤，先把版本、node、workflow execution ID 和 log 一起記錄，再回查官方 release，而不是先刪除 workflow 重建。

2.39.1 要怎麼測，才不會混進正式環境#

如果你需要驗證 2.39.1 的預覽修正，使用另一個測試 image 或隔離專案：

1
services:
2
  n8n-preview:
3
    image: docker.n8n.io/n8nio/n8n:2.39.1

測試前先確認：

1. 這個 container 不會連到 production database。
2. webhook、OAuth callback 和 queue Redis／database 都是測試資源。
3. workflow export、credential 和 encryption key 不會覆蓋正式環境。
4. release notes 中的預覽功能有明確的驗證案例。
5. 測試完成後留下「哪些已通過、哪些仍不能使用」的紀錄。

預覽版的價值是提早找出相容性問題，不是把正式環境變成 beta 測試機。若只是需要安全修補與 stable patch，先以 2.38.5 做最小升級，別把 2.39.1 一起帶進來。

回滾計畫要先寫，不要等 migration 失敗才想#

資料庫 migration 可能讓單純降回舊 image 變得不安全，所以回滾不是只把目標 tag 改回舊版。升級前先確認 n8n 官方更新指南對目前版本的 migration 和支援方式，再決定備份還原、停機窗口和資料遺失界線。

至少要能回答：

• 哪個 tag 是目前最後一個已驗證版本？
• 失敗時是還原 database、volume、image，還是只停用一條 workflow？
• Queue Mode 的 worker 是否會繼續消費舊任務？
• webhook 第三方服務是否需要暫停或重新驗證？

升級變更的完成條件應是「測試資料、logs 和主要 workflow 都通過」，不是「Docker Compose 沒有報錯」。

結論：stable 先升，預覽另測#

以 2026 年 9 月 10 日查到的 registry 狀態來看，n8n 2.38.5 位於 latest／stable／rc，2.39.1 位於 beta／next。從 2.23 或更舊版本升級時，先固定 2.38.5、備份資料、對齊所有執行元件，再針對安全公告涉及的 expression engine、Instance AI workflow summary、OAuth DCR，以及 proxy environment、dynamic credential、OAuth、Webhook、AI、MCP 和 Queue Mode 做回歸；需要提前測新功能時，另建隔離環境，不要用 production 資料庫承擔預覽版風險。

常見問題#