自行托管 LiveContext：n8n 替代方案与 VPS 配置

LiveContext 是什么，以及运行成本

要自行托管 LiveContext，您需要一台内存约为 8 GB 的 VPS。LiveContext CE 是一个开源自动化平台，可在自动化流程中运行 AI 代理。它以 Docker Compose 堆栈形式发布，包含 6 个围绕 Java 后端构建的容器。上游 README 要求至少 4 GB 内存，建议使用 8 GB；compose 文件展示了这些内存的分配位置。

该项目位于 GitHub：livecontext-ai/livecontext-ce，采用 AGPL-3.0 许可证。截至 2026 年 8 月，当前版本为 v0.2.11，于 2026 年 8 月 3 日发布。所有镜像仅为 linux/amd64 构建，因此无法使用廉价的 Arm 方案。本指南固定使用该标签，将堆栈置于反向代理之后，并介绍上游文档未涵盖的备份流程。

在自行托管 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 写为最低配置，而不是建议配置。

可选 profile 会使所需配置提升到 8 GB。浏览器代理 profile 会在 SearXNG 搜索实例旁添加一个内存上限为 2048 MB 的 Chromium 容器，renderer profile 还会为截图和 PDF 额外增加 1024 MB。除非启用相应 profile，否则这两个服务都不会启动，因此请在需要前保持禁用。该 SearXNG 容器用于充当代理的搜索后端，因此它返回的页面会以不受信任文本的形式进入提示词；为 AI 代理提供 SearXNG 网页搜索的详细实现正是通过这一信任边界完成的。

如果您已经运行 n8n，请计划替换它，而不是在其基础上继续添加服务。我们关于使用 Docker 和 HTTPS 在 VPS 上运行 n8n 的指南中的堆栈由一个 Node 进程和 Postgres 组成，在小型 VPS 上运行没有问题。仅 LiveContext 后端预留的资源，就超过了整个 n8n 堆栈的使用量。在同一台 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 标签可能在您不知情的情况下发生变化，而后端每次启动都会执行数据库迁移。因此，意外拉取镜像可能在凌晨 3 点将数据库 schema 向前迁移；除非从备份恢复，否则无法回退。

首次启动前编辑 docker/.env.ce（下一节会列出需要修改的内容），然后启动整个服务栈。

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

本指南中的每条 Compose 命令都使用相同的 --env-file 标志。Compose 会在每次调用时重新读取该文件。因此，不带此标志的命令会回退到 Compose 文件中预设的默认值，并可能发布与您配置不同的端口。

后端健康检查的 start_period 为 120s，并轮询 /actuator/health。因此，在 schema 迁移和工具注册运行期间，docker compose ps 会将 livecontext 服务报告为 health: starting，这一状态大约会持续前两分钟。这是正常现象。您可以在服务器上快速检查：

curl -s localhost:8080/actuator/health

该命令应输出 {"status":"UP"}。看到此输出后，请通过端口 3000 打开 Web UI。您创建的第一个账户会成为管理员，因此请在端口被其他人访问之前创建自己的账户。这是第一天不应将端口 3000 发布到互联网的最重要原因。

必须修改的环境变量

示例文件提供了可在笔记本电脑上启动整个栈的默认值。其中一些值不适合用于公网服务器。

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。这两个数据库端口都没有发布到主机，因此不会直接暴露。但之后连接到同一网络的任何容器都可以使用文档中的默认凭据访问它们。
• CREDENTIAL_ENCRYPTION_PASSWORD 和 CREDENTIAL_ENCRYPTION_SALT 留空时会自动生成。请改为手动设置。工作流保存的凭据使用这一对值加密。因此，将数据库转储恢复到新服务器时，如果没有相同的密码和盐值，恢复出的凭据记录将无法解密。设置后不要再修改，并将 docker/.env.ce 作为备份的一部分保存。
• FRONTEND_PORT 和 BACKEND_PORT 会分别替换端口映射中的 ${FRONTEND_PORT:-3000}:3000 和 ${BACKEND_PORT:-8080}:8080。示例环境变量文件会显式设置这两个值，而且其中的默认值不一定是 3000 和 8080。请读取你自己的文件，不要直接假定端口值。
• GATEWAY_PUBLIC_URL 是后端面向浏览器的来源地址。只要使用反向代理，它就会影响请求处理。请参阅下一节。
• 模型密钥（ANTHROPIC_API_KEY、OPENAI_API_KEY、GOOGLE_API_KEY，以及可选的 MISTRAL_API_KEY 或 DEEPSEEK_API_KEY）以明文保存在此处。只填写你实际使用的服务提供商对应的密钥。

六个容器的作用

• postgres 将 pgvector/pgvector:pg16 作为容器 livecontext-db 运行，其中存放名为 livecontext 的数据库。这里需要使用 pgvector 扩展执行嵌入向量搜索，因此不能使用普通的 postgres:16 镜像。
• redis 使用 redis:7-alpine 运行，并配置了 appendonly yes 和 --maxmemory-policy noeviction。这是有意为之：Redis 在这里保存队列和运行状态，因此达到内存上限时会向写入方返回错误，而不是静默丢弃键。能够看到的错误，总比悄无声息丢失的工作更好。
• minio 是用于存储在工作流中传递的文件的 S3 兼容对象存储。一个只运行一次的 minio-init 容器会在启动时执行 mc mb myminio/workflow-files --ignore-existing，创建存储桶，然后退出。在 docker compose ps 中看到 minio-init 为 exited (0)，说明状态正常。
• bridge 保存 CLI 适配器和 MCP（模型上下文协议）工具。它在 Docker 网络内部监听 8093 端口，不发布到主机。
• livecontext 是后端，由一个监听 8080 端口的 Java 21 单体应用组成。它运行工作流引擎、调度器和代理。
• frontend 是监听 3000 端口的 Next.js Web UI。只有最后两个容器的端口发布到主机。

状态保存在五个命名卷中：livecontext_data 用于 Postgres，另外四个是 livecontext_redis、livecontext_minio、livecontext_keys 和 livecontext_logs。Compose 会为这些卷添加项目名称前缀。项目名称默认为目录名，因此磁盘上的实际卷名可能类似 livecontext-ce_livecontext_minio。运行 docker volume ls，并在编写针对这些卷的备份脚本前复制准确的名称。

docker compose down -v 会删除全部五个卷。这是文档规定的重新开始方式，也是丢失所有已创建工作流的最快方式。-v 就是两者之间的全部区别。

将其置于 Traefik 后，而不是发布端口 3000

在公网 VPS 上发布端口 3000 和 8080，会让应用在没有 TLS（传输层安全）保护、且管理员注册入口前没有访问控制的情况下直接暴露。仅有 ufw 规则并不足够，因为 Docker 会为已发布端口插入自己的 iptables 规则，并将其置于 ufw 管理的链之前。因此，即使 ufw 显示拒绝该端口，发布到 0.0.0.0 的端口仍然可以访问。

正确做法是不发布任何端口，让代理通过共享的 Docker 网络访问容器。在仓库根目录创建 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 列表中，因为为服务命名任何网络都会替换默认网络。省略它会切断前端与 Postgres 和 Redis 的连接。启动任何服务前，先确认合并后的配置：

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

路由器、证书解析器以及 HTTP 到 HTTPS 的重定向配置与其他应用相同。因此，请参阅我们的 Traefik 反向代理指南，了解如何在一台 VPS 上运行多个应用，不要在这里重新编写 TLS 配置。将一个主机名路由到 frontend 的端口 3000，再将第二个主机名路由到 livecontext 的端口 8080。

第二个主机名不是可选项。Web UI 会在浏览器中调用后端，因此后端需要一个浏览器可以访问的独立来源。将 GATEWAY_PUBLIC_URL 设置为 docker/.env.ce 中的后端 URL，例如 https://lc-api.example.com。如果跳过此设置，页面可以正常加载，但所有操作都会失败，因为 UI 会根据打开页面时使用的地址解析后端来源，并调用代理从未发布的端口。

由于任何首先访问注册页面的人都可以使用它，建议在前端路由器上配置 forward auth。这样，用户必须先在代理层完成身份验证，才能看到该页面。这正是将 Authentik 作为自有 SSO 层运行在相同 Traefik 配置上增加的功能。

模型密钥放在哪里，以及为什么空闲实例仍会产生费用

代理运行在此处的自动化环境中，因此其成本模型不同于普通工作流工具。提供商密钥位于 docker/.env.ce 中，作为 ANTHROPIC_API_KEY 或 OPENAI_API_KEY 存在。后端和桥接程序会在启动时读取该密钥，并将其应用于整个实例。密钥不会按用户隔离。实例上的任何账户只要能够构建代理，就会消耗该密钥对应的额度。第一个注册的用户是管理员。

以下 3 个做法可以让费用保持可预测。为此 VPS 单独创建一个提供商密钥，这样撤销该密钥时不会影响其他内容。在提供商控制台中设置硬性消费上限，因为这是机器之外唯一由您控制的限制。然后使用 LiveContext 提供的每个代理信用额度和每个代理指标，这样在您发现问题前，单个循环不会耗尽密钥额度。

代理进入计划任务后，空闲成本不会归零。无论是否有人查看，计划任务触发器都会执行，每次执行都会发送令牌。每 5 分钟执行一次的计划任务每天会运行 288 次。即使代理读取页面后决定不执行任何操作，读取页面仍会产生费用。先让代理使用 webhook 或聊天触发器运行，观察一周的实际支出，确认每次运行的成本后，再改用计划任务。

备份 Postgres 和对象存储

这里有两个数据存储和一个密钥，丢失其中任何一个都会导致实例丢失。在同一时间窗口内备份数据库和存储桶，并先停止后端服务，确保数据库行导出后不会再写入对应文件。

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。然后复制对象存储卷，并使用 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 语句，而不是只显示一行错误信息。然后将这 3 个文件全部复制到服务器之外。只保存在受保护服务器上的备份不能算作备份。

要将数据恢复到全新的服务器，请安装相同的 tag，将保存的 docker/.env.ce 放回原位，以确保凭据加密密码和 salt 匹配；启动一次整个栈以创建卷，停止后端服务，然后加载转储文件：

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

升级，以及升级失败时的恢复

每次都先创建转储。后端会在启动时应用架构迁移，而且迁移只能向前执行。因此，错误升级后切换回旧标签，会让旧代码运行在更新后的架构上。回滚意味着恢复转储，所以必须先创建转储。

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 设置为第三条命令输出的列表中选定的标签。持续监控后端日志，直到健康检查端点再次返回响应。您的 docker-compose.override.yml 未被跟踪，因此执行 git checkout 会保留它，但请查看标签之间 docker-compose.yml 的差异，因为新增服务或重命名服务可能使您的覆盖配置过时，而不会显示任何错误消息。

故障模式及对应的提示信息

容器持续重启，并且 docker compose ps 显示 exited (137)。 这是内核的内存不足终止机制。状态块中的 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，然后重新创建前端容器，因为该值会在启动时读取。

所有服务都正常，但工作流中上传的文件消失了。 检查 minio-init，确认其显示为 exited (0)，而不是非零代码。如果从未创建过存储桶 workflow-files，后端就没有存放对象的位置。

选择 LiveContext 还是 n8n

如果智能体是核心，应选择 LiveContext：您希望模型构建并运行自动化流程，并接受将 8 GB 服务器和 Java 服务作为代价。如果您需要确定性工作流、大型节点库，以及能够与其他服务共享 VPS 的较小资源占用，应选择 n8n。这里的版本号都较新，v0.2.11 截至 August 2026，因此请固定镜像标签，并在每次升级前阅读发行说明。如需了解更广泛的选择，包括处于这两种方案之间的工具，请参阅我们整理的自托管 n8n 替代方案，不要只阅读这两者的对比。

FAQ

自托管 LiveContext 需要多少 RAM？

按 8 GB 规划。上游 README 将 4 GB 列为最低要求、8 GB 列为建议配置，随附的 compose 文件也与此一致：仅后端的内存上限就是 1536 MB，5 个基础服务合计略低于 3 GB，且不包括没有内存上限的前端容器。启用浏览器代理配置后，Chromium 和一个 SearXNG 容器还会额外占用 2048 MB，此时 8 GB 就不再是可选配置。

可以在 Arm VPS 上运行 LiveContext 吗？

不可以。所有已发布的镜像都针对 linux/amd64 构建，因此在 Arm 方案上拉取 docker compose up 时会因 no matching manifest for linux/arm64/v8 in the manifest list entries 失败。理论上可以通过 QEMU 模拟运行，但对于 JVM 工作负载，实际不可用。请选择 x86 方案。

应将模型 API 密钥放在哪里？

在首次启动前，将其写入 docker/.env.ce，格式为 ANTHROPIC_API_KEY、OPENAI_API_KEY 或 GOOGLE_API_KEY。后端和桥接服务会在启动时读取该密钥，并将其应用于整个实例，而不是单个用户。将文件权限设为 600，并使用专门为此服务器创建的密钥，以便单独撤销该密钥；同时在服务提供商控制台中设置消费上限，因为这是唯一不在本机上的限制。

如何备份 LiveContext？

需要备份3项：livecontext 数据库的 pg_dump、MinIO 卷的副本，以及 docker/.env.ce 文件。在执行前两项操作时，停止 livecontext 和 frontend 服务，以确保数据库与对象存储中的数据一致。环境文件也很重要，因为工作流中保存的凭据使用 CREDENTIAL_ENCRYPTION_PASSWORD 和 CREDENTIAL_ENCRYPTION_SALT 加密；恢复时如果缺少这些值，新服务器上的任何组件都无法读取这些凭据记录。

为什么后端启动后会在 health: starting 停留数分钟？

compose 健康检查会设置 start_period: 120s 并轮询 /actuator/health，因此在执行架构迁移和工具注册期间，Docker 会将服务报告为正在启动。首次启动耗时2到3分钟属于正常现象。如果服务始终无法变为健康状态，请查看 docker compose logs -f livecontext。如果堆栈停在迁移步骤，通常表示它使用的是来自较新版本的数据库卷。