AI Operations Server Ubuntu 26.04 Server + Docker + n8n 安裝流程

在 AI Operations Server 的規劃中，Ubuntu 26.04 Server、Docker、n8n、PostgreSQL、Redis、Qdrant、OpenAI API、Open WebUI 與 Portainer 會組成一台專門用來處理 AI 自動化、資料流轉、工作流程編排與向量記憶的後端中樞。這台伺服器的定位不是網站伺服器，也不是反向代理伺服器，更不是單純拿來放置 WordPress 的主機；它的任務是作為企業內部或專案團隊的「AI 自動化與資料處理中樞」，負責把 WordPress、WooCommerce、表單、外部 API、OpenAI 模型與資料庫流程串接起來，形成可維護、可擴充、可觀測的 AI Operations 架構。

本文會以系統工程師的角度，說明如何在 Ubuntu 26.04 Server 上使用 Docker Compose 部署 n8n、PostgreSQL、Redis、Qdrant、Open WebUI 與 Portainer，並建立一個適合 WordPress 自動化、AI 文章生成、WooCommerce 商品管理、表單自動回覆、API 串接中控，以及未來可擴展 Agent 架構的基礎平台。文章中的指令與設定可作為正式環境的起點，但正式上線前仍建議依照公司資安政策加入防火牆、備份、TLS、權限控管、監控與日誌集中化。

AI Operations Server 的核心定位

這台 AI Server 不應該被設計成「什麼都跑」的萬用伺服器。若同時在同一台機器上放網站、資料庫、反向代理、CI/CD、監控、備份與 AI 任務，長期會導致權限混亂、資源競爭與故障範圍擴大。比較穩定的設計方式，是明確界定此伺服器只處理 AI Operations 相關任務。

本架構中的 AI Operations Server 只做四件事：

• AI 思考：透過 OpenAI API 進行文字生成、摘要、分類、翻譯、商品描述產生、客服回覆草稿生成等任務。
• 流程自動化：以 n8n 作為 Workflow 核心，負責排程、Webhook、API 串接、條件判斷、錯誤重試與任務分派。
• 資料處理：使用 PostgreSQL 儲存 n8n 工作流程資料、執行紀錄、憑證索引與應用資料。
• 記憶與搜尋：使用 Qdrant 作為 Vector DB，儲存文件、商品、FAQ、客戶互動摘要等向量資料，提供 AI Agent 或 RAG 流程查詢。

因此，WordPress 網站本身可以部署在另一台 Web Server 或受管主機上；AI Operations Server 則透過 WordPress REST API、WooCommerce REST API、Webhook、表單通知或自訂 API 與網站互動。這樣的拆分能有效降低網站服務與 AI 自動化任務之間的耦合，也讓系統工程師在除錯、維護與擴充時更容易掌握邊界。

推薦完整架構圖

以下是此 AI Operations Server 的建議邏輯架構。實務上，WordPress 可位於外部主機、雲端平台或另一台內部 Web Server；AI Server 則專注處理自動化與 AI 資料流程。

WordPress
   ↓
n8n (核心 Workflow)
   ↓
OpenAI API
   ↓
PostgreSQL (資料)
   ↓
Redis (Queue)
   ↓
Qdrant (AI 記憶)

+ Docker (全部容器化)
+ Portainer (管理)
+ Open WebUI (測試用)

更完整的部署關係可理解為：

外部使用者 / 管理員 / 表單提交者
        ↓
WordPress / WooCommerce / Contact Form
        ↓ Webhook / REST API
AI Operations Server
        ├── n8n：Workflow 核心、Webhook 入口、排程任務
        ├── PostgreSQL：n8n 資料庫、流程紀錄、應用資料
        ├── Redis：Queue、快取、背景任務協調
        ├── Qdrant：向量資料庫、AI 記憶、語意搜尋
        ├── Open WebUI：AI 測試與操作介面
        ├── Portainer：Docker 容器管理 UI
        └── OpenAI API：外部 AI 模型能力

核心任務與建議使用情境

WordPress 自動化

n8n 可以透過 WordPress REST API 讀取文章、建立草稿、更新分類、同步標籤、偵測文章發布事件，也可以透過 Webhook 接收 WordPress 外掛傳來的事件。例如當編輯在 WordPress 後台新增一篇草稿時，n8n 可自動將文章內容送至 OpenAI API 進行 SEO 標題建議、Meta Description 生成、內文摘要與分類建議。

AI 文章生成

AI 文章生成流程通常不建議直接全自動發布，而是採用「AI 生成草稿，人工審核後發布」的方式。n8n 可定期讀取關鍵字清單，呼叫 OpenAI API 生成文章大綱、段落內容、FAQ 與摘要，再將結果寫入 WordPress 草稿。若搭配 Qdrant，還可以先搜尋既有知識庫、產品資料或品牌規範，再讓 OpenAI 根據內部資料生成較一致的文章。

WooCommerce 商品管理

WooCommerce 商品資料可透過 REST API 與 n8n 串接。常見應用包含商品描述自動優化、多語系翻譯、庫存警示通知、商品分類建議、批次更新 SEO 欄位、根據供應商 API 自動建立商品草稿等。PostgreSQL 可以保存商品同步紀錄，Redis 則可用於排隊處理大量商品更新，避免一次打爆 WooCommerce API 或外部供應商 API。

表單自動回覆

當 WordPress 表單外掛送出詢問、報價需求或客服問題時，可透過 Webhook 進入 n8n。n8n 可以先將內容寫入 PostgreSQL，再呼叫 OpenAI API 產生回覆草稿，並根據問題類型決定寄送 Email、建立 CRM 任務、通知 Slack 或提交至客服系統。若表單內容涉及敏感資料，建議先做遮罩、分類與審核，不要直接把所有原文送至外部 AI API。

API 串接中控

n8n 很適合作為 API 串接中控。它能把 WordPress、WooCommerce、CRM、ERP、Google Sheets、Slack、Email、LINE、Telegram、內部 API、外部供應商 API 與 OpenAI API 串在一起。對系統工程師而言，n8n 的優勢在於可視化流程、節點化錯誤處理、Webhook 入口與排程能力，能快速建立可觀察的中介層。

未來可擴展 Agent

當系統逐漸成熟後，可以將 n8n 作為 Agent Orchestration 的外層控制器，搭配 Qdrant 儲存向量記憶，OpenAI API 提供推理能力，PostgreSQL 保存任務狀態與執行結果，Redis 負責 Queue。未來若要擴展多 Agent 架構，例如 SEO Agent、商品資料 Agent、客服 Agent、報表 Agent，都可以建立在這個基礎上。

伺服器規格建議

若只是小型自動化與測試用途，最低可以從 2 vCPU、4 GB RAM、40 GB SSD 開始。但若要同時運作 n8n、PostgreSQL、Redis、Qdrant、Open WebUI 與 Portainer，並處理中等規模的 WordPress 與 WooCommerce 任務，建議至少使用以下規格：

• CPU：4 vCPU 以上
• 記憶體：8 GB RAM 以上，正式環境建議 16 GB RAM
• 硬碟：100 GB SSD 起跳，若 Qdrant 向量資料多，建議獨立磁碟或擴充空間
• 作業系統：Ubuntu 26.04 Server
• 網路：固定 IP 或內部 DNS，必要時搭配 VPN 存取管理介面

如果 Open WebUI 僅用於測試 OpenAI API，而不在本機跑大型 LLM，則不需要 GPU。若未來要在本機部署 Ollama、vLLM 或其他開源模型，才需要額外規劃 GPU、VRAM、驅動程式與模型儲存空間。

安裝前準備

以下範例假設已完成 Ubuntu 26.04 Server 基本安裝，並可使用具備 sudo 權限的帳號登入。請先更新系統套件：

sudo apt update
sudo apt upgrade -y

安裝常用工具：

sudo apt install -y ca-certificates curl gnupg lsb-release ufw git unzip htop net-tools

設定主機名稱，例如：

sudo hostnamectl set-hostname ai-ops-server

確認系統版本：

lsb_release -a
uname -a

設定基本防火牆

正式環境不建議將所有管理介面直接暴露到公網。若目前是測試環境，可以先開啟 SSH、n8n、Portainer 與 Open WebUI 的連線埠，但正式上線時建議限制來源 IP 或改由 VPN 存取。

sudo ufw allow OpenSSH
sudo ufw allow 5678/tcp
sudo ufw allow 9000/tcp
sudo ufw allow 9443/tcp
sudo ufw allow 3000/tcp
sudo ufw enable
sudo ufw status verbose

常見服務埠可規劃如下：

• n8n：5678
• Portainer：9000 或 9443
• Open WebUI：3000
• PostgreSQL：5432，建議只允許 Docker 內部網路使用
• Redis：6379，建議只允許 Docker 內部網路使用
• Qdrant：6333，若需要外部 API 存取才開放，否則保留內部網路即可

安裝 Docker Engine

Ubuntu 26.04 Server 建議使用 Docker 官方套件來源安裝 Docker Engine。先建立 keyring 目錄並加入 Docker GPG key：

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

加入 Docker apt repository：

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

安裝 Docker Engine 與 Docker Compose Plugin：

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

確認 Docker 版本：

docker --version
docker compose version

將目前使用者加入 docker 群組，避免每次都要 sudo 執行 Docker 指令：

sudo usermod -aG docker $USER
newgrp docker

測試 Docker 是否可正常運作：

docker run --rm hello-world

建立專案目錄

建議將 AI Operations Server 的所有 Docker Compose 設定集中在固定目錄，例如 /opt/ai-ops：

sudo mkdir -p /opt/ai-ops
sudo chown -R $USER:$USER /opt/ai-ops
cd /opt/ai-ops

建立資料目錄，讓容器資料可持久化保存：

mkdir -p data/postgres
mkdir -p data/redis
mkdir -p data/qdrant
mkdir -p data/n8n
mkdir -p data/open-webui
mkdir -p data/portainer

建立環境變數檔案

請建立 .env 檔案保存密碼、金鑰與服務設定。以下為範例，正式環境務必更換所有密碼與金鑰。

cd /opt/ai-ops
nano .env

POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=change_this_postgres_password

N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=change_this_n8n_password
N8N_ENCRYPTION_KEY=change_this_to_a_very_long_random_string
N8N_HOST=your-ai-server.example.com
N8N_PROTOCOL=http
N8N_PORT=5678
WEBHOOK_URL=http://your-ai-server.example.com:5678/

OPENAI_API_KEY=sk-your-openai-api-key

QDRANT_API_KEY=change_this_qdrant_api_key

TZ=Asia/Taipei

產生隨機金鑰可使用：

openssl rand -hex 32

N8N_ENCRYPTION_KEY 對 n8n 非常重要，n8n 會用它加密 Credentials。若正式使用後更換此值，可能導致既有 Credential 無法解密。因此正式部署前請先固定並備份這個值。

建立 Docker Compose 設定

接著建立 docker-compose.yml。此範例包含 n8n、PostgreSQL、Redis、Qdrant、Open WebUI 與 Portainer。PostgreSQL、Redis 與 Qdrant 預設不對外開放，主要讓 Docker 內部網路使用；n8n、Open WebUI、Portainer 則依需求對外提供管理介面。

nano docker-compose.yml

services:
  postgres:
    image: postgres:16
    container_name: aiops-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: ${TZ}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - aiops-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    container_name: aiops-redis
    restart: unless-stopped
    command: redis-server --appendonly yes
    volumes:
      - ./data/redis:/data
    networks:
      - aiops-net
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  qdrant:
    image: qdrant/qdrant:latest
    container_name: aiops-qdrant
    restart: unless-stopped
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}
    volumes:
      - ./data/qdrant:/qdrant/storage
    networks:
      - aiops-net
    ports:
      - "6333:6333"

  n8n:
    image: n8nio/n8n:latest
    container_name: aiops-n8n
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}

      N8N_BASIC_AUTH_ACTIVE: "true"
      N8N_BASIC_AUTH_USER: ${N8N_BASIC_AUTH_USER}
      N8N_BASIC_AUTH_PASSWORD: ${N8N_BASIC_AUTH_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}

      N8N_HOST: ${N8N_HOST}
      N8N_PORT: ${N8N_PORT}
      N8N_PROTOCOL: ${N8N_PROTOCOL}
      WEBHOOK_URL: ${WEBHOOK_URL}
      GENERIC_TIMEZONE: ${TZ}
      TZ: ${TZ}

      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: 336

      N8N_DIAGNOSTICS_ENABLED: "false"
      N8N_VERSION_NOTIFICATIONS_ENABLED: "true"
    volumes:
      - ./data/n8n:/home/node/.n8n
    networks:
      - aiops-net
    ports:
      - "5678:5678"

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: aiops-open-webui
    restart: unless-stopped
    environment:
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      TZ: ${TZ}
    volumes:
      - ./data/open-webui:/app/backend/data
    networks:
      - aiops-net
    ports:
      - "3000:8080"

  portainer:
    image: portainer/portainer-ce:latest
    container_name: aiops-portainer
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data/portainer:/data
    networks:
      - aiops-net
    ports:
      - "9000:9000"
      - "9443:9443"

networks:
  aiops-net:
    driver: bridge

如果正式環境要將 n8n 放在 HTTPS 網域後面，通常會在另一台反向代理或 Load Balancer 上處理 TLS，並將 N8N_PROTOCOL 設為 https，WEBHOOK_URL 設為正式 HTTPS URL。由於本文中的 AI Operations Server 定位不是反向代理，因此不在同一台主機上額外部署 Nginx Proxy Manager 或 Traefik，以避免角色混雜。

啟動服務

啟動所有容器：

cd /opt/ai-ops
docker compose up -d

查看容器狀態：

docker compose ps

查看即時日誌：

docker compose logs -f n8n
docker compose logs -f postgres
docker compose logs -f redis
docker compose logs -f qdrant

確認服務：

• n8n：http://伺服器IP:5678
• Open WebUI：http://伺服器IP:3000
• Portainer：http://伺服器IP:9000 或 https://伺服器IP:9443
• Qdrant API：http://伺服器IP:6333

初始化 n8n

第一次開啟 n8n 時，系統會要求建立 Owner 帳號。完成後，建議先確認以下項目：

• Timezone 是否為 Asia/Taipei。
• Webhook URL 是否正確。
• 是否能建立 Credential。
• 是否能建立測試 Workflow。
• Queue 模式是否正常連接 Redis。

若要測試 n8n Webhook，可建立一個簡單 Workflow：

1. 新增 Webhook Trigger。
2. 新增 Set 節點，回傳測試欄位。
3. 新增 Respond to Webhook 節點。
4. 啟用 Workflow。

使用 curl 測試：

curl -X POST http://your-ai-server.example.com:5678/webhook/test \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "name=AI Operations Server"

在 n8n 設定 OpenAI API

在 n8n 中可透過 OpenAI 節點或 HTTP Request 節點呼叫 OpenAI API。建議以 n8n Credential 管理 API Key，不要把金鑰硬寫在節點中。若使用 HTTP Request 節點，可建立 Header：

Authorization: Bearer sk-your-openai-api-key
Content-Type: application/json

典型用途包含：

• 根據 WordPress 文章草稿產生 SEO 標題。
• 根據 WooCommerce 商品規格產生商品描述。
• 根據表單內容產生客服回覆草稿。
• 將長文章摘要成社群貼文。
• 將客戶問題分類成技術支援、報價詢問、售後服務或垃圾訊息。

對系統工程師而言，建議在 n8n 中建立「Prompt Template」管理策略，避免每個 Workflow 都散落不同提示詞。可以將提示詞保存在 PostgreSQL、Google Sheets、Git Repository 或 n8n 子流程中，讓提示詞版本更容易控管。

測試 PostgreSQL

進入 PostgreSQL 容器：

docker exec -it aiops-postgres psql -U n8n -d n8n

查看資料表：

\dt

離開 psql：

\q

如果要建立額外應用資料庫，例如保存 WordPress 自動化紀錄，可另建資料庫與使用者。不過在正式環境，建議將 n8n 內部資料與業務資料分開，以降低維護風險。

測試 Redis

Redis 在此架構中主要作為 n8n Queue 與快取用途。測試方式如下：

docker exec -it aiops-redis redis-cli ping

若回傳：

PONG

代表 Redis 可正常運作。

測試 Qdrant

Qdrant 是向量資料庫，用於 AI 記憶、語意搜尋與 RAG 流程。可先測試 API 是否可連線：

curl http://localhost:6333/

若啟用了 API Key，外部呼叫時需加入 Header：

curl http://localhost:6333/collections \
  -H "api-key: change_this_qdrant_api_key"

在 n8n 中，常見設計是先將 WordPress 文章、WooCommerce 商品描述、FAQ、客服紀錄或內部文件切分成 chunks，送到 OpenAI Embeddings API 產生向量，再寫入 Qdrant。使用者提問時，n8n 先拿問題產生 embedding，查詢 Qdrant 找出最相關內容，再把搜尋結果與問題一起送到 OpenAI API 產生回答。

Open WebUI 的用途

Open WebUI 在此架構中不是核心 Workflow 引擎，而是 AI 操作與測試介面。系統工程師、內容編輯或產品經理可以透過 Open WebUI 測試 Prompt、比較模型回覆、驗證內部知識內容是否適合交給 AI 使用。若 Open WebUI 僅串接 OpenAI API，主要用途是快速驗證 AI 回應品質；若未來加上 Ollama 或本機模型，則可以進一步測試私有模型與混合模型流程。

Open WebUI 啟動後可瀏覽：

http://伺服器IP:3000

第一次登入通常需要建立管理員帳號。請注意，若此介面暴露在公網，必須搭配強密碼、來源 IP 限制或 VPN，否則可能造成 API Key 濫用與資料外洩風險。

Portainer 的用途

Portainer 是 Docker 管理 UI，可用來檢視容器狀態、日誌、映像檔、Volume、Network 與 Stack。對系統工程師而言，Portainer 很適合作為日常維運輔助工具，但不應取代版本控管。正式環境的 Docker Compose 檔案仍應放在 Git 中控管，並透過標準流程部署。

初次開啟 Portainer：

http://伺服器IP:9000

或：

https://伺服器IP:9443

建立管理員帳號後，選擇本機 Docker environment，即可管理目前主機上的容器。

WordPress 與 n8n 串接模式

WordPress 與 n8n 的串接可分成兩種方向：WordPress 主動通知 n8n，以及 n8n 主動呼叫 WordPress。

WordPress 主動通知 n8n

可透過表單外掛、Webhook 外掛或自訂程式，在特定事件發生時呼叫 n8n Webhook。例如：

• 使用者提交聯絡表單。
• 新訂單成立。
• 商品庫存低於門檻。
• 文章狀態改為草稿。
• 會員註冊完成。

n8n 接收事件後，可以進行資料清洗、寫入 PostgreSQL、呼叫 OpenAI API、通知管理員、更新 WooCommerce 或建立後續任務。

n8n 主動呼叫 WordPress

n8n 可透過 WordPress REST API 主動建立文章草稿。例如使用 Application Password 進行 Basic Auth。測試指令如下：

curl -X POST https://your-wordpress-site.example.com/wp-json/wp/v2/posts \
  -u "wordpress_user:application_password" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "title=AI 自動產生文章草稿" \
  -d "content=這是一篇由 n8n 與 OpenAI API 產生的文章草稿。" \
  -d "status=draft"

正式使用時，建議建立專用 WordPress 帳號，只授予必要權限，不要使用最高權限管理員帳號作為 API 整合帳號。

WooCommerce 商品管理流程範例

WooCommerce API 可讓 n8n 讀取、建立或更新商品。常見 AI 自動化流程如下：

1. n8n 每日排程讀取 WooCommerce 商品清單。
2. 找出描述過短、缺少 SEO 欄位或缺少分類的商品。
3. 將商品名稱、規格、品牌、屬性送至 OpenAI API。
4. 產生商品短描述、長描述、SEO 標題與 Meta Description。
5. 先寫入 PostgreSQL 作為審核佇列。
6. 人工確認後，再由 n8n 更新 WooCommerce 商品。

使用 curl 讀取 WooCommerce 商品範例：

curl https://your-wordpress-site.example.com/wp-json/wc/v3/products \
  -u "ck_your_consumer_key:cs_your_consumer_secret"

更新商品範例：

curl -X PUT https://your-wordpress-site.example.com/wp-json/wc/v3/products/123 \
  -u "ck_your_consumer_key:cs_your_consumer_secret" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "short_description=這是由 AI 優化後的商品短描述。"

表單自動回覆流程範例

表單自動回覆不應只是單純把使用者問題丟給 AI 回答。更穩定的流程是先分類、再查詢資料、最後產生回覆草稿。建議流程如下：

1. WordPress 表單送出後呼叫 n8n Webhook。
2. n8n 將原始表單資料寫入 PostgreSQL。
3. OpenAI API 判斷問題類型與優先權。
4. 若需要知識庫，先查詢 Qdrant 取得相關 FAQ 或文件。
5. OpenAI API 根據問題與查詢結果產生回覆草稿。
6. n8n 寄送 Email 給客服人員審核，或依規則自動回覆。
7. 所有處理結果寫回 PostgreSQL 作為稽核紀錄。

這種設計可避免 AI 在缺少上下文時亂答，也可以讓客服流程保留人工審核與追蹤紀錄。

備份策略

AI Operations Server 的關鍵資料主要包含 PostgreSQL、n8n 設定、Qdrant 向量資料、Open WebUI 資料與 Docker Compose 設定。建議至少每日備份 PostgreSQL 與 /opt/ai-ops 目錄。

PostgreSQL 備份範例：

mkdir -p /opt/ai-ops/backups
docker exec aiops-postgres pg_dump -U n8n n8n > /opt/ai-ops/backups/n8n_$(date +%F).sql

壓縮專案目錄：

sudo tar -czf /opt/ai-ops/backups/aiops_data_$(date +%F).tar.gz /opt/ai-ops/data /opt/ai-ops/docker-compose.yml /opt/ai-ops/.env

正式環境請將備份同步到異地，例如 S3、NAS、另一台備份伺服器或企業備份系統。也應定期進行還原演練，因為沒有測試過的備份不能視為可靠備份。

更新與維護

更新容器映像檔前，請先備份。接著可執行：

cd /opt/ai-ops
docker compose pull
docker compose up -d

清理未使用映像檔：

docker image prune -a

查看磁碟使用量：

docker system df
df -h

查看容器資源使用：

docker stats

n8n、PostgreSQL、Qdrant 都屬於有狀態服務，不建議在沒有備份與測試的情況下盲目升級 major version。若是正式環境，建議先在 staging server 驗證相同 Docker Compose 設定，再更新 production server。

安全性建議

AI Operations Server 會保存 OpenAI API Key、WordPress API Token、WooCommerce API Key、表單資料、客戶問題、商品資料與自動化執行紀錄，因此安全性必須從一開始就納入規劃。

• 不要使用 root 帳號直接登入 SSH。
• SSH 使用金鑰登入，停用密碼登入。
• n8n、Open WebUI、Portainer 使用強密碼。
• 管理介面盡量限制來源 IP 或透過 VPN 存取。
• PostgreSQL、Redis 不對外開放。
• OpenAI API Key 不寫死在 Workflow 節點中。
• 定期輪替 API Key 與應用程式密碼。
• 敏感資料進入 OpenAI API 前先做遮罩或最小化。
• 定期備份並測試還原。
• 將 Docker Compose 與環境設定納入權限控管。

若要強化 SSH 安全性，可編輯：

sudo nano /etc/ssh/sshd_config

建議設定：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

重新載入 SSH：

sudo systemctl reload ssh

常見錯誤排除

Docker 無法啟動

檢查 Docker 服務狀態：

sudo systemctl status docker

若未啟動，可執行：

sudo systemctl enable docker
sudo systemctl start docker

若目前使用者無法執行 docker 指令，確認是否已加入 docker 群組：

groups
sudo usermod -aG docker $USER
newgrp docker

n8n 無法連線 PostgreSQL

先檢查 PostgreSQL 容器是否健康：

docker compose ps
docker compose logs postgres

常見原因包含 POSTGRES_USER、POSTGRES_PASSWORD、POSTGRES_DB 與 n8n 環境變數不一致，或 PostgreSQL data volume 曾經用舊密碼初始化過。若是測試環境且資料可刪除，可停止容器並清除 PostgreSQL 資料目錄後重建：

docker compose down
rm -rf /opt/ai-ops/data/postgres/*
docker compose up -d

正式環境不可直接刪除資料目錄，應先備份並分析日誌。

n8n Webhook URL 錯誤

如果 WordPress 呼叫 n8n Webhook 時網址不正確，通常是 WEBHOOK_URL、N8N_HOST 或 N8N_PROTOCOL 設定不符合外部實際存取網址。修改 .env 後重新啟動 n8n：

docker compose up -d n8n

若前方有 HTTPS 反向代理，WEBHOOK_URL 必須使用 HTTPS 完整網域，而不是容器內部名稱或 localhost。

Redis Queue 沒有正常運作

檢查 Redis：

docker exec -it aiops-redis redis-cli ping

查看 n8n 日誌：

docker compose logs -f n8n

確認 n8n 的 Redis host 設為 redis，也就是 Docker Compose service name，而不是 localhost。在容器內，localhost 指的是 n8n 容器本身，不是 Redis 容器。

Qdrant API 無法存取

先確認容器狀態：

docker compose ps qdrant
docker compose logs qdrant

若在伺服器本機測試：

curl http://localhost:6333/collections -H "api-key: your_qdrant_api_key"

若外部無法連線，請確認 UFW 是否開放 6333，以及雲端防火牆 Security Group 是否允許來源 IP。不建議將 Qdrant 直接開放給所有公網來源。

OpenAI API 呼叫失敗

常見原因包括 API Key 錯誤、額度不足、模型名稱錯誤、請求格式錯誤或網路無法連到 OpenAI。可在伺服器上測試 DNS 與連線：

curl -I https://api.openai.com

若是 n8n 節點錯誤，請查看該執行紀錄中的 request 與 response。正式環境不要在日誌中長期保留完整敏感內容，避免洩漏客戶資料或 API Key。

Portainer 無法管理 Docker

Portainer 需要掛載 Docker socket：

/var/run/docker.sock:/var/run/docker.sock

若沒有掛載，Portainer 將無法管理本機 Docker。請檢查 docker-compose.yml 中 portainer service 的 volumes 設定，修改後重新部署：

docker compose up -d portainer

磁碟空間快速耗盡

n8n 執行紀錄、Docker logs、PostgreSQL 資料、Qdrant 向量資料都可能消耗大量磁碟。先檢查：

df -h
docker system df
du -sh /opt/ai-ops/data/*

可在 n8n 設定中啟用執行資料清理，例如本文 Compose 已加入：

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336

代表保留約 14 天執行資料。若正式環境需要稽核，應將重要紀錄寫入專門資料表或日誌系統，而不是依賴 n8n 內建執行紀錄永久保存。

正式環境部署建議

若此 AI Operations Server 要投入正式使用，建議採用以下部署原則：

• n8n 對外 Webhook 與管理後台分離，管理後台限制 IP。
• 所有密碼與 API Key 使用密碼管理系統保存。
• Docker Compose 檔案放入 Git，但 .env 不提交到公開 repository。
• PostgreSQL 定期備份，並測試還原。
• Qdrant 資料若可由來源資料重建，仍需保存索引建立流程。
• OpenAI API 設定預算上限與用量警示。
• 所有自動發布流程都應保留人工審核機制。
• 對 WordPress 與 WooCommerce API 設定最小權限。
• 大型批次任務使用 Redis Queue，避免 API 瞬間超載。
• 建立 staging 環境測試 n8n Workflow 變更。

建議的 Workflow 設計模式

n8n Workflow 很容易快速堆疊，但若缺少設計規範，長期會變成難以維護的流程迷宮。建議採用以下模式：

• 入口流程：只負責接收 Webhook、驗證資料、寫入任務。
• 處理流程：負責呼叫 OpenAI API、查詢 Qdrant、整理資料。
• 輸出流程：負責寫回 WordPress、WooCommerce、Email 或其他系統。
• 錯誤流程：統一處理失敗通知、重試、人工介入。
• 共用子流程：將 OpenAI Prompt、格式化、資料驗證封裝成可重用節點。

例如 AI 文章生成可以拆成：「關鍵字讀取」、「資料蒐集」、「Qdrant 查詢」、「OpenAI 生成」、「品質檢查」、「WordPress 建草稿」、「通知編輯」等多個階段。這樣比把所有邏輯塞在單一 Workflow 中更容易除錯與擴充。

結論

以 Ubuntu 26.04 Server、Docker、n8n、PostgreSQL、Redis、Qdrant、OpenAI API、Open WebUI 與 Portainer 建立 AI Operations Server，可以讓 WordPress 自動化、AI 文章生成、WooCommerce 商品管理、表單自動回覆、API 串接中控與未來 Agent 擴展具備一致的基礎架構。這台伺服器的重點不是承載網站流量，而是承載 AI 自動化流程、資料處理、佇列任務與向量記憶。

對系統工程師而言，最重要的是清楚區分角色：WordPress 負責內容與前台，n8n 負責 Workflow，OpenAI 負責 AI 推理，PostgreSQL 負責結構化資料，Redis 負責 Queue，Qdrant 負責 AI 記憶，Portainer 負責容器管理，Open WebUI 則提供 AI 測試介面。只要邊界清楚，未來要擴充更多 Agent、更多 API 串接或更多自動化流程，就能在不破壞既有網站架構的前提下持續演進。

FAQ

這台 AI Operations Server 可以同時當 WordPress 網站主機嗎？

技術上可以，但不建議。本文的架構定位是 AI 自動化與資料處理中樞，不是網站伺服器。將 WordPress 與 AI Operations 拆開，可降低資源競爭與安全風險，也方便未來擴充。

一定要使用 PostgreSQL 嗎？

n8n 可使用不同資料庫，但正式環境建議使用 PostgreSQL，穩定性、查詢能力與維護工具都較成熟。SQLite 適合測試，不建議用於正式多流程、多使用者或 Queue 模式環境。

Redis 的用途是什麼？

Redis 在此架構中主要用於 n8n Queue 與快取。當 Workflow 數量增加、任務需要背景處理或批次執行時，Redis 能協助提升穩定性與可擴充性。

Qdrant 一定需要嗎？

如果只是簡單呼叫 OpenAI API 產生文章或回覆，Qdrant 不是必需。但若要建立 AI 記憶、知識庫搜尋、RAG、產品資料查詢或未來 Agent，Qdrant 會是很重要的向量資料庫元件。

Open WebUI 是不是可以取代 n8n？

不可以。Open WebUI 主要是 AI 聊天與測試介面，n8n 則是 Workflow 自動化核心。兩者用途不同，Open WebUI 適合測試 Prompt 與模型回覆，n8n 適合串接 WordPress、WooCommerce、API、資料庫與排程任務。

Portainer 是否必要？

Portainer 不是必要元件，但對系統工程師日常維護 Docker 容器很方便。即使使用 Portainer，也建議保留 Docker Compose 檔案與 Git 版本控管，不要只依賴 UI 操作。

OpenAI API Key 應該放在哪裡？

建議放在 n8n Credential 或受控的環境變數中，不要直接寫在 Workflow 節點、程式碼或公開 Git repository。正式環境應定期輪替 API Key，並設定用量限制。

n8n 可以直接自動發布 WordPress 文章嗎？

可以，但不建議在沒有審核的情況下全自動發布。較安全的做法是由 n8n 建立草稿，並通知編輯或管理者審核，確認內容品質、事實正確性與品牌語氣後再發布。

如果未來要加入自架 LLM，需要改架構嗎？

不一定。若加入 Ollama、vLLM 或其他本機模型，可以把它視為新的 AI 推理服務，讓 n8n 透過 API 呼叫。若要跑大型模型，則需要額外規劃 GPU、VRAM、驅動程式、模型儲存與散熱供電。

正式環境最容易忽略的問題是什麼？

最常被忽略的是備份、Webhook URL、API Key 權限、n8n 執行紀錄膨脹、管理介面暴露公網，以及 AI 自動化缺少人工審核。這些問題在測試階段不明顯，但正式運作後會直接影響安全性與穩定性。