自行託管 LiveContext：n8n 替代方案與 VPS 規格

LiveContext 的用途與執行成本

自行託管 LiveContext 需要一台約有 8 GB RAM 的 VPS。LiveContext CE 是開放原始碼自動化平台，可在自動化流程中執行 AI agent。它以 Java 後端為核心，透過 Docker Compose stack 執行 6 個容器。上游 README 要求至少 4 GB RAM，建議使用 8 GB；compose 檔案則會顯示這些記憶體的配置方式。

專案位於 GitHub 的 livecontext-ai/livecontext-ce，採用 AGPL-3.0 授權。截至 2026 年 8 月，目前版本為 v0.2.11，於 3 August 2026 發布。所有 image 僅建置為 linux/amd64，因此無法使用價格較低的 Arm 方案。本指南固定使用該 tag，將 stack 放在反向代理後方，並涵蓋上游文件未提供的備份程序。

在自行託管 LiveContext 前評估 VPS 規格

提供的 compose 檔案中，每項服務都設定了明確的記憶體限制，因此你可以在租用 VPS 前先評估所需規格。以下是 v0.2.11 compose 檔案中寫入的限制，不是實際測得的使用量。

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

僅後端的上限就是 1536 MB。此限制套用在 Java 21 程序上，因此 JVM 會使用其中大部分記憶體，並持續維持該用量。5 項基礎服務合計略低於 3 GB，而前端完全沒有設定限制，因此會使用 Node 要求的記憶體。4 GB VPS 幾乎不會剩下空間供核心與頁面快取使用，所以 4 GB 被列為最低需求，而不是建議規格。

選用的 profiles 會讓所需規格提高到 8 GB。瀏覽器代理程式 profile 會在 SearXNG 搜尋實例旁加入一個上限為 2048 MB 的 Chromium 容器；renderer profile 則會另外增加 1024 MB，用於處理螢幕截圖與 PDF。除非啟用對應的 profile，否則這兩項服務都不會啟動，因此在需要前應保持停用。SearXNG 容器是代理程式的搜尋後端，因此它回傳的頁面會以不受信任的文字進入提示。這就是 讓 AI 代理程式使用 SearXNG 網頁搜尋 所涉及的信任邊界，詳細說明如下。

如果你已經執行 n8n，請規劃替換它，而不是將兩者加在一起。我們在 VPS 上使用 Docker 和 HTTPS 執行 n8n 的指南中的堆疊，是在 Postgres 旁執行單一 Node 程序，在小型 VPS 上即可穩定運作。LiveContext 僅後端預留的記憶體，就超過該完整堆疊的用量。在同一台 8 GB VPS 上執行兩個自動化平台，通常可以運作，但只要兩者在同一分鐘執行工作，就可能超出可用資源。如果必須共用主機，也要依照我們介紹在 Docker Compose 中設定記憶體限制的文章所述的方法，為其他所有服務設定明確限制，避免單一失控的工作流程拖垮整台機器。

使用 Docker Compose 安裝 LiveContext，並固定使用標籤

請從乾淨的 Ubuntu 24.04 VPS 開始，並確認已安裝 Docker Engine 24 或更新版本，以及 Compose v2。若尚未安裝 Docker，請先依照VPS 的 Docker Compose 基礎教學操作，再返回本節。

README 提供 npx livecontext 作為單行啟動方式。在筆記型電腦上使用沒有問題。在伺服器上，應將 compose 檔案放在由你管理的目錄中。這樣升級時只需執行 git checkout，也能明確查看變更內容。

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

compose 檔案已將每個映像固定到其發行標籤，例如 ghcr.io/livecontext-ai/livecontext-ce:v0.2.11。切換到相符的 git 標籤，才能讓 compose 檔案與映像版本保持一致，因為 v0.2.11 的 compose 檔案就是針對這些映像撰寫的。不要將標籤修改為 latest。latest 標籤可能在你未注意時移動，而後端每次啟動都會執行資料庫 migration。因此，意外的 pull 可能在凌晨 3 點將 schema 升級，除非還原備份，否則無法回復。

第一次啟動前，先編輯 docker/.env.ce（下一節會列出需要修改的內容），再啟動整個 stack。

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

本教學中的每個 compose 指令都使用相同的 --env-file flag。Compose 每次執行指令時都會重新讀取該檔案，因此省略此 flag 的指令會改用 compose 檔案內建的預設值，並可能發布與你設定不同的埠。

後端 healthcheck 的 start_period 為 120s，並輪詢 /actuator/health。因此，在 schema migration 與工具註冊執行期間，docker compose ps 會將 livecontext 服務回報為 health: starting，時間約為前兩分鐘。這是正常現象。可從伺服器快速檢查：

curl -s localhost:8080/actuator/health

此指令應輸出 {"status":"UP"}。確認後，請在 port 3000 上開啟 Web UI。你建立的第一個帳戶會成為 admin，因此請在其他人能連線到該埠之前建立自己的帳戶。這是不應在第一天就將 port 3000 發布到網際網路的最重要原因。

必須變更的環境變數

範例檔案提供可運作的預設值，因此整個 stack 可在筆記型電腦上啟動。其中有幾項設定不適合用於公開伺服器。

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

使用 openssl rand -base64 32 產生每個隨機值。以下說明幾項容易造成問題的設定：

• POSTGRES_PASSWORD 和 MINIO_ROOT_PASSWORD 的預設值分別是 postgres 和 minioadmin。這兩個資料庫埠都沒有發佈到主機，因此不會直接暴露；但日後加入同一個 network 的任何容器，都能使用文件所列的預設值連線到這兩個埠。
• CREDENTIAL_ENCRYPTION_PASSWORD 和 CREDENTIAL_ENCRYPTION_SALT 留白時會自動產生。請改為自行設定。工作流程儲存的認證資料會使用這組值加密，因此若將資料庫 dump 還原到新主機，卻沒有相同的密碼與 salt，還原的認證資料列將無法讀取。請只設定一次，並將 docker/.env.ce 視為備份的一部分。
• FRONTEND_PORT 和 BACKEND_PORT 會代入埠對映，成為 ${FRONTEND_PORT:-3000}:3000 和 ${BACKEND_PORT:-8080}:8080。範例 env 檔案會明確設定這兩項，而其中的預設值不一定是 3000 和 8080。請查看自己的檔案，不要直接假設。
• GATEWAY_PUBLIC_URL 是瀏覽器存取 backend 所使用的 origin。只要使用 reverse proxy，這項設定就會生效。請參閱下一節。
• model keys（ANTHROPIC_API_KEY、OPENAI_API_KEY、GOOGLE_API_KEY，以及選用的 MISTRAL_API_KEY 或 DEEPSEEK_API_KEY）會以明文儲存在此處。只填入實際使用的 provider。

六個容器的用途

• postgres 以容器 livecontext-db 執行 pgvector/pgvector:pg16，其中保存名為 livecontext 的資料庫。這裡需要 pgvector extension 來執行 embedding 搜尋，因此不能使用一般的 postgres:16 image。
• redis 以 appendonly yes 和 --maxmemory-policy noeviction 執行 redis:7-alpine。這項政策是刻意設定的：Redis 在這裡保存佇列與執行狀態，因此達到記憶體上限時，會向寫入端回傳錯誤，而不是靜默刪除 keys。能看見的錯誤，比工作無聲消失更容易處理。
• minio 是工作流程中傳遞檔案所使用的 S3 相容物件儲存。一次性的 minio-init 容器會在啟動時執行 mc mb myminio/workflow-files --ignore-existing、建立 bucket，然後結束。若在 docker compose ps 中看到 minio-init 為 exited (0)，即表示狀態正常。
• bridge 保存 CLI adapters 和 MCP（model context protocol）工具。它在 Docker network 內監聽 8093，且不會發佈至 host。
• livecontext 是 backend，使用單一 Java 21 monolith，監聽 8080 port。它執行 workflow engine、schedulers 和 agents。
• frontend 是監聽 3000 port 的 Next.js web UI。只有最後這兩個服務會發佈至 host。

狀態保存在五個具名 volumes 中：livecontext_data 用於 Postgres，另外還有 livecontext_redis、livecontext_minio、livecontext_keys 和 livecontext_logs。Compose 會在這些名稱前加上 project name；project name 預設為目錄名稱，因此磁碟上的實際 volume 名稱會類似 livecontext-ce_livecontext_minio。執行 docker volume ls，並在針對這些 volumes 撰寫 backup script 前，複製確切的名稱。

docker compose down -v 會刪除全部五個 volumes。這是文件記載的重新開始方式，也是遺失所有已建立 workflow 的最快方法。-v 就是兩者之間的全部差異。

改用 Traefik 代理，不要發布 3000 埠

在公開 VPS 上發布 3000 和 8080 埠，會讓應用程式在沒有 TLS（傳輸層安全性）的情況下直接對外提供服務，也沒有任何閘道保護管理員註冊頁面。單獨設定 ufw 規則並不足夠，因為 Docker 會將自己的 iptables 規則插入已發布埠的鏈結前方，優先於 ufw 管理的規則。因此，即使 ufw 顯示拒絕該埠，發布至 0.0.0.0 的埠仍然可連線。

正確做法是不發布任何埠，改讓代理程式透過共用的 Docker network 存取容器。在 repo 根目錄建立 docker-compose.override.yml：

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

有兩個細節會決定這項設定是否有效。!override 會取代 ports 清單，而不是與其合併；這需要 Compose v2.24 或更新版本。請使用 docker compose version 檢查，因為在較舊版本的 Compose 中，兩個清單會合併，埠仍會被發布。default 也必須保留在每個 networks 清單中，因為指定任何 network 都會取代預設 network；若省略它，frontend 就無法連線至 Postgres 和 Redis。在啟動任何服務前，先確認合併後的設定：

docker compose --env-file docker/.env.ce config

路由器、憑證解析器，以及 HTTP 重新導向至 HTTPS 的設定，與其他應用程式相同。因此，請依照 我們的 Traefik 反向代理指南，在同一台 VPS 上執行多個應用程式，不要在此重新撰寫 TLS 設定。將一個 hostname 路由至 frontend 的 3000 埠，並將另一個 hostname 路由至 livecontext 的 8080 埠。

第二個 hostname 並非可選設定。web UI 會在瀏覽器中呼叫 backend，因此 backend 必須有瀏覽器可連線的獨立 origin。將 GATEWAY_PUBLIC_URL 設定在 docker/.env.ce 中，指向該 backend URL，例如 https://lc-api.example.com。若省略此設定，頁面仍會正常載入，但所有操作都會失敗，因為 UI 會根據你開啟頁面時使用的位址解析 backend origin，並呼叫代理程式從未發布的埠。

由於任何首先連線的人都能看到註冊頁面，建議在 frontend router 上設定 forward auth，讓使用者必須先通過代理程式驗證才能看到該頁面；將 Authentik 作為自己的 SSO 層會在相同的 Traefik 設定上提供這項功能。

模型金鑰的放置位置，以及閒置執行個體仍會產生成本的原因

代理程式會在此自動化系統中執行，因此其成本結構不同於一般工作流程工具。Provider key 位於 docker/.env.ce 的 ANTHROPIC_API_KEY 或 OPENAI_API_KEY 中，後端與 bridge 會在啟動時讀取該金鑰，並套用至整個執行個體。金鑰不會依使用者區分。凡是在你的執行個體上擁有帳戶且能建立代理程式的人，都會使用該金鑰產生成本；而第一位註冊者會取得 admin 權限。

以下 3 個習慣有助於讓帳單維持可預測。為這台 VPS 建立專用的 provider key，這樣撤銷時不會影響其他用途。在 provider console 中設定硬性支出上限，因為在你保護的這台機器之外，只有這項限制能控制支出。接著使用 LiveContext 提供的每個代理程式 credit budget 與每個代理程式 metrics，避免單一迴圈在你察覺前耗盡金鑰額度。

代理程式一旦依排程執行，閒置成本就不會是 0。排程觸發器會在無人監看時照常觸發，而每次觸發都會傳送 tokens。每 5 分鐘執行一次的排程每天會執行 288 次；即使代理程式讀取頁面後決定不採取任何動作，讀取頁面仍會產生成本。先讓你的第一批代理程式使用 webhook 或 chat trigger，觀察 1 週的實際支出，再在了解每次執行成本後改用排程。

備份 Postgres 與物件儲存

這裡有兩個資料儲存區和一個 secret，三者任一遺失都會導致執行個體遺失。在同一個時間窗口內備份資料庫與 bucket，並先停止 backend，確保資料庫資料列完成傾印後，不會再寫入檔案。

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

如果你變更過 DB_USERNAME，請改用你設定的值取代 postgres。接著複製物件儲存 volume，使用 docker volume ls 輸出的前綴名稱：

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

在信任傾印檔前，先確認檔案不是空的：gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 應顯示 CREATE TABLE 和 DROP TABLE 陳述式，而不是只顯示一行錯誤訊息。接著將這三個檔案全部複製到伺服器外部。只存放在受其保護的機器上的備份，不是真正的備份。

若要還原到新的主機，請安裝相同的 tag，將保存的 docker/.env.ce 放回原位，使 credential encryption password 和 salt 保持一致；先啟動 stack 一次，讓 volumes 建立完成，再停止 backend，然後載入傾印檔：

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

升級，以及升級失敗時的復原

每次都要先建立 dump。後端會在啟動時套用 schema migration，而 migration 只能向前移動。因此，升級失敗後切回較舊的 tag，會讓舊版程式碼使用較新的 schema。Rollback 的方式是還原 dump，所以必須先建立 dump。

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

將 TAG 設為第三個指令列出的項目中所選取的 tag。持續監控後端 log，直到 health endpoint 再次回應。你的 docker-compose.override.yml 未受追蹤，因此執行 git checkout 時會保留它；但請閱讀不同 tag 之間 docker-compose.yml 的 diff，因為新增服務或重新命名服務可能會讓你的 override 變得過時，而且不會顯示任何錯誤訊息。

失效情況與實際看到的字串

容器持續重新啟動，且 docker compose ps 顯示 exited (137)。 這是核心的記憶體不足終止程序；state 區塊中的 docker inspect livecontext-app 會以 "OOMKilled": true 確認這一點。後端可能已達到 1536M 限制，或主機先耗盡記憶體。提高任何限制前，先檢查 free -m，因為在沒有可用記憶體的主機上提高容器限制，只會讓終止程序改為針對其他容器。

拉取映像檔時失敗，並顯示 no matching manifest for linux/arm64/v8 in the manifest list entries。 這些映像檔僅針對 linux/amd64 發佈。Arm VPS 無法使用已發佈的映像檔執行此堆疊，而透過 QEMU 模擬執行 JVM 加 Chromium 的速度過慢。請改用 x86 方案。

Bind for 0.0.0.0:3000 failed: port is already allocated。 主機上的其他程序已經占用該埠。請在 docker/.env.ce 中變更 FRONTEND_PORT，或套用上方的覆寫設定，完全不要發佈任何埠。

UI 已啟動，但加入代理後登入請求失敗。 瀏覽器呼叫的後端來源並未由代理提供服務。開啟瀏覽器的網路分頁，查看失敗請求使用的主機名稱。將 GATEWAY_PUBLIC_URL 設為公開後端 URL，然後重新建立 frontend 容器，因為該值會在啟動時讀取。

所有服務狀態都正常，但工作流程中上傳的檔案消失。 檢查 minio-init，確認其顯示 exited (0)，而不是非零代碼。如果從未建立 workflow-files bucket，後端就沒有儲存物件的位置。

選擇 LiveContext 或 n8n

當代理程式是核心需求時，選擇 LiveContext：如果您希望模型建立並執行自動化流程，並接受使用 8 GB 主機及 Java 服務作為代價。若您需要可預測的工作流程、大型節點函式庫，以及能與其他服務共用 VPS 的資源占用量，則選擇 n8n。本節所述版本仍較新，v0.2.11 截至 August 2026，因此每次升級前都應固定 tag，並閱讀 release notes。若要了解更廣泛的選項，包括介於這兩者之間的工具，請參閱我們整理的 self-hosted n8n 替代方案，不要只比較這兩項工具。

FAQ

自架 LiveContext 需要多少 RAM？

請預留 8 GB。上游 README 將 4 GB 列為最低需求，並建議使用 8 GB；隨附的 compose 檔案也符合這項規格：僅 backend 的上限就是 1536 MB，5 個基礎服務合計接近 3 GB，且尚未計入無上限的 frontend 容器。啟用 browser agent profile 後，Chromium 還會增加 2048 MB，並多出一個 SearXNG 容器，因此此時 8 GB 已不是可選容量。

可以在 Arm VPS 上執行 LiveContext 嗎？

不行。所有已發布的 image 都是為 linux/amd64 建置，因此在 Arm 方案上執行 docker compose up 時，會在 pull 階段因 no matching manifest for linux/arm64/v8 in the manifest list entries 而失敗。理論上可以透過 QEMU 模擬執行，但對 JVM 工作負載而言，實務上無法使用。請選擇 x86 方案。

應該在哪裡放置 model API key？

在 docker/.env.ce 中，以 ANTHROPIC_API_KEY、OPENAI_API_KEY 或 GOOGLE_API_KEY 的形式設定，並在首次啟動前完成。backend 和 bridge 會在啟動時讀取此設定，而且它會套用至整個 instance，而非單一使用者。請將檔案權限設為 mode 600，並使用僅為此伺服器建立的 key，以便個別撤銷。也請在 provider console 中設定支出上限，因為這是唯一存在於機器外部的限制。

如何備份 LiveContext？

需要備份 3 項：livecontext 資料庫的 pg_dump、MinIO volume 的副本，以及 docker/.env.ce 檔案。建立前兩項備份時，請先停止 livecontext 和 frontend 服務，讓資料庫與 object store 保持一致。env 檔案也很重要，因為 workflow 中儲存的 credentials 是使用 CREDENTIAL_ENCRYPTION_PASSWORD 和 CREDENTIAL_ENCRYPTION_SALT 加密；如果還原時缺少這些值，新主機上的任何元件都無法讀取 credential 資料列。

為什麼 backend 在開機後會停留在 health: starting 數分鐘？

compose healthcheck 會設定 start_period: 120s，並輪詢 /actuator/health，因此 Docker 會在執行 schema migration 和工具註冊時，將服務回報為 starting。首次啟動需要 2 到 3 分鐘是正常情況。如果服務始終未變為 healthy，請讀取 docker compose logs -f livecontext。如果 stack 停在 migration 階段，通常表示它指向較新 release 使用的 database volume。