n8n本地部署实战：用Docker自托管自动化工作流-代码聚汇网

n8n本地部署实战：用Docker自托管自动化工作流

n8nDocker本地部署

|难度：普通|阅读约 40 分钟

坦白说，我一开始对n8n是没有那么上心的。当时团队里已经有人引入了某商业iPaaS平台，我第一反应是"又来一个工具，能比现有方案好到哪去"。但后面被拉去处理一个对接需求：要把企业微信群机器人和内部工单系统打通，还要定期抓取几个政府公开数据源做汇总推送。商业平台报了个一年大几万的订阅价，数据还要走他们的云。我一想,这不行，领导也不批预算。于是重新抱起n8n，用Docker在自己服务器上撸了一遍，半天时间就搞定了整个流程。从那以后，n8n就成了我本地自动化工作流的主力。

如果你也在找一款可以自托管、可视化编排、能连接各种API和数据库、还不用被厂商绑死的自动化工具，那这篇关于n8n本地部署的文章就是为你准备的。文本会从最基础的部署方式开始，逐步讲到数据持久化、安全加固、升级备份，以及和当前很火的本地大模型（比如Ollama、DeepSeek）怎么联动。无论你是第一次接触n8n，还是部署完了想优化现有实例，都可以在这篇里找到可落地的参考。

1. 为什么放着免费的云版不用，偏要自己本地部署

聊部署之前，我得先讲清楚一个问题：n8n官方本身提供Cloud版本，注册就能用，还有免费额度。那为什么还要折腾本地部署？这是我被问得最多的问题，每次我都要花几分钟解释，这里也一并说清楚。

1.1 数据隐私是大多数人绕不开的门槛

n8n Cloud的数据链路简单说就是：你的工作流代码、连接的数据库地址、API密钥、凭证信息，全部会经过n8n的服务器。哪怕n8n在隐私条款里写了一大堆"加密存储""合规认证"，当你对接的是公司内部客户数据、财务对账单、医疗信息这些敏感内容时，法务和合规这一关就过不了。我见过不止一个团队，工作流搭到一半被安全部门叫停，就是因为数据出域的问题。

本地部署之后，情况就完全不同了。所有数据只在你的服务器内部流转，n8n的服务端、执行器、队列、数据库全都跑在你自己的局域网或云主机里。从物理层面就把数据出境的风险切断，这也是"本地部署"最大的价值所在。

1.2 成本与扩展成本的根本差异

n8n Cloud的计费是按"执行次数+工作流数量"来算的。项目初期可能还够用，但随着业务量增长、自动化场景越铺越多，账单会以肉眼可见的速度往上走。本地部署版本的n8n是开源的，核心功能完全免费，只有企业级功能（比如LDAP、多用户权限精细管控、队列模式）需要额外付费订阅。

我个人的观点是：如果你只有一两个人在用，工作流数量几十个以内，社区版足够了，本地部署基本就是纯省钱的方案。等到以后规模变大，也可以无缝升级到企业版，不用把已经搭好的东西推倒重来。这种"先跑起来，再按需付费"的路径，比起一开始就被SaaS订阅绑住要灵活得多。

1.3 自由度：插件、执行器、定制化

云版n8n能用的节点范围，是官方替你选好的。本地部署则完全不受限制，你可以安装社区节点包（npm install），可以自定义写一个执行器脚本，甚至给n8n打补丁，也可以让它和只在内网环境的服务通信——这在云版里是做不到的。

举一个实际案例。我们有个任务是把内部旧系统的SOAP接口封装成REST接口给新系统调用，这个旧系统的IP只能在公司内网访问，云版n8n根本连不上。本地部署后，n8n和旧系统跑在同一内网，直接在Webhook节点里填内网地址，整个流程就走通了。类似的场景还有连接本地数据库、读取内网共享盘文件、调用局域网内打印机服务等，这些都是本地部署的"主场优势"。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署方案选型：Docker 依然是省心首选

确定了要自托管之后，接下来就要选择部署方式。n8n官方提供了三种主流方式，我用表格对比一下，再讲讲各自的适用场景：

部署方式	安装难度	升级成本	资源占用	适用场景
npm全局安装	低	中	低	单机开发测试，想快速跑起来看看效果
二进制Docker部署	低	低	低	生产环境单机部署，推荐大多数团队选择
Docker Compose全家桶	中	低	中	需要搭配PostgreSQL、Redis、反向代理的生产部署
官方Desktop App	极低	自动	中	纯本地个人使用，不涉及服务器和公网访问

我推荐首选Docker。原因不复杂：n8n依赖Node.js环境，不同版本对Node版本有要求，npm全局安装容易踩到依赖版本冲突；而Docker把运行环境、依赖、代码全都打包在镜像里，宿主机上不用装任何运行时，部署过程就是pull镜像+run容器这么简单。升级也方便——拉一个新镜像，重启容器就完事，出问题还能回滚到上一个镜像标签。

如果你只有一台服务器，还打算长期作为生产环境用，那我建议直接用Docker Compose方式，把n8n、PostgreSQL、Redis（可选，用于队列模式和并发控制）、Nginx（可选，用于反向代理HTTPS）一次性编排好。这样不用一台一台去装维护工具链，也方便后面迁移。

2.1 服务器配置建议

再强调一下硬件要求。n8n本身是个Node.js应用，对CPU和内存有一定要求，但不算太夸张。结合我自己的经验：

跑个位数工作流、低频触发（比如每小时执行一次）：2核4G的服务器就能跑，Docker容器内存控制在1G左右就够了。
跑几十个工作流、有高频轮询（比如每1分钟查一次数据库）：建议4核8G，内存在2G到4G之间。
如果还要在本地跑Ollama大模型做AI节点，建议CPU 8核以上，内存16G起步，否则n8n和推理进程会互相抢资源。

存储方面，系统盘建议留出20G以上，镜像本身不大（约1GB），但工作流的历史执行记录、日志文件会慢慢累积。后续我会讲日志清理和定期备份，这跟存储规划是联动的。

2.2 操作系统与运行环境准备

我在Ubuntu 22.04 LTS和Debian 12上都验证过下面的流程，国内服务器用CentOS 7的话需要把apt换成yum，并且注意Docker源配置，其他步骤大同小异。

首先是装Docker。如果你服务器上还没有Docker，执行这段：

bash复制# 使用官方安装脚本（国内服务器可先配置阿里云或清华镜像源）
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

# 启动并设置开机自启
systemctl enable --now docker

# 验证
docker --version

Docker装好之后，强烈建议顺带配置镜像加速器，不然拉取n8n镜像的速度会让人怀疑人生。在 /etc/docker/daemon.json 写入：

json复制{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://dockerproxy.com"
  ]
}

然后 systemctl restart docker 让配置生效。这一步做完，后面所有镜像拉取都会快很多，属于国内部署绕不开的实用技巧。

3. 完整部署步骤：从零到可用工作流的细节

我直接把生产环境推荐的Docker Compose配置贴出来，然后逐段解释每个关键配置的意图。这样你不仅能把它抄走，还能真正理解为什么这么配。

3.1 先说明我要搭的目标架构

我要搭建的目标是这样的：

n8n主服务运行在Docker容器内，数据存储到PostgreSQL数据库（也用Docker跑），保证数据持久化。
宿主机上安装Nginx（或者用容器跑）做反向代理，启用HTTPS，用于公网访问。
用环境变量控制n8n的时区、加密密钥、Webhook地址等关键参数。
预留Redis配置（我先不启用，注释掉），为以后升级企业版队列模式做准备。

3.2 docker-compose.yml 完整配置

创建目录：

bash复制mkdir -p /opt/n8n && cd /opt/n8n

新建 docker-compose.yml：

yaml复制version: "3.8"

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - N8N_ENCRYPTION_KEY=请替换成一长串随机字符串
      - TZ=Asia/Shanghai
      - GENERIC_TIMEZONE=Asia/Shanghai
      - WEBHOOK_URL=https://n8n.example.com
      - N8N_PROXY_HOPS=1
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
    networks:
      - n8n_network

  postgres:
    image: postgres:15
    container_name: n8n_postgres
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=请设置一个强密码
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n_network

volumes:
  n8n_data:
  postgres_data:

networks:
  n8n_network:
    driver: bridge

下面把几个关键点单独拎出来讲。

端口映射 127.0.0.1:5678:5678

这一步很多人会忽略。默认情况下，把端口直接暴露到公网非常危险，n8n新版本虽然内置了登录鉴权，但暴露公网前最好还是有一层反向代理保护。这里先用 127.0.0.1 绑定，只允许宿主机本地访问，后面由Nginx反向代理转发外部请求，这样n8n服务本身不会直接接触公网。

N8N_ENCRYPTION_KEY

这是n8n用于加密存储凭证（credentials）的主密钥。如果不设置，n8n会每次启动时自动生成一个随机值，后果就是容器重启后凭证解密失败，所有连接都会失效。所以必须手动设置一个长期固定的随机字符串。生成方式：

bash复制openssl rand -hex 32

把输出的字符串填到环境变量里。注意保管好，丢失后虽然不影响工作流定义本身，但所有密码、API Key这类凭证信息都无法解密，只能重新配置。

N8N_HOST、N8N_PROTOCOL、WEBHOOK_URL

这三个变量共同决定了n8n生成Webhook回调地址时使用的域名和协议。如果后期要用企业微信、钉钉这类平台主动调用n8n的Webhook，必须要让对外暴露的地址是可达的HTTPS地址。这里的配置思路是：公网域名 n8n.example.com，通过Nginx终止HTTPS，然后把请求反向代理到内网的 5678 端口。N8N_PROXY_HOPS=1 告诉n8n前方有一层代理，它才会正确识别由Nginx透传的 X-Forwarded-Proto 头，从而生成https链接。

数据卷

我用了一个具名卷 n8n_data 挂载到容器内 ~/.n8n，用来存放工作流定义、凭证、配置文件。又用 postgres_data 挂载PostgreSQL的数据目录。两个卷都是Docker管理的具名卷，好处是用一条命令就能备份恢复。后续我会贴实际备份命令。

3.3 启动与初始化

配置写好后，直接执行：

bash复制docker compose up -d

首次启动会拉取镜像，网络正常的话几分钟内完成。启动后，用 docker compose ps 查看状态，如果两个容器都是 running，说明已经成功运行。

如果Nginx还没配好，可以先在本机测试：

bash复制curl http://127.0.0.1:5678/healthz

返回 ok 就说明n8n服务本身已经正常运行。

3.4 Nginx反向代理配置

为了让外部通过HTTPS正常访问，我在宿主机的 /etc/nginx/sites-available/n8n.conf 里加了这么一段：

nginx复制server {
    listen 80;
    server_name n8n.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name n8n.example.com;

    ssl_certificate     /etc/nginx/ssl/n8n.example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/n8n.example.com.key;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里面最容易忽略的一点是，一定要把 X-Forwarded-Proto 设置成 $scheme（即https）。如果漏了这个，n8n会认为用户一直在通过http访问，生成的Webhook链接会错误地变成http开头，回调时被浏览器拦截。这个坑我踩过一次，排查了好几个小时才定位到。

配好后：

bash复制ln -s /etc/nginx/sites-available/n8n.conf /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

接着在浏览器访问 https://n8n.example.com，首次打开会让你填管理员邮箱和密码，设置完成之后就进入主界面了。

3.5 使用SQLite还是PostgreSQL

上面我用了PostgreSQL，其实n8n默认使用SQLite，开箱即用。那为什么还要额外装一个PostgreSQL？

我的建议是：个人实验、工作流数量不多，SQLite完全够用；但如果是服务器上长期跑，多个工作流、多个用户、同时有大量执行日志，那SQLite的单文件锁机制会成为瓶颈。尤其当多个流程并发写入日志时，SQLite容易出现 "database is locked" 错误。PostgreSQL在并发、稳定性、备份恢复方面都强太多。既然都上Docker了，多加一个PostgreSQL容器成本并不高，我建议直接一步到位。

4. 部署后必做的安全与稳定性设置

很多教程讲完"装好了、能登录了"就戛然而止，导致一堆人上线后裸奔。我在实际运维中就见过不少直接暴露在公网、没有管理员密码保护、甚至默认配置裸跑的n8n实例。本地部署不等于本地安全，尤其是你如果还放在公网服务器上，以下几项强烈建议逐条落实。

4.1 配置外部用户鉴权与权限隔离

如果你是团队使用，不推荐大家共享一个管理员账号。n8n社区版支持创建多个用户，但权限管理相对基础——自定义角色和细粒度权限属于企业版功能。不过即使只有"作者和管理员"两种角色，也比共用admin一个号好得多，至少每个人的操作日志可追溯。

在 n8n 主界面左下角"Settings" → "Users" 里邀请成员即可，填邮箱、设密码，然后按成员职责划分角色。管理员账号建议只用来做系统设置，日常搭建工作流用普通账号。

4.2 N8N_ENCRYPTION_KEY 的备份与轮换

前面讲过这个密钥的重要性。实际运维里，建议把密钥存到密码管理器中，或者写在 /opt/n8n/.env 文件里，并在 docker-compose.yml 中使用 env_file 引用，而不是裸写在配置文件中。这样既方便备份，也避免代码仓库泄露密钥。

yaml复制services:
  n8n:
    ...
    env_file:
      - .env

.env文件内容示例：

bash复制N8N_ENCRYPTION_KEY=你的32字节随机hex字符串
POSTGRES_PASSWORD=数据库强密码

这样docker-compose.yml里就不用出现明文密码了。注意 .env 文件权限要设为 600，只允许root用户读取。

4.3 公网IP白名单与安全组

如果你的n8n只是自己或者小团队用，并且是固定IP办公场景，强烈建议在云服务器安全组中只允许特定IP访问443和22端口。这是非常简单但极其有效的防线。我在生产环境上部署的n8n就在安全组规则里只放行了自己的办公网段IP，其他地方一律拒绝，哪怕有人扫到了端口也进不来。

如果不幸必须允许全网访问，那HTTPS证书就用靠谱一点，并且做好fail2ban之类的防护，避免被暴力破解。实际上对大多数对外提供Webhook回调的n8n来说，真正需要开放的是80/443端口，管理后台可以设置为仅内网访问，需要时再通过SSH隧道连回来。

4.4 启用Tunnel或者Webhook Test时注意回调安全

n8n在测试Webhook时有一个"Webhook Test URL"，这个URL默认不需要认证，知道地址的人都可以向它POST数据。好消息是它只能在编辑器打开时激活，并且有有效期。但为了防止别人扫描到这个临时URL后塞垃圾数据，建议在Webhook节点里开启 "Allowed Origins" 或 "Allowed IP Ranges" 限制来源。

更推荐的做法是，给Webhook节点本身加上"Header Auth"或"JWT Auth"鉴权。在节点配置的Credentials里选择 "Header Auth"，设定一个预期的Header头和值，业务方调用时就必须带上正确凭证，不然n8n直接拒绝。这招在对接第三方平台时尤其好用，能挡住一大波无效请求。

4.5 日志轮转与磁盘空间预警

前面说存储要留够，实际上n8n本地部署最容易被忽视的运维问题就是日志和数据库无限膨胀。容器内部不断产生执行日志，PostgreSQL里也累积着无数历史执行记录，时间一长磁盘就满了。

n8n提供一个环境变量可以控制执行数据的保留时间：

yaml复制- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=336

意思是启用执行数据自动清理，保留最近336小时（14天）的执行记录，超过自动删除。配置后重启容器生效。这样历史记录不会无限增长，排查问题也够用了。

如果你还想让Docker容器日志也不至于撑爆磁盘，可以在 /etc/docker/daemon.json 里加上log轮转配置：

json复制{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

然后重启Docker服务。注意这会影响到所有容器，建议提前确认没有其他容器依赖原日志配置。

5. 与本地AI模型及其他服务联动的扩展配置

近几年本地部署大模型的热度非常高，我周围很多朋友都在折腾Ollama、Dify、DeepSeek等。恰好n8n对AI节点的支持也比较完善，可以很方便地把工作流接入到本地模型上。如果你部署n8n的目的不仅仅是做传统API编排，而是想跑通一条"感知→决策→行动"的AI自动化流水线，这一章可以参考。

5.1 让n8n调用本地Ollama模型

先以Ollama为例，这是我尝试最顺的一条链路。假设你已经在另一台机器或者同一台服务器上装好了Ollama，并额外拉了一个模型，比如 qwen2.5:7b 或 deepseek-r1:7b，那接下来的步骤就是：

在n8n中新建一个工作流，添加"Basic LLM Chain"节点，然后在Model子节点中选择 Ollama 类型：

Model ID：填你在Ollama中拉取的模型名，比如 qwen2.5:7b
Base URL：填 Ollama 服务的地址。如果n8n和Ollama在同一台机器的不同容器，记得不要写 localhost，要填Ollama容器名或宿主机IP，比如 http://192.168.1.100:11434

这里有个细微但关键的设置：如果Ollama是直接在宿主机上跑的，没有容器化，那n8n容器内通过 host.docker.internal 或宿主机IP就能访问。但如果你是Linux环境，需要在docker-compose里加 extra_hosts: - "host.docker.internal:host-gateway" 才能让容器内解析到这个特殊域名。

配置好之后，整个工作流的核心逻辑就是：进来一段文本数据，n8n传给本地Ollama，模型返回回答，n8n再通过HTTP Request节点把结果推送到企业微信机器人或钉钉群。整个过程数据不出本地服务器，非常适合对数据敏感的内部知识库问答、会议纪要整理这类场景。

5.2 用OpenAI兼容接口对接任意本地推理服务

现实情况是，不止Ollama，像vLLM、LocalAI、LM Studio这类推理服务大多都提供了OpenAI兼容的API接口。n8n里的OpenAI节点其实可以填任意一个Base URL。具体做法：

节点类型选择 Open AI
Base URL 填你的本地推理服务地址，比如 http://192.168.1.100:8000/v1
API Key 随便填一长串占位符（本地服务往往不校验）

这样就能直接复用OpenAI节点的全部参数能力，比如temperature、top_p、max_tokens，并且切换不同本地模型时只需改Model ID，不用重建工作流。这个技巧非常实用，我本地测试Dify、FastGPT和n8n联动时都用的是这个方案。

5.3 本地部署DeepSeek等大模型之后的工作流参考

如果你已经把DeepSeek或者其他开源模型本地部署好了（这在工程上需要一定显存或者CPU推理的耐心），可以把n8n当做连接器，串联出一套完整的AI自动化工序。我实际搭过一条比较通用的工作流，架构是这样的：

触发器：周期或Webhook，收到一段音频转写文本或文章链接。
处理：用本地DeepSeek模型做摘要提炼、分类打标。
存储：把结果写入PostgreSQL数据库，方便后续检索。
通知：通过企业微信机器人推送给指定群。

整个链路里，n8n负责的是"编排"，本地模型负责"智能"，数据库负责"记忆"，前端IM负责"触达"。这四层各司其职，每层都可以独立替换。Dify这类平台更侧重RAG和Agent应用，n8n的强项在全流程自动化。实际配合使用时，可以让Dify解决问答机器人，把Dify的API暴露出来，n8n再在外部流程里调用Dify接口，这样各用所长。

5.4 多机部署时n8n与其他服务的网络拓扑

如果n8n、Ollama、PostgreSQL都在同一台服务器上部署，网络比较简单，直接用Docker内部网络就能互通。但如果你像我一样，生产环境有单独的数据库服务器、GPU推理服务器、Web服务器，那建议把n8n容器放在一个专门的内网网段，只开放它需要访问的端口。在安全组层面把 n8n 和 GPU 推理服务器划在一个内网安全组，外网访问只通过Nginx入口进入，最大程度减少暴露面。

6. 升级与备份：让实例长期稳定运行

最后聊一聊运维层面最容易被忽略、但对生产环境至关重要的事情：升级和备份。很多朋友的n8n跑起来之后就不再管了，结果某天想安装一个社区节点，发现版本太旧不支持；或者服务器硬盘坏了，所有工作流和凭证直接全灭。这两种情况我都见过，属于可以提前避免的灾难。

6.1 数据备份实操：一条命令备份全部状态

n8n的数据都在Docker卷里。如果你的数据库用的是PostgreSQL，那么需要备份的主要有两个东西：n8n的数据卷和PostgreSQL数据库。下面是我的备份方案：

bash复制# 1. 备份n8n配置和工作流文件（直接打包卷目录）
docker run --rm -v n8n_data:/data -v /backup/n8n:/backup alpine tar czf /backup/n8n_data_$(date +%Y%m%d).tar.gz -C /data .

# 2. 备份PostgreSQL数据库
docker exec n8n_postgres pg_dump -U n8n -d n8n > /backup/n8n_db_$(date +%Y%m%d).sql

把这两条命令写进Cron脚本，每天凌晨执行一次，同时把 /backup 目录同步到异地存储（比如对象存储或另一台机器），基本上就万无一失了。恢复流程很简单：重装Docker容器后，把n8n数据卷解压回去，然后恢复PostgreSQL的dump文件，再启动容器。10分钟内就能回到备份时的状态。

很多人可能会问：既然n8n数据卷里已经包含了工作流，为什么还要单独备份数据库？答案很简单：如果你用了PostgreSQL，工作流数据存在数据库里才是最新的。n8n数据卷里主要是配置文件、凭证、一些本地缓存数据，两者互为补充，缺一个都可能恢复不完整。

6.2 如何平滑升级n8n镜像

n8n迭代速度非常快，几乎每周都有小版本更新。升级前建议先看Release Notes，尤其是大版本升级（比如 0.x 到 1.x）可能涉及Breaking Changes。我的升级流程是：

bash复制cd /opt/n8n

# 1. 拉取最新镜像
docker compose pull

# 2. 优雅关闭旧容器
docker compose down

# 3. 重新创建并启动容器
docker compose up -d

# 4. 清理悬空镜像
docker image prune -f

升级前务必备份一次数据和数据库，万一新版本有兼容性问题，可以快速回滚。回滚的方式很简单：把 docker-compose.yml 里的镜像tag从 latest 改为上一次使用的具体版本号（比如 n8nio/n8n:1.66.0），然后重新 up -d。

另外强烈建议不要长期用 latest 标签跑生产。你可以每个月固定选一个周末，升级到当时的最新稳定版本，顺便看一下Release Notes。长期不升级的坏处不只是功能缺失，更麻烦的是n8n会逐步淘汰旧API，你之前用的一些老节点可能会在新版本中不再兼容，越拖到后面升级成本越高。

6.3 社区节点与自定义包维护

n8n的能力很大程度上靠社区节点扩展。社区节点是npm包，在n8n界面里的"Settings" → "Community Nodes"可以安装和管理。但有个问题：社区节点往往不跟主版本一起升级，可能主版本升上去了，某个社区节点还不兼容。遇到这种情况，建议锁定版本号并等待节点作者适配，不要急着升主版本。

我本人在社区节点这块的教训是：尽量少装花哨的第三方节点，优先用官方基础节点（HTTP Request、Webhook、Schedule Trigger、Postgres、Redis等）完成80%的需求，剩下的用Function节点写JS逻辑定制。这样升级时兼容性问题少很多，排查问题也容易。真正需要社区节点时，再看GitHub Stars、维护频率、是否适配当前n8n版本，谨慎引入。

6.4 监控与告警

生产环境长期运行，不能没有监控。最简单的方案是在宿主机上用crontab写个健康检查脚本：

bash复制#!/bin/bash
if ! curl -sf http://127.0.0.1:5678/healthz > /dev/null 2>&1; then
    echo "n8n health check failed at $(date)" >> /var/log/n8n_monitor.log
    # 这里可以接你的企业微信机器人通知
    curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key' \
        -H 'Content-Type: application/json' \
        -d '{"msgtype": "text", "text": {"content": "n8n服务异常，请检查"}}'
fi

每分钟跑一次，服务挂了马上告警。数据库层面的监控可以通过 pg_stat_activity 或者第三方监控工具查连接数和慢查询，但初期用健康检查+磁盘空间告警就够用了。

我在部署n8n的过程中，踩过因为Nginx代理头没设置导致Webhook地址错误的坑，也吃过不设置加密密钥导致连不上数据库的亏，还经历过磁盘被日志撑爆的折腾。但整体来说，n8n本地部署的性价比非常高，尤其是和本地大模型联动之后，一个人就能搭建一套相当强力的自动化处理中枢。如果你正打算在服务器上部署n8n，照着上面的配置和运维建议走一遍，应该能少走不少弯路。