Dify 自架教學：在 VPS 上部署 AI Agent 工作流平台，從聊天機器人到 RAG 知識庫

n8n 解決了「把 API 串起來自動跑」的問題，Ollama 解決了「在自己機器上跑 LLM」的問題。但中間還有一塊空白：怎麼讓不會寫程式的人，也能用拖拉的方式組出一個 AI Agent，接上企業知識庫，然後直接發布成聊天機器人或 API？

Dify 就是來填這個空白的。GitHub 上超過 14 萬顆星、每週數千次 commit、2026 年 5 月剛釋出 v1.14.2——它已經不是實驗性質的專案，而是很多團隊正式環境裡的核心元件。

Dify 到底在做什麼

Dify 的核心是一個視覺化的 AI 工作流編輯器。打開瀏覽器、拖幾個節點、連起來，就能組出一條完整的 AI 處理流程：使用者輸入 → 意圖分類 → 查詢知識庫 → LLM 生成回覆 → 輸出。整條流程不用寫一行程式碼。

但它不只是「拖拉工具」。Dify 把幾件事整合進同一個平台：

多模型管理：同時接 OpenAI、Anthropic、本地 Ollama、vLLM，在同一個工作流裡切換模型
RAG 知識庫：上傳 PDF、Markdown、網頁，Dify 自動切片、向量化、建索引，查詢時做混合檢索
Agent 工具箱：內建 50 多種工具（Google 搜尋、DALL-E、程式碼執行沙箱），也能自訂 API 工具
一鍵發布：做好的應用可以直接變成獨立網頁、嵌入式 widget、或 REST API endpoint

這套東西的目標使用者不是工程師（工程師會直接用 LangChain 或 LangGraph），而是產品經理、客服主管、行銷團隊——那些有明確需求但不想碰程式碼的人。工程師的角色變成架好 Dify、設好模型、管好基礎設施，然後讓業務單位自己去組 AI 應用。

跟 n8n 不是同一件事

已經在用 n8n 的人可能會問：n8n 也能接 LLM、也能做自動化，為什麼還要多架一套 Dify？

定位完全不同。n8n 是通用型的工作流自動化工具，強項在「把 400 多種外部服務串起來」：收到 Slack 訊息 → 查 Google Sheets → 呼叫 API → 發 Email。AI 只是 n8n 流程中的一個節點。

Dify 則是「以 LLM 為核心」的應用建構平台。它的重心在 prompt 管理、RAG 管線、對話記憶、模型切換與評估。n8n 的 AI 節點能呼叫一次 LLM，但它沒有知識庫、沒有對話歷史管理、沒有 prompt 版本控制。

實務上的分工是這樣的：Dify 負責建出 AI 應用（客服機器人、文件問答、內容生成器），n8n 負責把這些應用串進業務流程（定時觸發、事件驅動、多步驟審批）。兩者用 API 對接，各做各擅長的事。

架構拆解：Docker Compose 裡到底跑了什麼

Dify 的 Docker Compose 不是一個容器跑天下，而是一整組微服務：

元件	功能	資源占用
`api`	後端 API 服務（Python/Flask）	中
`worker`	非同步任務處理（文件索引、向量化）	中～高
`web`	前端介面（Next.js）	低
`db`	PostgreSQL 資料庫	低～中
`redis`	快取與任務佇列	低
`weaviate`	向量資料庫（RAG 用）	中
`plugin_daemon`	外掛管理服務	低
`sandbox`	程式碼執行沙箱	低
`nginx`	反向代理	極低

總共 9 個容器。這代表 Dify 不適合跑在 1GB RAM 的最低規格 VPS 上。官方最低要求是 2 核 CPU + 4GB RAM，但實際經驗是 4 核 + 8GB RAM 才算舒適——特別是當 worker 在處理大量文件索引時，記憶體很容易衝上去。

Docker Compose 生產部署步驟

以 Ubuntu 24.04 LTS 為例，假設 Docker 與 Docker Compose v2 已經裝好。

1
2
3

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

打開 .env，至少要改這幾項：

# 安全性：務必換掉預設的 secret key，用以下指令產生一組隨機值
# openssl rand -hex 42
SECRET_KEY=<貼上你產生的隨機字串>

# 對外存取（使用 8080 避免與 Caddy 的 80/443 衝突）
DIFY_PORT=8080
EXPOSE_NGINX_PORT=8080

# 如果要搭配 Ollama 跑本地模型
OLLAMA_API_BASE_URL=http://host.docker.internal:11434

啟動：

1	docker compose up -d

第一次啟動會拉取所有映像檔，視網路速度大約需要 5-10 分鐘。完成後瀏覽器打開 http://你的VPS-IP:8080 就能進入初始化設定頁面，建立管理員帳號。

生產環境必須額外處理的事

Docker Compose 跑起來只是起點。要在正式環境穩定運作，這幾件事不能跳過。

HTTPS 與反向代理。Dify 內建的 Nginx 只處理 HTTP。生產環境需要在前面再加一層反向代理處理 TLS，用 Caddy 最省事：

1
2
3

dify.example.com {
    reverse_proxy localhost:8080
}

Caddy 會自動申請並續約 Let’s Encrypt 憑證，不用手動設定。

PostgreSQL 備份。Dify 的所有設定、工作流定義、對話記錄都存在 PostgreSQL 裡。丟了就全部重來。最基本的做法：

1	docker compose exec -T db pg_dump -U postgres dify > backup_$(date +%Y%m%d).sql

-T 參數關閉 TTY 分配，確保在 cron 或 systemd timer 排程執行時不會出錯。每天跑一次，備份檔丟到異地儲存。

向量資料庫的持久化。預設的 docker-compose.yaml 已經把 Weaviate 的資料掛到 volume，但升級版本前務必確認 volume 沒有被清掉。RAG 知識庫的向量索引重建非常耗時，幾百份文件可能要跑好幾個小時。

資源監控。worker 容器在處理文件切片和向量化時，CPU 和記憶體用量會暴增。沒有監控就無法判斷 VPS 規格是否足夠。搭配 Beszel 或 Checkmate 這類輕量監控工具，能即時掌握各容器的資源消耗。

接上 Ollama：資料完全不出境的 AI 應用

Dify 最吸引臺灣企業的一點：所有資料都在自己的伺服器上，LLM 推論也在自己的機器上。

如果 VPS 上已經跑了 Ollama，Dify 可以直接把它當模型供應商。在 Dify 後台的「模型供應商」設定裡，選擇 Ollama，填入 API 位址（通常是 http://host.docker.internal:11434），Dify 就會自動偵測所有已下載的模型。

這代表整條鏈路——使用者提問 → RAG 檢索 → LLM 生成——全部在同一台（或同一內網的）機器上完成。對於處理敏感資料的場景（法律文件、醫療記錄、財務報表），這不是加分項，是硬需求。

搭配的模型建議：

RAG 問答：Llama 3.1 8B 或 Qwen 2.5 7B，Q4 量化即可，回覆品質已經堪用
Embedding 向量化：nomic-embed-text 或 bge-m3，後者對中文支援較好
程式碼生成：DeepSeek Coder V2 Lite

CPU-only 的 VPS 跑 7B 量化模型大約 5-10 tok/s，做為內部工具夠用。如果需要更快的回應速度，可以把 LLM 推論放在有 GPU 的機器上，Dify 透過 API 遠端呼叫。

踩過的坑與解法

升級踩雷。Dify 的迭代速度極快（幾乎每週一版），但部分版本升級會改動資料庫 schema。正確的升級流程是：先備份 PostgreSQL、拉新版映像檔、docker compose up -d 讓 migration 自動跑、確認沒報錯後才算完成。跳版本升級（例如從 v1.10 直接跳 v1.14）有機率出問題，建議逐版升級。

記憶體不足導致 worker 被 OOM Kill。上傳大量 PDF 做 RAG 索引時，worker 容器的記憶體可能衝到 2-3GB。如果 VPS 總共只有 4GB，其他容器會連帶被影響。解法是在 docker-compose.yaml 裡設定 worker 的記憶體上限：

services:
  worker:
    deploy:
      resources:
        limits:
          memory: 2G

同時考慮加 swap 做為緩衝，但不要依賴 swap 跑長期負載。

Plugin Daemon 佔用連接埠。較新版的 Dify 加入了 Plugin Daemon 服務，會佔用額外的 port。如果 VPS 上有其他服務跑在相同 port，啟動時會報錯。檢查 .env 裡的 port 設定，確保沒有衝突。

什麼情境該用 Dify、什麼不該

適合 Dify 的場景：企業內部知識庫問答、客服聊天機器人、文件摘要與分類、需要非技術人員自行調整 prompt 和流程的應用。

不適合 Dify 的場景：需要複雜多步驟自動化（用 n8n）、需要 sub-second 延遲的即時推論（直接呼叫模型 API）、需要多個 Agent 協作的複雜任務（用 LangGraph 或 CrewAI 寫程式碼）。

Dify 的甜蜜點在「中等複雜度的 AI 應用，需要快速迭代，而且使用者不是工程師」。符合這個描述，Dify 會幫你省掉大量開發時間。

結語

Dify 把「自架 AI 應用平台」的門檻壓到了一個合理的位置：一台 4 核 8GB 的 VPS、一個 docker compose up -d、加上半小時的設定，就能讓團隊開始用拖拉介面組 AI 工作流。搭配 Ollama 跑本地模型，資料完全不需要離開自己的基礎設施。

NCSE Network 提供搭載 Intel Gold CPU 與 NVMe SSD 的臺灣 VPS 主機，是方電訊機房直連，適合部署 Dify 這類需要穩定運算與低延遲的 AI 應用平台。有興趣的讀者可以到 NCSE Network 了解方案細節。