n8n 免費嗎？自架 Community 與 Enterprise 限制

n8n 可免費自行託管嗎？

可以，n8n 可免費自行託管。您可以在自己擁有的伺服器上執行 community edition，授權條款不限制您建立的工作流程數量，也不限制工作流程的執行頻率。是否適合使用這個免費版本，取決於兩點：n8n 並不符合 Open Source Initiative (OSI) 對「開放原始碼」的定義；此外，部分特定功能在您付費取得 licence key 前會維持停用狀態。

n8n 採用 Sustainable Use License, version 1.0。原始碼公開，您可以閱讀、執行及修改。但此授權限制的是您可以使用它提供服務的對象。您可以為自己或自己的公司執行 n8n，但不得將其製作成供他人付費使用的產品。

Fair-code 的定義，以及 n8n 為何不是開放原始碼

Fair-code 是 n8n 對自身模式採用的標籤。它描述的是一種軟體：原始碼公開，且可自由執行，但作者限制其商業用途。n8n 的文件直接說明了這個用詞的原因：OSI 核准的開放原始碼授權條款不能限制軟體的使用方式，而 Sustainable Use License 正好包含這類限制。因此，n8n 不稱自己為開放原始碼軟體。

這項區分並不只是文字問題，也會影響採購團隊。若政策寫著「我們部署開放原始碼工具，或已購買的工具」，n8n 就會落在第三類，必須由相關人員實際決定如何處理。進行討論前，先閱讀 n8n 儲存庫中的授權條款檔案，不要等到討論後才查看。

Sustainable Use License 允許的使用方式

授予的權限本身相當廣泛。此授權授予您非專屬、免權利金、全球性的授權，讓您得以使用、複製、散布、提供他人使用及製作本軟體的衍生著作，使用目的可以是內部業務或個人非商業用途。

實務上包括：

• 在您自己的伺服器上執行 n8n，供您自己的公司使用，例如將 CRM（客戶關係管理系統）的資料同步至內部資料庫。
• 在家中執行 n8n，供個人專案使用。
• 修改程式碼，並執行修改後的版本。
• 為您自己的產品撰寫 n8n 節點，或開發產品與 n8n 之間的其他整合。
• 銷售顧問服務，例如為客戶建立工作流程。
• 銷售支援服務，例如在客戶擁有的伺服器上設定及維護 n8n。
• 將 n8n 作為產品內部不對外顯示的後端使用，但前提是 n8n 使用您公司自己的憑證。

此授權不會限制您的使用量。沒有執行次數配額，也沒有使用者席次上限，因此自架執行個體的唯一上限，就是執行該執行個體之機器的 CPU 與記憶體。AI 節點也不受限制，因此 在 n8n 中建立 AI 代理工作流程可使用免費版本。

永續使用授權不允許的行為

限制條款很精簡，n8n 在永續使用授權頁面中列出相關範例：

• 託管 n8n，並向他人收費以使用該服務。
• 對 n8n 進行白牌化，並向客戶收費提供。
• 使用 n8n 收集終端使用者本人的認證資料，讓他們存取自己在其他服務中的帳戶。
• 修改、移除或隱藏任何授權、著作權或其他聲明。
• 進行商業散布。只有以非商業目的免費散布才獲得允許。

第三項限制最容易讓人意外，因此請仔細閱讀兩次。使用公司自己的 API keys 搬移公司自己的資料的帳務工作屬於內部使用，這是允許的。如果產品讓每位客戶透過你的 n8n instance 連結自己的 Google 帳戶，則不符合規定，因為授權條款是依 n8n 持有誰的認證資料來劃定界線。兩種情況使用的是相同的軟體與伺服器，但結果不同。

同一個 repository 中還有第二種授權。檔名包含 .ee. 的任何原始碼檔案，或其目錄路徑包含 .ee 的任何原始碼檔案，都不適用永續使用授權，而是受另一份 n8n Enterprise License 規範。這些程式碼會隨你拉取的相同 Docker image 一起提供，因此付費功能已包含在 build 中，但會保持停用狀態，直到有效的 key 將其啟用。以其他方式啟用這些功能屬於違反授權，不是設定技巧。

fair-code 與 MIT 及 AGPL 的差異

MIT 授權允許所有用途，包括取得程式碼並銷售其託管版本；唯一真正的條件是標示著作權與授權資訊。

AGPL（GNU Affero General Public License）同樣允許銷售託管版本。其條件是公開修改內容：如果你修改軟體，並讓使用者透過網路存取該軟體，就必須向這些使用者提供修改後的原始碼。

Sustainable Use License 採用不同的限制方式。它不要求你公開修改內容，而是限制你可以服務的對象。簡單來說，AGPL 規範你必須公開哪些內容，Sustainable Use License 則規範你可以銷售給哪些對象。

這項差異會決定 fork 的結果。任何人都可以 fork AGPL 專案，並將其作為競爭性的託管服務執行，但前提是必須公開修改內容。n8n 則不允許這種做法，因為使用限制會隨程式碼進入每一份複本。這就是 n8n 可以公開完整原始碼，同時銷售 cloud 產品，而不必與自身的複製品競爭的原因。

哪些功能需要付費授權金鑰

社群版包含幾乎完整的產品功能。n8n 列出的是排除項目，而不是包含項目，這種方式更實用。截至 2026 年 8 月，版本比較頁面將以下功能列為付費功能：

• 透過 SAML（security assertion markup language）或 LDAP（lightweight directory access protocol）提供 SSO（single sign-on）
• 共用工作流程與憑證
• 專案
• 自訂變數
• 環境
• 使用 Git 進行版本控制
• 外部 secrets
• 二進位資料的外部儲存
• 日誌串流
• Multi-main mode

多數團隊最先遇到的限制是共用功能。單獨評估工具時，很容易忽略這項限制。在社群版中，只有執行個體擁有者，以及建立工作流程或憑證的使用者可以開啟該項目。同一個執行個體中的兩位同事，無法在介面內互相轉交工作流程。團隊通常以共用登入帳號因應，但這會失去變更追蹤，無法得知誰修改了什麼。

第二項是 SSO。如果公司要求所有內部工具都使用 single sign-on，社群版從第一天起就不符合要求，不論其他功能是否足夠。在這類產品中，免費自架應用程式將驗證功能列為付費功能的情況反覆出現；自架應用程式的 SSO 稅說明了供應商為何總是在相同位置劃線。

實務上，環境與 Git 版本控制算是同一項功能。兩者結合後，可以將工作流程保存在 repository 中，並從開發執行個體部署到正式執行個體。沒有這些功能時，必須手動將工作流程匯出為 JSON，再於另一端匯入。這種方式可行，也有許多人這樣做，但沒有審查步驟，也沒有歷程記錄。

Multi-main mode 是限制擴充能力的功能。社群版可以正常使用包含多個 worker process 的 queue mode。但無法執行多個 main process。main process 負責排程與 webhooks，因此仍是單一故障點。沒有授權金鑰，就無法讓它具備備援能力。

日誌串流與外部 secrets 屬於合規功能。日誌串流會將 n8n 的事件日誌推送到既有的監控系統。外部 secrets 會從 vault 讀取憑證，而不是使用 n8n 自有的加密儲存區。這兩項功能通常是工具投入正式環境數個月後，才會在資安審查中被要求。等到那時才發現價格，時機會很尷尬。

如果受限制的功能正是你實際需要的功能，而方案超出預算，請比較其他工具，不要與授權限制周旋。自架 n8n 替代方案值得並列閱讀，因為每個專案對免費功能的界線都不同。

註冊您的社群執行個體以取得免費授權金鑰

部分免費功能仍需要授權金鑰。在了解流程後，這並不矛盾。註冊電子郵件地址即可取得免費金鑰，並免費解鎖另外三項功能：

• 資料夾，用於整理工作流程
• 編輯器中的偵錯功能，工作流程期間會複製並固定執行資料
• 自訂執行資料，用於儲存及註解執行中繼資料

取得金鑰的步驟如下：

1. 開啟編輯器左下角的三點選單。
2. 前往 Settings，再選擇 Usage and plan。
3. 選取 Unlock，再選擇 Send me a free license key。
4. 將電子郵件中的金鑰貼到 Enter activation key，然後選取 Activate。

如果伺服器是透過檔案設定，請略過介面，並在首次啟動前將金鑰設定為環境變數。

docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 \
  -e N8N_LICENSE_ACTIVATION_KEY="paste-your-key-here" \
  -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

在連接埠 5678 開啟編輯器，然後檢查 Settings，再選擇 Usage and plan。該頁面應顯示您的方案名稱，而不是解鎖提示。如果提示仍然存在，通常是因為執行個體先前已完成啟用：N8N_LICENSE_ACTIVATION_KEY 對已持有授權的執行個體不會產生作用，因此將它加入現有容器的環境變數後，可能看起來完全沒有變化。

正式環境伺服器還有另外兩個重要的授權變數。N8N_LICENSE_AUTO_RENEW_ENABLED 預設為 true。將它設為 false 後，您必須每十天從設定選單手動續期，否則授權功能會停止運作。N8N_LICENSE_DETACH_FLOATING_ON_SHUTDOWN 也預設為 true；執行個體關閉時會釋放授權，讓其他執行個體可以取得授權。若正式環境執行個體會在部署期間重新啟動，請將它設為 false，讓授權功能隨執行個體一同恢復。這兩項設定均記載於管理授權頁面。

雲端方案的定位

n8n Cloud 在 n8n 自有基礎架構上執行相同的軟體。方案依工作流程執行次數計費，而不是依啟用中的工作流程數量計費。因此，等待 webhook 且處於閒置狀態的工作流程，在觸發前不會產生費用。

對自行代管者而言，重要的是企業授權金鑰會隨方案提供，而不是單獨銷售。購買 Business 或 Enterprise 方案後，您會收到金鑰，再將該金鑰貼到執行於自有硬體上的執行個體中。自行代管與付費並不互相衝突。

截至 2026 年 8 月，入門級方案在 n8n pricing page 上公布了每月價格。較高階的方案須透過銷售團隊洽詢，Enterprise 方案則完全未公布價格，因此此處列出的任何金額，在您讀到時可能已經過時。請索取報價，並明確詢問報價是否包含自行代管金鑰。

如果您仍在自行執行與付費使用代管自動化產品之間做選擇，n8n 與 Zapier 及 Make 的比較會從成本結構而非功能清單進行分析。

在自有產品中銷售 n8n

如果客戶會看到並使用 n8n 編輯器本身，就需要 embed license。n8n 也會將此授權以 OEM（original equipment manufacturer）協議的形式提供。該協議允許 Sustainable Use License 所禁止的白標與轉售。這是需協商的合約，採報價制，主要對象是將工作流程自動化功能整合至既有產品中的公司。

將 n8n 作為隱藏的後端是另一種情況，不需要此類協議。如果工作流程使用貴公司的認證資料執行，且使用者從未接觸編輯器，標準授權即可涵蓋。區分兩者的關鍵在於認證資料與編輯器，而不是營收。

那麼，您需要哪個版本？

如果是一家公司執行自己的自動化流程，且同事彼此可以查看工作內容，community edition 就已經足夠。註冊以取得免費金鑰，然後開始建立流程。下一步是準備伺服器；使用 Docker 和 HTTPS 在 VPS 上自行託管 n8n 涵蓋部署、反向代理與憑證設定。

如果公司需要單一登入，或需要分開的開發與正式環境，community edition 無法滿足這些需求，修改設定也無法解決。請評估 Business plan，或選擇授權條款符合預算的工具。

如果要向其他人銷售存取權，應與 n8n 洽談商業協議。越早開始洽談，成本越低。

FAQ

n8n 是開放原始碼嗎？

不是。n8n 屬於 fair-code，採用 Sustainable Use License 發行。其原始碼公開，您可以閱讀、執行及修改，但該授權條款限制使用方式；而 OSI 認可的開放原始碼授權不得包含使用限制。n8n 在自有文件中也如此說明，並改稱其為 source available。檔名含有 .ee. 或路徑含有 .ee 的檔案，甚至不適用該授權，而是受個別的 n8n Enterprise License 規範。

我可以向客戶收取與 n8n 相關工作的費用嗎？

可以，但限於服務。為客戶建立工作流程不需要另行簽署協議，為客戶擁有的伺服器安裝或維護 n8n 也不需要。您不能向他人收取存取由您執行之 n8n 實例的費用，也不能銷售白標版本。判斷標準是對方付費購買的是您的工作，還是軟體的存取權。

為什麼我的團隊無法在 self-hosted community edition 中共用工作流程？

工作流程與憑證共用屬於授權功能，沒有付費金鑰時會停用。在 community edition 中，只有實例擁有者與建立項目的使用者可以開啟該項目，因此無法在介面中將工作流程交給同事。將工作流程匯出為 JSON，再由其他帳戶匯入即可使用，但憑證不會包含在匯出內容中，且匯入的副本會成為獨立工作流程，擁有自己的執行歷史記錄。

如果我的 n8n 實例無法連線至授權伺服器，會發生什麼事？

已啟用的實例預設會向 https://license.n8n.io/v1 更新授權，而 N8N_LICENSE_AUTO_RENEW_ENABLED 預設為 true。若您關閉自動更新，必須每 ten days 從設定選單手動更新，否則授權功能會停止運作。若對外連線防火牆阻擋授權伺服器，請使用小寫的 https_proxy_license_server 變數，透過 proxy 傳送要求，不要停用更新功能。

我必須付費才能移除 n8n 品牌標示嗎？

如果客戶會看到結果，就必須付費。Sustainable Use License 禁止變更、移除或遮蔽授權與著作權聲明，並明定將 n8n 白標化後銷售給客戶，是不允許的使用方式。若要重新命名您銷售的產品，必須簽署 embed 或 OEM 協議。若只供自有員工使用，調整實例外觀涉及的問題較小；但無論面向何種使用者，授權與著作權聲明相關條款都同樣適用。