在 VPS 上自托管 n8n。
您的自动化引擎，您的凭证，您的物理机器。

n8n 是一个工作流自动化引擎：一块可视化画布，您在其中把一个触发器——webhook、计划任务、数据库中的一条新记录、队列中的一条消息——接入一串节点，这些节点调用 API、转换数据、按条件分支、运行任意的 JavaScript 或 Python，并把结果交给流程中的下一环。软件本身内置了几百个集成节点，再加上一个能覆盖其余一切场景的通用 HTTP Request 节点。从 1.x 系列开始，它还带有 AI Agent 和 LLM 节点，这也是为什么 2026 年安装它的人中，有相当大一部分是在搭建智能体，而不是传统的 ETL 管道。

在您输入第一行命令之前，真正重要的是许可证问题，因为 n8n 并不是 OSI 意义上的开源软件，这个区别不只是学术上的。核心部分以 Sustainable Use License 发布：一份非独占、免版税、面向全球的授权，允许您出于内部业务目的，以及个人或非商业用途，使用、复制、修改和分发该软件。它所保留的，是向他人就 n8n 或其衍生品收费的权利——正是这一条款，排除了在此基础上搭建一款付费“托管 n8n”产品的可能。另外，文件名中带 .ee.，或路径中带 .ee 的任何文件，完全被排除在该许可证之外，需要付费的 n8n Enterprise License。

说得明白一点：在 VPS 上运行 n8n，用来自动化您自己的公司、您以服务形式为客户交付的工作，或者您自己的个人生活，一直都在免费授权范围之内。把 n8n 作为托管产品出售则不在此列。网上几乎每一场“n8n 到底是不是免费的”争论，说到底都是两个人隔着这条界线各说各话。

成本这一面。 n8n Cloud 按执行次数计价：Starter 套餐按年计费，每月 €20，包含 2,500 次执行；Pro 套餐每月 €50，包含 10,000 次；Business 套餐每月 €667，包含 40,000 次。自托管的话，执行次数根本不是一项计费条目——它只受这台机器有多少 CPU 和内存的限制。一个每五分钟轮询一次 API 的工作流，单独就会消耗每月 8,640 次执行；在 Cloud 上，光是这一个工作流就已经迫使您升级到 Pro 档位，而在一台 $3.90 的 VPS 上，这不过是空闲 CPU 里一个微不足道的零头。

云端价格为 n8n.io 于 2026 年 8 月公布的按年计费价格；按月计费更贵。这笔权衡不只是钱的问题——自托管会把升级、备份、TLS 续期和正常运行时间的责任都转移到您这一边。

在控制面板中：Order → VPS → Sentinel，镜像选 Debian 12。开户无需邮箱地址，全程不要求任何身份证件，账单可用 Monero、Bitcoin、Lightning 或其他任一支持的资产结算。选择节点位置时，应以到您所自动化的服务的延迟为准，而不是到您自己的延迟——一台自动化服务器与 API 对话的频率，远高于与您对话的频率。

在您动手配置服务器之前，先创建 DNS 记录：为 n8n.example.com 添加一条指向该 VPS IPv4 的 A 记录，如果使用 IPv6，再添加一条 AAAA 记录。这一步必须先做，因为 Caddy 一旦启动就会立刻向 Let's Encrypt 申请证书，而针对一个尚未解析的域名申请证书会失败——然后进入退避等待，您就会白白花上二十分钟纳闷网站为什么打不开。

给 DNS 一分钟时间生效，并在继续之前，从您自己的机器上确认一下：

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

在任何服务监听公网端口之前，先执行首小时加固清单——仅密钥 SSH、只放行 22、80、443 端口且不留其他缺口的防火墙，以及无人值守的安全更新。自动化服务器就是一个凭证保险柜，值得花这整整一个小时。

先创建目录，并生成两个密钥。请现在按此顺序生成，并随生成随粘贴进 .env——尤其是加密密钥，必须在 n8n 首次启动之前就已存在，而不是之后。

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

立即锁定该文件——它保管着这个实例日后将存储的每一项凭证所依赖的密钥：

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

两个值得说明的设计决定。 第一，n8n 不对外发布端口。只有 Caddy 绑定 80 和 443；n8n 在 Compose 网络内部监听 5678 端口，主机外部完全无法触及。令人意外的是，相当数量的自托管 n8n 实例直接以 5678 端口暴露在公网上、前面没有任何 TLS，而扫描暴露服务的搜索引擎会把它们收录进去。第二，即便现在工作流数据已经保存在 PostgreSQL 中，n8n 数据卷仍然保持挂载——那个目录里仍然存放着实例设置、日志文件和源码控制相关的资源。

启动它：

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

一个能启动、显示编辑器并跑通手动测试的 n8n，还算不上真正可用的 n8n。悄无声息出问题的那一半是入站 webhook，而且它出错的方式常常看起来像是第三方服务的责任。

WEBHOOK_URL. 没有它，n8n 会根据 N8N_HOST 和 N8N_PORT 来构建 webhook 地址，给您的可能是类似 http://localhost:5678/webhook/abc 这样的地址——而当您把它粘贴进 Stripe 或 GitHub 时，那里永远无法访问到它。上面的 Compose 文件把 WEBHOOK_URL 设为公网 HTTPS 根地址，这才是编辑器会显示、外部世界也真正能够调用的地址。

N8N_EDITOR_BASE_URL. 这是 n8n 在它发送的邮件——密码重置、用户邀请——中所使用链接的公网地址。这里配错了，意味着一条指向 localhost 的邀请链接，招来的是同事的求助工单，而不是某个集成出了故障。

N8N_PROXY_HOPS. n8n 从 X-Forwarded-For 中读取客户端 IP，而它只信任这个数字所指定的跳数。前面只有一层反向代理时——也就是本方案中的 Caddy——这个值应为 1。如果再在 Caddy 前面加一层 Cloudflare，就变成 2。如果保持默认的 0，每个请求看起来都会像是来自代理本身，这会悄悄破坏限速以及您工作流中任何基于 IP 的逻辑。

N8N_SECURE_COOKIE. 它默认是 true，意味着会话 cookie 只会通过 HTTPS 发送。这是正确的设置，本方案也满足这一点。了解这一点很有必要，因为它解释了首次尝试用普通 http 访问时的经典症状：登录表单接受了密码，随后又把您带回登录表单，如此循环往复。正确的解决办法是配好 TLS，而不是把这个开关关掉。

认真测试一下。创建一个带 Webhook 节点的工作流，激活它，复制生产地址（Production URL），然后从一台不是服务器本身的机器上调用它：

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

这个区别几乎每个人都曾踩过一次坑：测试地址（Test URL）只在您打开编辑器、并启用了“Listen for test event”时才会监听。生产地址（Production URL）只有在工作流被切换为 Active 状态时才存在。一个在编辑器里能用、在生产环境却返回 404 的 webhook，几乎总是因为工作流没有被激活。

n8n 默认运行在常规模式下：为编辑器提供服务、接收 webhook 的进程，同时也执行工作流。这种方式简单且没有问题，直到某个耗时长的工作流开始让其他工作流排队等待。症状很明显——执行长时间停留在“运行中”状态，编辑器变得迟钝，本该 200 毫秒内响应的 webhook 变成了八秒才响应。

队列模式把工作拆开来做。主实例保留编辑器、触发器和 webhook 端点，把执行 ID 推送到 Redis 中；独立的 worker 进程从中取出，从 PostgreSQL 加载工作流，执行它，再通过 Redis 回报结果。这种架构衍生出三条规则，忽视其中任何一条都会吃苦头：所有实例必须共享同一个 PostgreSQL 数据库，所有实例必须携带相同的 N8N_ENCRYPTION_KEY，而且完全不支持 SQLite。

对 Compose 文件的新增内容是一个 Redis 服务和一个 worker 服务，后者其实是同一个 n8n 镜像，只是以 worker 命令运行：

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

同时也要在主 n8n 服务中加入 EXECUTIONS_MODE=queue 和 QUEUE_BULL_REDIS_HOST=redis——两端必须在模式上保持一致。有两个选项值得从第一天起就设置好：OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true，这样在编辑器中点击“测试工作流”就不会占用主进程；以及 N8N_GRACEFUL_SHUTDOWN_TIMEOUT，它默认为 30 秒，决定了重新部署时 worker 有多长时间完成当前任务。如果您的工作流通常运行超过半分钟，就调高这个值，否则每次部署都会中断正在进行的工作。

不要从这里开始。队列模式增加了两个活动部件，也带来了一整类常规模式根本不存在的故障。请留在常规模式下，直到您能亲眼看到队列在增长，或某个工作流阻塞了另一个，再在同一台机器上加入单个 worker，然后才考虑增加第二台机器。这一演进路径——Sentinel 跑常规模式、Garrison 配一个 worker、Ravelin 配三个——覆盖了除真正大规模部署之外的所有情形。