n8n 2.35.7 升級怎麼做？先分清 stable、beta 與自架回歸

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

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

1
npm view n8n dist-tags --json

本次查核得到的狀態是：

因此，更新 Docker image 或 package 時不要把 latest、beta、next 混在同一條部署流程：

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

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

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

2.35.7 與 2.36.5 的差異要怎麼看#

兩個版本都在 2026 年 8 月 21 日發布，release notes 的修正範圍很接近，但 release channel 不同：

這裡要分清楚「release note 有修正」和「可以直接放進 production」。2.36.5 的 tag 仍是 Pre-release；如果你只需要穩定頻道的修正，先以 2.35.7 做基準，不要因為預覽版號碼比較新就一起切換。

這次 patch 先驗證 AI Assistant，不要把它當成通用額度更新#

2.35.7 與 2.36.5 的官方 release 都只列出一項核心修正：提高 AI Assistant 模型驗證的 token limit。這個描述指向模型驗證流程，不等於 n8n 的 workflow execution、API rate limit 或外部模型服務配額都增加。

如果自架環境使用 AI Assistant，升級後應在測試資料上重新驗證模型連線、模型識別與初始化流程；如果沒有使用 AI Assistant，仍要照既有的 webhook、schedule、OAuth、MCP 與 Queue Mode 清單回歸，不要因為 patch note 很短就省略部署檢查。

如果你的自架環境透過公司 proxy、反向代理或多層 outbound gateway 呼叫 API，升級時仍要保留 webhook、OAuth 和外部 node 的 HTTPS 測試，不要只確認 container 能啟動。

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

跨過多個 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.35.7
4

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

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

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

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.36.5 要怎麼測，才不會混進正式環境#

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

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

測試前先確認：

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

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

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

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

至少要能回答：

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

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

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

以 2026 年 8 月 24 日查到的 registry 狀態來看，n8n 2.35.7 是 latest／stable 基準，2.36.5 則在 beta 與 next，且 GitHub release 標示 Pre-release。從 2.23 或更舊版本升級時，先固定 2.35.7、備份資料、對齊所有執行元件，再針對 proxy HTTPS、OAuth、Webhook、AI、MCP 和 Queue Mode 做回歸；需要提前測新功能時，另建隔離環境，不要用 production 資料庫承擔預覽版風險。

常見問題#