Dify VPS Docker Compose 自架教學

Dify 是什麼，以及你即將執行的服務

Dify 是一個可自行託管的平台，用於建構以大型語言模型為基礎的應用程式。它提供網頁介面，讓你設計聊天應用程式、代理程式與檢索流程；也提供 API，讓你從自有程式碼呼叫這些功能，並集中管理提示、資料集與模型金鑰。小型團隊可以架設這類工具，讓所有人以同一個私有基礎環境進行開發，而不必將 API 金鑰分散在各個指令碼中。如果你仍不熟悉 agent、tool call 與 retrieval pipeline 等概念，先從頭了解這些概念，能讓 Dify 的建構介面看起來像熟悉的控制項，而不是一面沒有標示的開關牆。

自行執行 Dify，表示你需要執行許多元件。截至 2026 年 10 月，Dify 文件所述的預設堆疊會啟動 15 個長時間執行的容器，另有一個只執行一次、負責設定檔案權限後結束的工作。其中 7 個是 Dify 自有服務：API server、websocket server、background worker、scheduler、web frontend、plugin daemon，以及 agent backend。另外 8 個是相依服務：Postgres database、Redis cache、Weaviate vector database、nginx front door、2 個 code sandbox，以及 2 個 SSRF proxy。Docker Compose 會將這些元件串接起來，但這確實是一套完整的堆疊；Dify 文件所述的最低需求是 4 GiB RAM 與 2 個 CPU core。如果這台 VPS 也要執行其他服務，應根據實測數據進行規劃，而不是只看官方公布的數值，因為PhotoPrism 與 Immich 實際所需的 RAM 下限遠高於其公布的最低需求；共用同一台主機的相片伺服器，會先耗盡 Dify database 與 vector store 的資源。CPU 競爭也會造成相同問題：將 Jellyfin library 改造成 90 年代的錄影帶店，只瀏覽 artwork 時幾乎不需要額外資源，但只要有人開始轉碼，Dify 的 worker 就會排在它後面等待。好處是，無論你在 Dify 上建構多少應用程式，容器數量都維持固定；相較之下，OpenBot 會為每個 AI coworker 配置各自的 container 與 browser，每增加一名成員，RAM 下限就會再次上升，Dify 的資源成本曲線較為平緩。

由於 Dify 會保存你的 model API keys，以及你載入供檢索使用的私有文件，從啟動服務的第一分鐘起，就應將執行它的主機視為敏感系統。本指南會先安裝 Dify，再依照保護任何保存 secret 的服務的方式強化其安全性。

先決條件

您需要一台執行 Ubuntu 24.04 的 VPS，至少具備 4 GiB 記憶體與 2 個 CPU 核心，並已安裝 Docker 及 Docker Compose plugin（Dify 需要 Compose 2.24.0 或更新版本）。此外，您需要具備 sudo，或是屬於 docker 群組的使用者。下方的 clone 指令也會使用 git、curl 與 jq。如果您不熟悉 Docker，VPS 上的 Docker Compose 基礎涵蓋本指南所需的安裝方式與核心指令。建議準備一個指向該伺服器的網域名稱，因為您會希望在 Dify 前方使用 TLS，而不是直接使用裸 IP 位址。

取得 Dify 與其 Compose 檔案

Dify 將 Docker 設定放在主儲存庫中。請複製最新的發行版本，不要複製開發分支，然後切換到 docker 目錄：

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

如果複製作業失敗並顯示「Remote branch null」錯誤，表示 GitHub API 查詢沒有傳回結果；請從 releases 頁面選擇版本，並手動將版本傳給 --branch。

.env 檔案是核心設定。開始任何操作前，請先閱讀此檔案。最先需要處理的是設定密碼與 secret 的值：SECRET_KEY、Postgres 密碼和 Redis 密碼。SECRET_KEY 的初始值為空白；如果保留空白，Dify 會產生金鑰，並將其保存在儲存目錄中。密碼則不同：範例檔案會為 Postgres 和 Redis 設定相同的 difyai123456，也會為 code sandbox、plugin daemon 和 Weaviate 設定固定且公開已知的金鑰。保留這些初始值，是自架 Dify 遭到入侵最常見的原因。若要自行設定 secret key，請先產生一組：

openssl rand -base64 42

將產生的值貼入 SECRET_KEY，並為檔案中的每個密碼與金鑰欄位設定強度高且唯一的值。Redis 密碼也出現在 CELERY_BROKER_URL 中，因此請一併修改，否則 worker 無法連線到 Redis。

步驟 2：啟動

啟動整個 stack：

docker compose up -d

第一次執行會拉取數個映像檔並初始化資料庫，因此請等待約 1 分鐘。確認容器狀態正常：

docker compose ps

每個長時間執行的服務都應讀取 running；一次性的權限處理工作完成後就會結束。Dify 預設會透過隨附的 nginx 容器，在 port 80 提供 Web 介面。第一次造訪 http://YOUR_SERVER/install 時，請建立 admin 帳號。請立即完成這項操作，確保在其他人能連線到該 port 前建立帳號，因為在帳號建立前，任何載入該頁面的人都能取得帳號控制權並擁有你的執行個體。

步驟 3：不要直接暴露服務。先配置 TLS 與防火牆

多數快速安裝流程會在這裡停止，而多數事故也從這裡開始。Dify 內建的 nginx 會在 port 80 上以明文監聽所有介面，也會發布 port 443。您不應讓管理員登入資訊與模型金鑰透過純 HTTP 傳輸，也不應讓外部存取內部服務。

使用預設拒絕的防火牆限制主機，只允許 SSH 與 Web 流量：

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

請注意，只涵蓋 IPv4 的防火牆可能會讓相同連接埠在 IPv6 上保持開放，形成許多自架服務管理者都會遇到的 IPv6 防火牆漏洞。請確認兩種網路協定都受到過濾。此外，Docker 發布的連接埠由 Docker 自己的防火牆規則處理，而不是由 ufw 處理；預設堆疊也會將 plugin daemon 的除錯連接埠 5003 發布到所有介面。除非您確實需要從另一台機器除錯 plugins，否則請在 .env 將 EXPOSE_PLUGIN_DEBUGGING_PORT 設為 127.0.0.1:5003。

至於 TLS，最乾淨的做法是將 Dify 的 Web 連接埠綁定至 loopback，並在前方執行使用 Let's Encrypt 憑證的反向代理，讓公開網際網路上唯一可見的服務是透過 HTTPS 通訊的代理。Dify 的 .env 可讓您變更對外暴露的連接埠；請將其設為綁定在 127.0.0.1，再讓代理指向該連接埠。EXPOSE_NGINX_SSL_PORT 也應採用相同設定，因為 Dify 的 nginx 預設會占用主機的 port 443，而您的代理需要使用該連接埠。在 VPS 上安全執行 AI agent 中的強化 agent 概念同樣適用：將會變動的元件留在 loopback，只公開必要服務，並由單一強化入口處理 TLS。如果某個工具的介面只有您自己需要，且完全不需要憑證，請略過代理，改用 SSH tunnel 存取；自架 open-kritt security scanner 就是讓其儀表板綁定 loopback，再轉送到筆記型電腦，而不是直接發布。若整個團隊都需要使用 Dify，但不希望開放給公開網際網路，overlay network 可將這個做法擴展到單一筆記型電腦之外：將伺服器的私有子網路發布到您的 tailnet，讓每台獲准的裝置都能透過私有位址存取 builder，同時讓防火牆除了 SSH 之外拒絕所有流量。若您是透過 coding agent 而非手動管理這台主機，請在交付權限前先決定它可在無人監督下執行多少操作，因為您為 Claude Code 保留的權限模式會決定它在重寫 .env 或重新啟動堆疊前是否會先詢問。若您最後讓一個工作階段持續監看容器日誌，另一個工作階段編輯代理設定，這兩個工作階段可以在同一台主機上互相傳遞文字，如此每次重新啟動堆疊時就不必在終端機之間反覆複製輸出。

步驟 4：保持修補更新

Dify 更新頻繁，更新內容也包含安全修正。由於您複製的是 release tag，因此更新時應切換至下一個 tag，而不是拉取分支。先備份資料庫，然後從 docker 目錄執行：

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

資料庫遷移會在啟動時自動執行，其中部分遷移無法還原，因此必須先備份。每次升級前都應閱讀 release notes，不要只在進行重大升級時閱讀：Dify 表示，不同 release 的升級步驟可能有所不同。例如，1.17.1 的說明（2026 年 9 月）提醒，若使用內建的 Weaviate 且已有現存資料，不要直接跳到該版本，而應依序完成每個 minor release 的升級。Dify 也會在不同 release 之間變更 .env schema，因此切換至新 tag 後，請先比較 .env.example 與您的 .env，再套用原有變更；因為尚未設定的新變數可能會導致容器無法啟動。

步驟 5：備份無法重新產生的資料

Dify 伺服器上有兩項資料無法替代：儲存應用程式、使用者與設定的 Postgres 資料庫，以及儲存上傳文件和向量索引的磁碟區。兩者都位於 docker 目錄下的 Docker 磁碟區中。請依排程建立快照，並將快照複製到伺服器之外。這些快照會在單一檔案中包含所有模型金鑰和上傳文件，因此在將它們移出伺服器前先加密，理由與Vaultwarden 備份成為原本穩固的密碼伺服器弱點相同。模型 API 金鑰可以重新簽發，但你花費一週建立的應用程式無法重新取得。相同的原則也適用於任何狀態必須在執行該代理程式的機器故障後繼續保留的代理程式：讓 KiroCrew 以持續執行的容器運作，關鍵在於建立記憶與排程的快照，否則下一次重新開機就會消失。

如果你希望在這裡建立的代理程式能搜尋自有資料集以外的即時網頁，將代理程式連線至自行託管的 SearXNG 執行個體，可讓查詢流量留在你控制的硬體上。不過，啟用前應先了解因此開啟的提示注入攻擊面。若需要更具自主性且能執行程式碼的代理程式，請參閱自行託管 Agent Zero；在 VPS 上建立自己的 AI 代理程式則涵蓋所有這些代理程式所需的基礎。

FAQ

自架 Dify 的系統需求為何？

Dify 文件列出的最低需求為 4 GiB RAM、2 個 CPU 核心，以及 Docker Compose 2.24.0 或更新版本。這項最低需求反映預設堆疊的規模：截至 2026 年 10 月，包含 15 個長時間執行的容器，以及 1 個僅執行 1 次的初始化工作。請為上傳的文件與向量索引準備足夠的磁碟空間。如果同一台伺服器還執行其他服務，也需要增加記憶體。

直接在 port 80 對外公開 Dify 是否安全？

不安全。Dify 內建的 Web server 以純 HTTP 監聽，且會處理管理員登入與模型 API keys。請在前方部署搭配 Let’s Encrypt 憑證的反向代理，將 Dify 自身的 port 綁定至 loopback，只讓 HTTPS 代理面向網際網路。另請搭配涵蓋 IPv4 與 IPv6 的預設拒絕防火牆。

如何更新自架的 Dify？

先備份資料庫，然後從 docker 目錄執行 docker compose down、git fetch --tags、git checkout 新的 release tag、docker compose pull 與 docker compose up -d。請先閱讀 release notes，因為不同 release 的升級步驟可能不同，migration 可能無法復原，而且 Dify 有時會新增 .env 變數；缺少該變數可能導致容器無法啟動。

安裝 Dify 後首先要做什麼？

前往 /install，立即建立管理員帳戶。在該帳戶建立前，任何能連到該頁面的使用者都可以取得管理權。請在容器狀態正常後立即完成設定，並在對全世界開放防火牆之前完成。