到目前為止，n8n 一直有兩種主要的部署方式：透過 npm 和透過 Docker。我們正在考慮停止支援原生 npm，並希望聽取您的意見。
希望您在閱讀後能夠填寫此問卷。
我們考慮這樣做的原因
我們正在開發一個功能強大得多的 AI 助手 - 想象一下 Claude Code，但內嵌在 n8n 中。這一直是社區最期待的功能之一，重要的是我們要將其帶到自託管版本。我們的目標是在今年夏天發佈自託管版本。
出於安全考慮，此助手需要一個沙箱。該沙箱需要部署在獨立的 Docker 容器中。這意味著 n8n 將依賴 Docker。因此，標準化採用基於 Docker 的部署是有意義的 - 特別是因為這本來就是一種更可靠的部署方法。
這對基於 npm 的安裝意味著什麼
如果您想升級，您需要確保已安裝 Docker，並改用該方式進行部署。您仍然可以將安裝保持在同一目錄中，並將該目錄掛載到 Docker。我們會提供有關如何執行此操作的指導。
如果我不想要助手，為什麼不能繼續透過 npm 運行其他 n8n 功能？
雖然技術上這是可能的，但產品的不同風格和配置越多，就會引入越多的複雜性和 bug。
遷移至僅限 Docker 還有其他好處；助手只是最直接的一個。這樣做將：
- 加快 n8n 的開發速度
- 使 n8n 更容易支援
- 為未來將其他產品與 n8n 捆綁的可能性打開大門，例如向量資料庫或 Redis。
我們想了解什麼
我們意識到在某些情況下使用 Docker 可能很困難。n8n 的使用方式多種多樣，有些我們甚至可能不知道。因此，我們希望聽取所有人對此主題的意見，無論您目前使用的是 npm 還是 Docker — 請填寫下面的問卷！
問卷連結
11 個讚
我支持這個想法。除了開發節點時，我已經很久沒有使用 npm 安裝 n8n 了。
使用 npm 安裝 n8n 終究會導致問題。Docker 也更安全。
當客戶要求我們管理他們的實例時，如果他們使用 npm，我們總是會勸他們改用 Docker。這樣管理起來會容易得多。
12 個讚
我同意Bram的看法，Docker設定起來簡單得多，速度也更快，而且它有容器功能，可以幫助保護東西的安全。
5 個讚
我支持這個方向。我自己在 Docker 中運行 n8n，之前也短暫嘗試過 npm。穩定性和可維護性的差異是顯而易見的。
讓我信服這個決定的是：嵌入式 AI 助手需要沙箱，而沙箱需要 Docker。這不是武斷的依賴，而是有技術根據的。認真使用 n8n 的人通常已經在運行 Docker。
唯一讓我有所保留的一點是：有些用戶在非常精簡的環境中運行 n8n，例如小型 VPS，資源有限，Docker 相比裸 npm 安裝會明顯消耗更多資源。對於他們來說，清晰的遷移幫助和理想情況下優化的 Docker 映像會很重要。
總的來說：更少的變體意味著更少的 bug 和更快的開發速度。這對整個社群都有好處。
3 個讚
嗯，是時候進入 Docker 兔子洞了，學習 CLI 和 Desktop 教學。
如果某位高手能分享一個完整的 docker 檔案，包括 queue、workers、task runners、postgresql、redis 的範例…我們絕對可以阻止 npm 愛好者未來再這樣做了
P.S 有些人喜歡 npm…有些人喜歡 docker…但最重要的是大家都喜歡 N8N！！！
1 個讚
我同意：Docker 在這裡看起來是更乾淨且更易維護的方案，特別是對於 AI 助手沙箱和長期穩定性而言。
1 個讚
從 npm 升級簡直是噩夢。有很多依賴關係的問題。
Docker 比較容易，雖然會帶來一些開銷。可管理性是關鍵。
+1 贊成用 Docker
1 個讚
支持這個方向。根據我在多個客戶端環境的 VPS 實例上運行 n8n 的經驗，Docker 在 n8n 版本之間的表現明顯比 npm 更穩定——尤其是當 AI 沙箱開始需要獨立進程隔離時。
我想提出一個具體的請求：提供一個針對小型 VPS（1-2 vCPU、1-2 GB RAM）優化的最小單容器 Compose 文件，並附有清楚的文檔說明哪些服務可以禁用以減少開銷。很多自託管用戶在預算有限的 VPS 上運行 n8n，Docker daemon 本身會增加記憶體壓力，所以提供最小可行 Docker 設置的指導將大大降低這些遷移的阻力。
4 個讚
我在 Ubuntu VPS 上通過 MobaXterm 運行 Docker。這個方法有點技術性，但曾經用過的人長期來看可能會更傾向使用它。
Docker Compose + Cloudflare Tunnel 對使用者來說是一個必需的設置 - 備份、維護甚至遷移資料都相當容易。
為 AI 助手提供沙箱環境的要求只是一個額外的好處。
不過，當助手啟動時，目前的 Docker Compose 設置需要做任何改變嗎？還是說它只是一個額外的容器，插入並在同一個系統上運行？
感謝你的透明說明。我同意遷移到 Docker 有一些好處，但也面臨一些技術挑戰，包括本機檔案存取和允許像建立資料夾和檔案這樣的命令操作。目前透過多項調整可以實現這些功能，但加入 Docker 後會變得更加複雜。
另一個可能使事情複雜化的部分是 Docker 授權本身，以及這對某些使用者意味著什麼。
很好的想法，除此之外，npm 上的黑客攻擊名稱不斷增加，所以在 n8n 上工作時可能會損害您的數據。至於在 docker 中安裝 n8n，需要具備一定的技術知識，但是一個人是可以學習的，我自己在 Docker Desktop 上安裝 n8n 時遇到過問題，但我通過在 YouTube 上逐步搜索和向中文 AI Deepseek 提問解決了這個問題。
幸運的是，Coolify 使 Docker 更加用戶友善。檔案訪問存取仍然是難以處理的問題。
1 個讚
在 SaaS 平台上運行自託管的 n8n，支援多租戶 - 完全採用 Docker 優先。多工作程序、隊列模式設定中的所有內容在 main、workers 和 webhooks 容器中的 n8n 版本和運行環境一致時，運行更加可靠。基於 npm 的安裝會在主機作業系統級別產生漂移，導致環境之間出現細微差異，難以進行除錯。AI 助手沙盒化需求只是已經是生產部署正確選擇的方向的自然終點。
這是令人失望的消息 - 我還不是(尚未;-)專家,但我確實試過使用 Docker,它讓我的機器陷入了停滯(Windows 16Gb RAM,本地安裝了 n8n)。當我卸載了 Docker 並回到使用 NPM 時,我能夠真正開始在 n8n 上進行工作,而不是花時間去處理資源瓶頸問題。是的,我可以升級我的機器,但我的一些客戶只有更基本的設置,有時我需要配合他們現有的情況工作。
從我(雖然經驗有限)的角度來看,使用 Docker 似乎為簡單的情況增加了不必要的複雜性和開銷。如果必須出於技術原因使用 Docker,它一定要這麼佔用資源嗎?
2 個讚
根據我的想法，即使非管理員也能安裝 Docker，而且多虧了像 Portainer 這樣的工具，管理也變得輕而易舉。這讓初學者（像我一樣）在不想使用雲端解決方案的情況下更容易上手。
多個選項往往讓許多人在做決定時陷入兩難困境。有時候，讓別人幫你做決定是件好事（我這裡指的是那些只想試試看某個安裝方案的使用者）。
我對 AI 助手的想法感到興奮，我相信它將幫助 n8n 取得巨大進步。
問卷已填完？完成了 
2 個讚
我同意對大多數使用者採取Docker專用的方向，而且精簡、強化、非root預設映像很合理。但它有兩個特性使其難以在NAS/自託管主機（Unraid、Synology等）上良好運行，而且採用Docker專用的方式會將這些從「只需使用npm」變成難以解決的阻礙：
-
無主機UID/GID映射。 映像以固定的node使用者（uid 1000）執行，所以bind掛載的共享在主機上最終會由錯誤的UID/GID擁有。既定的修復方法（LinuxServer.io映像及類似的）是以root身份啟動、進行首次執行設定、然後以從主機提供的PUID/PGID重新映射的使用者身份降級 ——這樣容器就不會破壞共享權限。
-
無套件管理員（apk已移除）。 某些NAS整合在首次執行時需要root加套件管理員——例如Unraid的Tailscale整合使用一個在容器啟動時安裝並設定Tailscale的掛鉤，一旦apk/apt被移除就不可能做到。
重要的是，(1)不能只是目前映像上的一個env旗標：UID重新映射（掛載資料的chown、usermod、透過su-exec/gosu降級）從根本上需要容器以root身份啟動。這是與強化非root預設的故意立場改變——這正是為什麼我認為這應該存在於單獨的映像中，而不是削弱預設的原因。
所以：團隊是否願意考慮官方維護的自託管/NAS變體 ——例如n8nio/n8n:<version>-nas ——它以root身份啟動、重新映射到主機的PUID/PGID、降級權限，並為首次執行掛鉤保留可用的套件管理員？強化預設對其他所有人保持完全相同。
1 個讚
不了，謝謝。我已經從 docker 遷移到裸機了。太多額外的「docker 說」命令，只是為了實現我需要完成的事情。「但 docker 更安全得多！」彷彿駭客不知道 docker 命令和如何繞過這些東西一樣…… 算了……
