n8n 2.40.5 要升級嗎？stable、beta 與 2.41.0 RC 的檢查清單

2026-07-13

2026-09-23

工具推薦

n8n

/

工作流程自動化

/

AI

/

開發工具

/

自動化

截至 2026 年 9 月 23 日，npm registry 查到的 n8n dist-tags 是：latest、stable 與 beta 指向 2.40.5，next 與 rc 指向 2.41.0。這個結果與「stable、beta 一定是不同版本」的直覺不同，也代表升級前應該讀 registry 的實際標籤，不要只看 Docker 的 latest。

本文把 n8n 2.40.5 當成目前的 production 候選，並把 2.41.0 當成獨立的預發布測試線。版本與 security advisory 都可能變動；文中的版本判讀是查核日的快照，不是永久承諾。

先確認你要升級的是哪一條線#

先在自己的環境重新查詢：

1
npm view n8n dist-tags --json
2
npm view n8n@latest version time
3
npm view n8n@next version

用途	查核時的版本	建議做法
production self-hosted	2.40.5	固定完整版本，先在 staging 驗證再部署
想追蹤下一版	2.41.0	只放在隔離環境，不能和 production 共用未驗證資料庫
Docker 部署	`n8nio/n8n:2.40.5`	固定 image tag，並記錄 digest；不要用 `latest` 當回滾點
npm／pnpm 啟動	`[email protected]`	將版本寫進 lockfile，升級時檢查 lockfile diff

GitHub 的 2.40.5 release note 顯示這是一個 bug-fix release，內容包含限制 declarative routing 在 base URL ownership check 中的處理。它不是「所有 n8n security advisory 都已修好」的證明；穩定標籤與資安修補是兩個要分開驗證的問題。

先保存可回復的基準#

n8n 的資料不只在 workflow JSON。升級前應把下列項目列入同一張 change checklist：

n8n database 與 schema migration 的備份。
credentials、encryption key、webhook base URL 與反向代理設定。
active／inactive workflow、執行紀錄保留策略與 queue worker 設定。
custom node、community node、外部 binary 與環境變數。
現在的 n8n image digest、Node.js runtime、資料庫版本與部署 manifest。

如果 workflow 會處理外部 API，先在 staging 跑一條從 trigger 到最後一個 side effect 的測試流程；只確認 editor 可以開啟，不能證明 webhook、credential 和 retry 行為都正常。像是 n8n Code node 的資料過濾陷阱這類 workflow 行為，也應在升級後重新確認輸入型別與輸出資料形狀。

2.40.5 升級時要測哪些邊界#

Base URL、webhook 與反向代理#

因為 2.40.5 的 release note 涉及 base URL ownership check，升級後應至少測試：

editor 的公開網址與 webhook URL 是否仍使用同一個 host、scheme 和 path。
反向代理轉送 Host、X-Forwarded-Host、X-Forwarded-Proto 的方式是否一致。
webhook 在外部網路請求時能否正確到達 active workflow。
queue worker、主程序與 editor 看到的 base URL 是否一致。

不要只在內網打開 editor；用實際的公開 webhook 發送一個不會造成不可逆 side effect 的測試事件，再檢查 execution status。

Database、queue 與執行紀錄#

若使用 PostgreSQL、queue mode 或多個 worker，升級流程應分開驗證：

1
備份 database → 更新 staging image → 啟動主程序 → 確認 migration
2
→ 啟動 worker → 執行無副作用 workflow → 測 webhook → 觀察 queue 與 error

重點是確認 worker 和主程序沒有使用不同版本的 image，也沒有因為 migration 尚未完成就開始消費工作。升級期間若必須暫停 workflow，先確認外部 webhook 的重試策略，避免恢復後重複建立資料。

Credentials、community node 與外部依賴#

把 credentials 解密、OAuth refresh、HTTP request、檔案讀寫和 community node 各選一個代表流程。若版本升級伴隨 Node.js 或 image base 的變更，再加上原生依賴與 binary 的 smoke test。

不要把「workflow JSON 可以匯入」當成完整相容性測試；真正要比對的是 node 的輸入、輸出、錯誤分支和 side effect。

不能省略的 security advisory 查核#

n8n 公開 security advisories 頁面在 2026 年 9 月 16 日附近列出多筆新公告，嚴重度涵蓋 high 與 moderate。這些公告的受影響版本、修補版本和利用前提各不相同，不能從「目前是 stable」推導出「沒有風險」。

每次升級前使用以下流程：

打開 n8n 的 published security advisories，依公告逐筆查看 affected versions、patched versions 和 workaround。
將目前的 2.40.5 與公告的版本範圍比對；若範圍不清楚，先不要把 production 當成已完成修補。
確認公開 editor、webhook、credential test endpoint、community package 與 database query 等暴露面是否真的存在。
對高風險公告留下「已修補、已降低暴露面或接受風險」的決策紀錄。

這一段需要依公告內容逐筆判讀；本文只完成 advisory index 的存在與查核路徑確認，沒有把每一筆公告的影響範圍誤寫成 2.40.5 的保證。

一個可以回滾的部署順序#

推薦把變更拆成小步驟：

記錄目前 image digest、dist-tag 查詢結果、database backup 與設定檔 checksum。
在 staging 固定 2.40.5，完成 migration、登入、credential、queue、webhook 和代表性 workflow 測試。
先更新一個 canary worker 或低流量 instance，觀察 error rate、queue latency、execution failure 與 webhook response。
確認無異常後，再更新其他 worker 和主程序；每一個 process 都要使用同一個版本。
若發現問題，停止擴大部署，保留 log 與 execution ID，回到上一個已驗證的 image／package 版本。

不要在沒有 database backup 的情況下直接 downgrade。若 migration 改變 schema，回退可能需要官方相容性說明或從備份還原；「把 tag 改回去」本身不是 rollback plan。

2.41.0 要不要現在試？#

可以，但應把它視為另一個測試目標，而不是 2.40.5 的小 patch。使用 npm view n8n@next version 或 npm view n8n dist-tags 重新確認預發布版本，建立隔離 database 與 encryption key，並禁止它接收 production webhook。

如果目標只是取得 2.40.5 的 bug fix，不需要因為 next 有新版本就一起升級。預發布線的價值在於提前發現相容性問題，不是替 production 省略 staging。