credit: Nano Banana

n8n 2.0 新功能介紹

2025.12.29 約 8,868 字

n8n 2.0 在 2025 年 12 月正式發布了，這次是難得的大版本（Major Version）更新。這種大版本更新通常都是有重大變更或改版，通常也會伴隨著不相容的更新。如果你正在考慮要不要升級，或是想知道 2.0 到底多了什麼東西，來來來，我幫大家做好功課了。

文章有點長，怕大家沒耐心看完文章，先說我已經把 Zeabur 上的 n8n 模版升級到 2.0 版了：

n8n 2.0 版的環境變數也幫大家調整好了，只要一鍵就能部署最新版本的 n8n，歡迎大家直接使用最新版本的 n8n 來玩玩看新功能，如果有任何問題歡迎在文章下方留言討論。

如果你是要從 1.x 升級到 2.0，可以參考本文最後的「升級注意事項」來完成升級。

n8n 2.0 的亮點功能

n8n 2.0 版加了一些功能，也修正了一些問題，在深入細節之前，我先列出 n8n 2.0 版我個人認為比較重要的兩個功能：

Save/Publish 分離，編輯工作流不再怕手滑，改完確認沒問題再上線
Task Runner，現在 Code 節點可以跑在隔離環境，更安全也更穩定（但也有造成一些設定上的麻煩）

新功能：Save/Publish 工作流程

這是 2.0 最明顯的改變之一，也是我認為很實用的設計。

在 n8n 1.x 時代，如果你有一個正在使用中的工作流，當在編輯這個工作流程的時候並按下「Save」的那個摩門，修改的內容就直接上線了。這代表你正在編輯、測試的半成品，只要手滑或膝反射的按到 Save，就會立刻影響線上運作中的流程，然後說不定就這樣出錯，或是被看到不該被看到的資料。

到了 2.0，n8n 把「儲存」和「發布」分開了：

Save：儲存修改，但不影響線上版本
Publish：確認沒問題後，再把修改推到線上

大家可以在新的介面的右上角看到 Save 跟 Publish 這兩個按鈕，原本的操作流程變成：

打開工作流，開開心心的編輯、組裝工作流節點
隨時按 Save 儲存進度，但這時線上還是跑舊版本
待測試滿意後，再按 Publish 正式上線

每次 Save 都會建立版本紀錄，需要的話可以從「版本歷史」回滾到之前的版本。聽說 n8n 明年還會推出 AutoSave 的功能，有了 Save/Publish 分離，自動存檔才比較安全，不會因為自動存檔就讓半成品上線或讓原本正在運作的流程出錯。

常見問題

Q：為什麼 Publish 按鈕是灰色的，按不了？\
A: 有幾個可能性，例如工作流沒有變更、工作流有錯誤（就是那個可愛的紅色驚嘆號）都會造成 Publish 按鈕沒辦法按。這也不難解決，通常只要滑鼠移到按鈕上，就會有提示說明原因。

Q：編輯中如果有觸發事件進來，會跑哪個版本？\
A：會跑「已發布」的版本。正在編輯的內容不會影響線上執行，直到按 Publish 為止。

Q：編輯到一半，突然有緊急修改要上線怎麼辦？\
A：先 Save 目前的修改，從版本歷史切回已發布版本，做完緊急修改後 Publish，之後再從草稿繼續。

新功能：Task Runner

這個功能對一般使用者來說可能比較不明顯，但對於有用 Code 節點的使用者來說比較有感覺。Task Runner 是 n8n 用來執行 Code 節點的新機制。在 n8n 1.x 時代的 Code 節點的程式碼是直接在 n8n 主程式裡執行的。這種做法的問題是：

如果程式碼有問題（無限迴圈、記憶體洩漏），有可能會拖垮整個 n8n 系統
JavaScript 和 Python（透過 Pyodide）都在同一個行程（Process）裡跑
沒有資源隔離，一個有問題的工作流可能影響其他所有工作流
如果想要使用第三方的 Python 套件，必須把它們打包進 Pyodide，這很麻煩也不靈活

n8n 2.0 版新加入了 Task Runner 機制，讓 Task Runner 把 Code 節點的執行「隔離」出來。程式碼跑在獨立的環境中，而且還是使用原生的 Python 執行程式碼（不再用 Pyodide），就算出問題也不會影響 n8n 主程式。

Pyodide 其實不算是真正的 Python，它是一個在瀏覽器中執行 Python 的專案，原理是 CPython 編譯成 WebAssembly，讓我們可以在瀏覽器裡執行 Python 程式碼。因為它不是真正的 Python，所以 Pyodide 不支援一般 Python 所有的標準函式庫，效能也不怎麼好，就只是勉強能用而已。

回到 Task Runner，新加入的 Task Runner 有兩種模式：

Internal Mode（內部模式）：

在這個模式下，n8n 主程式會將 Task Runner 作為「子行程（child process）」啟動。因為是子行程，Task Runner 會繼承 n8n 的使用者身份（uid）和群組身份（gid），用白話文講就是 Task Runner 和 n8n 有相同的系統權限，n8n 能讀寫的檔案 Task Runner 也能，所以隔離程度較低。

設定簡單，只需 N8N_RUNNERS_ENABLED=true（這也是預設值）
不需要額外的容器或 Redis
不過不支援 Python Code 節點
官方建議：適合開發測試，不建議用於正式環境

External Mode（外部模式）：

在這個模式下，Task Runner 由獨立的 launcher 應用程式管理。這個 launcher 就像是一個「管理員」，平常不會讓 Task Runner 一直跑著佔資源，而是等到有 Code 節點要執行的時候才把 Runner 叫起來工作，工作完閒置一段時間後再自動關掉。這個 Task Runner 會以「Sidecar」形式部署在 n8n 旁邊，Sidecar 是容器部署的設計模式，就像摩托車的邊車一樣，兩個容器並排部署、各自獨立運作但互相協作。

完全隔離的執行環境，即使 Code 節點出問題也不影響 n8n 主程式
完整支援原生 Python（n8n 2.0 移除了 Pyodide，要執行 Python 程式也只能用這個模式）
因為是獨立的容器，所以可對 Task Runner 容器設定獨立的資源限制
官方建議：正式環境一律使用此模式

比較項目	Internal Mode	External Mode
程序隔離	子行程（共用權限）	獨立容器（完全隔離）
Python 支援	不支援	完整支援
設定複雜度	低	較高
適合環境	開發/測試	正式環境（官方建議）

如果你是使用 Docker 進行部署的話，相關的設定大概長這樣：

services:
  n8n:
    image: n8nio/n8n:2.1.4 # 目前最新版本
    environment:
      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - N8N_RUNNERS_AUTH_TOKEN=YOUR-SECRET-HERE

  task-runners:
    image: n8nio/runners:2.1.4 # 版本必須與 n8n 一致
    environment:
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
      - N8N_RUNNERS_AUTH_TOKEN=YOUR-SECRET-HERE # 必須與 n8n 的 token 一致
    depends_on:
      - n8n

這裡要注意的是，Task Runner 的版本必須和 n8n 主程式的版本一致，否則可能會出現不相容的問題。簡單介紹這幾個環境變數的用途：

n8n 主容器

環境變數	說明
`N8N_RUNNERS_ENABLED`	是否啟用（2.0 預設 `true`）
`N8N_RUNNERS_MODE`	`internal`（預設值）或 `external`
`N8N_RUNNERS_AUTH_TOKEN`	認證 token（external 必填）
`N8N_RUNNERS_BROKER_LISTEN_ADDRESS`	Broker 監聽位址（external 要設 `0.0.0.0`）
`N8N_RUNNERS_MAX_CONCURRENCY`	同時執行的最大任務數（預設 5）
`N8N_RUNNERS_TASK_TIMEOUT`	任務超時秒數（預設 300）

是說，如果故意把 N8N_RUNNERS_ENABLED 設成 false，那些 Code 節點會發生什麼事？這得看 Code 節點使用的語言：

JavaScript：會改用 vm2 沙箱執行，所以還是能正常執行。
Python (Beta)：理論上會改用 Pyodide 執行，但 2.0 已經移除 Pyodide，所以實際上也跑不了。
Python (Native)：直接報錯，完全不能用

如果確定不會用到 Python，關掉 Task Runner 也沒關係，不過你怎麼知道以後會不會用到呢？反正開著也不會佔多少資源。

Task Runner 容器

環境變數	說明
`N8N_RUNNERS_TASK_BROKER_URI`	Broker 連線位址
`N8N_RUNNERS_AUTH_TOKEN`	必須與 n8n 一致
`N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT`	閒置自動關閉秒數（預設 15）

n8n 升級到 2.0 後，如果原本的 Code 節點在是用 JavaScript 的話應該不會有什麼問題，但如果是用 Python 寫的話，沒有設定 Task Runner 的話執行的時候可能會看到這個錯誤：

Python runner unavailable: Python 3 is missing from this system. Internal mode is intended only for debugging.

這是因為 2.0 移除了 Pyodide，必須用 Task Runner 才能執行 Python 程式碼，設定 External Mode 的 Task Runner 就行了。

Task Runner 的資源消耗？

也許你會好奇額外跑一個 Task Runner 容器會不會吃太多資源。實際上影響不大：

項目	說明
記憶體	Task Runners 大約只會佔用 100 ~ 200MB 記憶體
CPU	閒置時幾乎為零，只有在執行的時候才消耗 CPU 的算力
啟動延遲	約 10 - 50ms（序列化 + 網路傳輸）

除此之外，Task Runner 還有自動關閉機制（N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=15），也就是閒置 15 秒後會自動停止，有新任務時再啟動。所以對於沒在寫 Python 或是偶爾才跑 Python 節點的情況，資源消耗是很低的。

修正、加強

修正：Human-in-the-Loop

這是一個困擾很多人的問題，我也遇過一次，但後來用別的方法繞過去，這在 2.0 版修好了！問題是什麼？假設你有這樣的架構：

主工作流：處理某個流程，中間需要人工審核
子工作流：發送 Slack 訊息給審核者，等待回應，然後回傳結果

在 1.x 版，如果子工作流裡有 Wait 節點，主工作流收到的結果會是錯的，因為它會收到子工作流「進入等待狀態時」的資料，而不是「等待結束後」的資料。在 2.0 版，主工作流會正確等待子工作流完全執行完畢，然後收到最終的輸出結果。這對於需要人工審批的流程特別重要：

主工作流收到請假申請
呼叫子工作流，發 Slack 訊息給主管
子工作流等待主管點擊「核准」或「拒絕」
子工作流把審批結果回傳給主工作流
主工作流根據結果繼續處理

在 1.x 版的時候步驟 4 會出問題，但在 2.0 版這個流程終於能正常運作了。

SQLite 效能大幅改善

如果你用 SQLite 作為 n8n 的資料庫，n8n 2.0 版帶來的效能提升會很明顯。新的 SQLite pooling driver 使用 WAL 模式和連線池，根據官方測試的結果寫到：

The new SQLite pooling driver alone can be up to 10x faster in our benchmarks. Filesystem-based binary data handling is more predictable under load. And task runners, while primarily a security feature, also provide better isolation and resource management.

效能最高可以提升 10 倍！剛好在 Zeabur 上我有準備另一個比較輕量的 n8n SQLite 模版（n8n-sqlite-template），我也同步把它升級到 2.1.4 版，大家可以試試看。

檔案資料處理

在 n8n 裡，圖片、PDF、Excel 這類非純文字的資料統稱為「二進位資料（Binary Data）」。在 1.x 版，在處理這些檔案資料的過程預設是存在記憶體裡，方便是方便，但處理大檔案的時候容易因為記憶體不足而出問題。2.0 把這個模式移除了，改成根據執行模式自動選擇：

模式	儲存位置	適用場景
`filesystem`	硬碟（預設 `~/.n8n/binaryData`）	單機部署（一般模式預設）
`database`	資料庫	多機部署（Queue Mode 預設）
`s3`	S3 相容儲存	大量檔案、需要共享存取（需付費授權）

如果沒特別需求的話，用預設的 filesystem 模式就行了。如果你是用 Queue Mode 的多機部署，預設會改成 database 模式，把檔案存在資料庫裡，這樣多台 n8n 主機可以共享存取檔案。

UI/UX 改進

節點跟場景 Canvas 視覺更新，工作流編輯器的畫布做了細微調整，節點的 Icon 看起來更精緻，這滿好的。但我個人沒有特別工作運轉中的效果，我覺得原本會轉轉轉的節點圖示比較有在「工作」的感覺。
側邊欄重新設計，導覽選單重新整理過，更容易找到需要的功能，但這需要一點時間適應。

安全性強化

2.0 的核心理念是「Secure by Default（預設安全）」，簡單說就是收緊各項預設值，讓 n8n 開箱即用時更安全。以前很多功能預設都開著，現在反過來，有風險的功能預設關閉，需要的話再自己打開。幾個比較主要的變更：

項目	1.x 預設	2.0 預設
Task Runner	關閉	開啟
Code 節點存取環境變數	允許	禁止
ExecuteCommand 節點	啟用	停用
LocalFileTrigger 節點	啟用	停用
OAuth callback 認證	不需要	需要
設定檔權限檢查	無	0600

這些變更的具體影響和對應的環境變數設定，在後面的「環境變數變更」小節會詳細說明。對我來說比較麻煩的是 ExecuteCommand 跟 LocalFileTrigger 這兩個節點被預設停用了，因為我有一些工作流（例如用來備份的）就剛好有用到這兩個節點，必須手動把它們打開才行。

升級注意事項

被移除的功能

Start Node

如果你的工作流還有舊的 Start 節點，需要替換：

手動執行 → 改用 Manual Trigger
被其他工作流呼叫 → 改用 Execute Workflow Trigger

這個影響不算太大，Manual Trigger 很早就存在了，我猜可能有些人連 Start 節點用都沒用過，我開始用 n8n 的時候就已經直接用 Manual Trigger 了，Start 節點在 2.0 正式移除應該沒什麼感覺。

不再支援 MySQL/MariaDB

n8n 2.0 不再支援使用 MySQL 或 MariaDB 作為資料庫後端。如果你目前使用這兩種資料庫，要升級到 2.0 的話需要先遷移到 PostgreSQL 或 SQLite。這是指 n8n 自己用的資料庫，MySQL 節點還是可以正常使用。

不過目前我放在 Zeabur 上的 n8n 模版的資料庫是用 PostgreSQL 或 SQLite 的，所以如果你是用 Zeabur 部署的話，這個問題就不會發生。

`--tunnel` 選項

n8n --tunnel 是一個方便開發者在本機測試 webhook 的功能。當你在本機跑 n8n 的時候，外部服務（像 Slack、GitHub）沒辦法直接連到你的 localhost，所以就沒辦法測試 webhook 觸發的工作流。--tunnel 會自動建立一個臨時的公開網址，讓外部服務可以透過這個網址把請求轉到你本機的 n8n。

可惜這個方便的功能在 2.0 被移除了，如果有需要的話可以用其他替代方案，例如 ngrok、localtunnel、Cloudflare Tunnel，我自己推薦 Cloudeflared。

環境變數變更

安全性相關（預設值改變）

這些是前面「安全性強化」提到的變更，如果升級後遇到問題，可以透過環境變數調整：

環境變數	說明	1.x 預設	2.0 預設
`N8N_BLOCK_ENV_ACCESS_IN_NODE`	Code 節點和表達式能否讀取 `process.env`	`false`	`true`
`NODES_EXCLUDE`	停用的節點清單，2.0 預設停用 ExecuteCommand 和 LocalFileTrigger	無	包含這兩個節點
`N8N_SKIP_AUTH_ON_OAUTH_CALLBACK`	OAuth callback 是否需要認證	`true`	`false`
`N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS`	檢查設定檔權限是否為 0600	`false`	`true`
`N8N_RUNNERS_ENABLED`	啟用 Task Runner	`false`	`true`

如果你的工作流因為這些變更而出問題，可以這樣調整：

Code 節點需要讀環境變數 → N8N_BLOCK_ENV_ACCESS_IN_NODE=false
需要用 ExecuteCommand 或 LocalFileTrigger → NODES_EXCLUDE=[]（空陣列）
用 embed 模式的 OAuth → N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true
Windows 設定檔權限問題 → N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false

被移除的環境變數

N8N_CONFIG_FILES：以前可以用這個變數指定額外的設定檔路徑，讓 n8n 讀取裡面的設定。2.0 移除了這個功能，現在統一用 .env 檔案，或是用 _FILE 後綴的方式（例如 DB_POSTGRESDB_PASSWORD_FILE=/run/secrets/db_password）來載入敏感設定。
QUEUE_WORKER_MAX_STALLED_COUNT：這是 Queue Mode（多機部署）用的設定。當一個任務被 worker 拿去執行但沒正常完成（例如 worker 當掉），這個任務會被標記為「停滯（stalled）」。這個變數原本是設定一個任務最多可以被重試幾次，2.0 移除了這個重試機制。

新增的環境變數

N8N_RESTRICT_FILE_ACCESS_TO（預設 ~/.n8n-files）：限制 n8n 可以存取的檔案目錄。為了安全性，n8n 只能讀寫這個目錄下的檔案，避免工作流存取到系統其他敏感檔案。
DB_SQLITE_POOL_SIZE（預設 3）：SQLite 連線池大小。連線池是一種效能優化技術，預先建立一些資料庫連線放在「池子」裡，需要的時候直接拿來用，不用每次都重新建立連線，這個變數可以用來設定在這個池子裡最多放幾個連線。

遷移步驟

使用遷移報告工具

n8n 提供了遷移報告工具，可以幫你檢查升級前需要處理的問題。

使用方式：

確保 n8n 版本是 1.121.0 或更高
用管理員帳號登入
進入 Settings > Migration Report

報告會列出：

Critical：一定要在升級前修好
Medium：可能造成非預期行為
Low：棄用警告，不會立即出問題

建議的升級流程

先升級到 1.121.0 以上，使用遷移報告工具
處理 Critical 問題：替換 Start 節點、移除已停止服務的節點、資料庫遷移
調整環境變數（如果需要）
測試 Task Runner：在 1.x 先啟用 N8N_RUNNERS_ENABLED=true 測試
升級到 2.0

1.x 支援時程

n8n 官方會在 2.0 發布後繼續支援 1.x 版本 3 個月（安全性更新和 bug 修復）。

小結

n8n 2.0 不算是「砍掉重練」或是加了一大堆功能的新版本，比較像是一個「強化」版本。官方的態度也很誠實沒有在官網上大吹特吹，與其說是新功能發布更像是還技術債，把過去兩年累積的安全問題、效能問題、舊程式碼一次清掉。

對於現有用戶來說，最需要注意的是：

Save/Publish 分離的新工作流程
Task Runner 預設開啟可能會造成 Python 節點無法執行
SQLite 的效能大幅提升
一些環境變數的預設值改變

升級前跑一次 Migration Report，按照它的指示處理問題，基本上就不會有太大的問題了 :)

n8n 2.0 的亮點功能

新功能：Save/Publish 工作流程

常見問題

新功能：Task Runner

Internal Mode（內部模式）：

External Mode（外部模式）：

n8n 主容器

Task Runner 容器

Task Runner 的資源消耗？

修正、加強

修正：Human-in-the-Loop

SQLite 效能大幅改善

檔案資料處理

UI/UX 改進

安全性強化

升級注意事項

被移除的功能

Start Node

不再支援 MySQL/MariaDB

--tunnel 選項

環境變數變更

安全性相關（預設值改變）

被移除的環境變數

新增的環境變數

遷移步驟

使用遷移報告工具

1.x 支援時程

小結

參考資源

留言討論

`--tunnel` 選項