n8n 部署教程：自建自动化工作流平台

摘要

n8n 用节点连线的方式把不同系统串联起来，实现数据同步、定时任务和事件触发的自动化，不需要为每个集成场景单独写代码。本文完成 n8n 的自建部署，涵盖资源规划、Docker 部署、Webhook 地址配置、凭据加密、定时与触发工作流的构建验证，以及数据库切换和备份策略。

一、n8n 适合做什么

n8n 属于工作流自动化工具，核心能力是把 A 系统的事件转换成 B 系统的动作。常见用途：

• 定时从某个接口拉取数据，处理后写入表格或数据库。
• 表单提交后自动创建工单并发送通知。
• 监控某个数据源的变化，满足条件时触发告警。
• 把多个平台的数据汇总成日报。
• 接收 Webhook 回调，做转换后转发到内部系统。

选择自建而非使用托管服务的理由通常是：处理的数据不便经过第三方、需要访问内网系统、或工作流执行量较大希望控制成本。

需要说明适用边界：n8n 擅长的是把已有系统连起来做流程编排，不适合承担高并发的实时数据处理。单实例的默认部署方式适合中小规模使用，执行量很大时需要额外设计队列模式和多副本。

二、资源规划与数据库选择

n8n 本身比较轻量，资源消耗主要来自工作流的执行。如果工作流中包含处理大文件或大批量数据的节点，内存需求会上升。

数据库选择是个需要提前决定的事：

n8n 默认使用 SQLite，配置简单，适合个人使用和工作流数量不多的场景。但随着执行历史累积，SQLite 在并发写入时可能出现性能瓶颈。

如果计划长期使用、工作流较多或有多人协作，建议从一开始就用 PostgreSQL。中途从 SQLite 迁移到 PostgreSQL 需要额外的数据迁移工作，不如一开始定好。

本文按 PostgreSQL 部署，因为它更适合长期使用。

需要放通的端口：

三、部署 n8n

mkdir -p ~/apps/n8n && cd ~/apps/n8n

编写 compose.yaml：

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: 替换为强密码
      POSTGRES_DB: n8n
    volumes:
      - pg-data:/var/lib/postgresql/data
    restart: unless-stopped

  n8n:
    image: n8nio/n8n:1.70.1
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: 与上面保持一致
      N8N_HOST: flow.example.com
      N8N_PROTOCOL: https
      N8N_PORT: 5678
      WEBHOOK_URL: https://flow.example.com/
      N8N_ENCRYPTION_KEY: 替换为随机长字符串
      GENERIC_TIMEZONE: Asia/Shanghai
      TZ: Asia/Shanghai
      N8N_DIAGNOSTICS_ENABLED: "false"
    volumes:
      - n8n-data:/home/node/.n8n
    depends_on:
      - postgres
    restart: unless-stopped

volumes:
  pg-data:
  n8n-data:

几处配置需要重点理解：

N8N_ENCRYPTION_KEY 用于加密存储各类第三方服务的凭据。生成一个足够随机的值：

openssl rand -hex 32

这个密钥必须在首次启动前设定好并妥善保存。它丢失后所有已保存的凭据都无法解密，需要全部重新配置。备份时这个密钥要和数据一起保存，否则恢复出来的数据是打不开的。

WEBHOOK_URL 决定生成的 Webhook 地址。如果不设置或设置错误，n8n 会用内部地址生成回调链接，外部系统无法访问。这是 Webhook 类工作流最常见的失败原因。

GENERIC_TIMEZONE 影响定时触发器的执行时间。不设置会使用默认时区，导致定时任务在预期之外的时间执行。

端口绑定到 127.0.0.1 意味着必须经过反向代理访问，比直接暴露更安全。

启动服务：

docker compose up -d
docker compose ps
docker compose logs n8n --tail 50

四、配置域名与 HTTPS

先在域名服务商处添加 A 记录，解析生效后验证：

dig +short flow.example.com

配置反向代理，以 Caddy 为例：

flow.example.com {
    reverse_proxy 127.0.0.1:5678
    request_body {
        max_size 100MB
    }
}

n8n 的编辑界面依赖长连接实现实时更新，Caddy 会自动处理协议升级。使用 Nginx 时需要手动添加协议升级相关请求头，否则编辑界面会出现连接异常。

request_body max_size 需要覆盖工作流中可能处理的最大文件。

服务器位于中国内地且使用域名对外提供服务时，需要先完成 ICP 备案。

HTTPS 在这里不只是安全考虑。很多第三方平台要求 Webhook 回调地址必须是 HTTPS，否则拒绝配置。所以证书是必备项，不是可选优化。

五、初始化与安全设置

访问域名，首次打开会引导创建账号。这个账号拥有全部权限，密码要足够强。

登录后先处理几项设置：

1. 确认时区设置正确，可以在设置中查看。
2. 如果多人使用，创建独立账号而不是共用。
3. 检查是否开启了不必要的公开访问。

关于访问控制，n8n 后台包含所有工作流配置和第三方服务凭据，属于高价值目标。建议：

• 在控制台防火墙规则中限制 443 端口的来源 IP，只允许自己的固定 IP 或办公网访问。
• 如果必须对外开放（例如需要接收公网 Webhook），可以只放通 Webhook 路径，编辑界面走内网或 SSH 转发访问。
• 账号开启强密码，不要使用默认或简单密码。

Webhook 路径需要公网可达，但编辑界面不需要。这两者可以在反向代理层做区分。

六、构建工作流并验证

用两类典型工作流验证部署是否真正可用。

验证一：定时触发工作流

这类工作流验证的是调度器和时区配置。

1. 新建工作流，添加一个定时触发节点。
2. 设置为每分钟执行一次（测试用，之后改回实际频率）。
3. 后面接一个简单的处理节点，例如设置一个固定值。
4. 保存并激活工作流。
5. 等待几分钟，在执行历史中查看是否按预期时间触发。

重点确认执行时间是否符合预期时区。如果时间偏差数小时，说明时区配置有问题。

验证二：Webhook 触发工作流

这类工作流验证的是外部可达性和地址配置。

1. 新建工作流，添加一个 Webhook 触发节点。
2. 保存后复制生成的 Webhook 地址。
3. 检查这个地址是否是公网可访问的域名，而不是内网地址或 localhost。如果不对，说明 WEBHOOK_URL 配置有误。
4. 激活工作流。
5. 从外部发起一次请求测试：

curl -X POST https://flow.example.com/webhook/你的路径 \
  -H "Content-Type: application/json" \
  -d '{"test":"hello"}'

1. 在执行历史中确认收到了这次调用，且数据正确。

这一步必须从服务器之外的网络发起测试。在服务器本机测试会走本地回环，不能验证公网可达性。

验证三：凭据可正常保存和使用

配置一个第三方服务的凭据（例如邮件发送或某个 API），在工作流中实际调用一次。能成功说明凭据加密和解密都正常工作。

七、常见问题与排查

Webhook 地址是内网地址或无法从外部访问

检查 WEBHOOK_URL 和 N8N_HOST 配置。修改后需要重启容器：

docker compose down && docker compose up -d

定时任务在错误的时间执行

时区配置问题。确认 GENERIC_TIMEZONE 和 TZ 都已设置为期望时区。工作流内的定时节点也可以单独指定时区，检查是否被覆盖。

编辑界面频繁断开或不实时更新

反向代理未正确处理长连接协议升级。使用 Nginx 时补充相应配置。

提示凭据无法解密

多为 N8N_ENCRYPTION_KEY 发生变化所致。恢复原密钥即可。如果密钥确实丢失，所有凭据需要重新配置，数据本身不受影响。这也说明了为什么这个密钥必须妥善备份。

工作流执行失败但看不出原因

在执行历史中点开具体执行记录，可以看到每个节点的输入输出和错误信息。这是排查工作流逻辑问题的主要手段。

执行历史占满磁盘

n8n 默认保留全部执行记录。工作流频繁执行时数据增长很快。可以通过环境变量配置执行记录的保留策略，只保留一段时间内或一定数量的记录。

查看当前占用：

docker compose exec postgres psql -U n8n -d n8n -c "\dt+"
df -h

内存占用过高

多为某个工作流处理了大批量数据所致。检查是否有节点一次性加载了过多数据，考虑改为分批处理。

容器启动失败

查看日志定位。常见原因是数据库连接失败（密码不一致）、加密密钥格式问题、端口被占用。

八、备份与维护

备份要覆盖三部分

加密密钥必须和数据库备份一起保存。 只有数据库没有密钥，凭据部分是打不开的，等于所有第三方服务连接都要重新配置。这是 n8n 备份最容易出错的地方。

数据库备份示例：

docker compose exec -T postgres \
  pg_dump -U n8n n8n | gzip > ~/n8n-db-$(date +%Y%m%d).sql.gz

写成脚本加入定时任务，并把备份同步到对象存储。备份文件中包含加密后的凭据信息，属于敏感数据，存储桶权限必须设为私有。

导出工作流作为额外保障

除了数据库备份，建议把重要工作流导出为 JSON 文件单独保存。这样即使数据库无法恢复，工作流逻辑也不会丢失，重新导入即可。

恢复演练

用备份的数据库和加密密钥在另一个环境还原，确认工作流列表完整、凭据可用。这一步能验证密钥是否真的备份对了。

变更前创建快照：升级版本前给实例创建快照。n8n 迭代较快，部分版本升级涉及数据库结构变更。回滚会把整块系统盘恢复到快照时间点，之后写入的数据会被清除，运行中的实例会自动关机。使用存储型套餐的实例不支持创建快照。

日常检查

• 每周确认备份任务执行成功。
• 查看执行历史中的失败记录，及时处理反复失败的工作流。
• 关注磁盘水位，必要时调整执行记录保留策略。
• 定期审阅已保存的凭据，清理不再使用的连接。

安全与合规要点

• 凭据是最敏感的部分。n8n 中保存的第三方服务凭据一旦泄露，影响范围是所有被连接的系统。加密密钥和备份文件都要严格保管。
• 工作流处理的数据要符合来源系统的使用约定。从第三方平台拉取数据时，遵守其接口调用频率限制和数据使用条款，不要用自动化手段绕过平台的访问限制。
• 涉及个人信息的工作流要注意最小必要原则，不要把不需要的个人敏感字段流转到其他系统。
• 发送通知类工作流要防止误触发造成骚扰，测试阶段建议先发送到自己的测试渠道。

部署完成后，如果需要把工作流产生的数据落到数据库长期保存，或为平台配置更精细的访问控制，可以作为下一步方向。

自动化平台这类长期运行的轻量服务，轻量应用服务器的入门规格即可承载并配合快照做环境保护；需要更灵活的规格调整时可使用云服务器 CVM，备份归档可使用对象存储 COS。