n8n自托管工作流自动化平台：Docker部署实战指南

1. 先搞清楚n8n到底是什么，以及它解决什么问题

先说结论：n8n是一个可自托管的、基于节点（node）的工作流自动化平台，你可以把它理解成“把自己日常那些重复、机械、跨系统的操作，全部编排成一条自动运行的流水线”。

很多人第一次看到“自动化连接平台”这几个字，第一反应是“这不就是另一个Zapier或者Make吗”。确实，它们做的事情高度相似——把A应用的触发事件，接到B应用的动作上，中间再插入一些逻辑判断、数据处理、人工审批之类的环节。但n8n的核心差异有两点：

一是开源且可自部署。这意味着数据不用经过第三方云平台，你可以把整个工作流引擎跑在自己服务器、NAS甚至一台普通PC上。对于有数据合规要求、或者想把自动化能力和现有业务系统深度打通的团队来说，这是Zapier这类纯SaaS产品给不了的。

二是本地优先（local-first）的执行模型。n8n的工作流跑在你自己控制的基础设施上，触发方式可以是Webhook、定时任务，也可以是手动执行。它不是“把数据上传到别人的平台再执行”，而是“在本地环境里执行逻辑，只对需要交互的外部API做请求”。这个本质区别，决定了它在企业内部的接受度远高于很多云端自动化工具。

我从什么时候开始认真用n8n的？最早是想做一个“监控某个网页内容变化，变化后自动通知我”的小工具。用Zapier当然也能做，但免费额度几分钟就烧完了，而n8n部署在自己机器上，跑多少个workflow只要你机器扛得住就行。后来越用越深，发现它真正厉害的地方不是单个节点，而是节点与节点之间那根连线——你可以把任意两个系统用一根线连起来，线中间想怎么处理数据都行。

这篇文章我不打算写成一个n8n的完整文档，那不现实也没必要。重点放在三块：核心概念拆解、用Docker快速部署的完整过程、以及几个我实际踩坑后的经验总结。如果你正准备把n8n引入自己的工作流或者团队，这篇文章能帮你少走很多弯路。

2. 部署前的核心概念：理解n8n的构建块

在敲任何一条docker命令之前，先把n8n的几个核心概念搞清楚。这些概念不搞明白，后面配工作流的时候会非常痛苦。

2.1 节点（Node）与工作流（Workflow）

n8n里所有操作都围绕“节点”展开。一个节点代表“做一件事情”，比如发送HTTP请求、读取数据库、解析JSON、发送邮件、调用AI模型，这些都是节点。节点之间用连线（connection）串起来，形成一个从左到右的执行流，这就是工作流。

我习惯把n8n的工作流类比成一个工厂流水线：原材料从最左边的触发节点进入，经过传送带到达各个工位（节点），每个工位完成自己的加工，再把半成品传给下一个工位。如果某个工位出了次品（运行时报错），这条流水线可以选择停下来报警，也可以选择把次品扔进废品区（error workflow），不让它影响后续环节。

理解了这个比喻，你就知道为什么n8n的学习曲线比写脚本陡一些：它不是命令式的“先做A再做B”，而是数据流的“A的输出接B的输入”。一开始可能会不习惯，但一旦习惯了，你会发现这种可视化编排方式比写代码维护起来更直观。

2.2 触发节点（Trigger）是整个工作流的起点

任何工作流至少要有一个触发节点，它决定“什么时候开始跑”。n8n里常用的触发节点有这么几类：

• Schedule Trigger（定时触发）：按cron表达式周期性执行，比如每天9点跑一次数据同步。
• Webhook Trigger（网络钩子触发）：提供一个HTTP接口地址，别人请求这个地址时触发工作流。这是和外部系统集成的关键。
• Manual Trigger（手动触发）：在编辑器里点按钮才执行，适合调试。
• EventListener类触发：比如监听某个邮箱、某个消息队列、某个数据库变更，属于进阶玩法。

我第一次上手时就犯过一个错：建了工作流，配置好了一系列节点，保存后却发现它不执行。后来才明白，我压根没放触发节点，工作流不知道什么时候该跑。这就像你给流水线通了电、备好料，但没按启动按钮。

2.3 数据流动与引用语法（基本没绕过去的坎）

n8n里，每个节点执行后都会输出一份JSON数据。这份数据作为下一个节点的输入。怎么引用上一个节点的数据？靠的是它的表达式语法——{{ $json.字段名 }}。

这设计听起来很简单，但实际用起来有几个容易懵的地方：

按执行的层级来说，前面的节点返回值可能是个数组，比如从数据库查到了10条记录，那$json就是这10条记录的数组。如果你在下一个节点的输入框里直接写{{ $json.name }}，它会遍历这10条记录，分别取出每条记录的name字段，然后这个节点会执行10次。这在n8n里叫“分批执行（each item independently）”。想取数组的特定一项？要写成{{ $json[0].name }}。想让某个节点只跑一次，而不按数组拆分？需要开启节点的“Execute Once”选项。

我之前帮同事排查过一个工作流，他写了个HTTP Request节点去调内部接口，接口返回了100条数据，结果下游每个节点都执行了100次，把目标系统请求打到限流。原因就是他没意识到$json里是个数组，且默认行为是对每个条目都执行一次。

2.4 Credentials（凭据）管理的坑

n8n里连接第三方服务，比如发邮件、调API、连数据库，都需要配置Credentials——也就是账号密码、API Key、Token之类的敏感信息。

这个模块有两个值得注意的点：

第一，Credentials是加密存储在n8n自己数据库里的，不是你每次去填明文。部署时设置的N8N_ENCRYPTION_KEY就是用来加解密这些凭据的。如果你部署后忘记设置这个Key，n8n默认会生成一个临时Key，但容器一重建，Key变了，所有已保存的Credentials全部无法解密，等于全部作废，得重新配置一遍。这个坑我踩过，印象非常深。

第二，社区里经常搜“n8n credentials”怎么填，本质上是因为不同Node类型对Credential的字段要求不一样。比如SMTP邮件节点，要填服务器地址、端口、账号、密码；OpenAI节点，只需要填一个API Key。别想着背下来，用的时候看对应Node的文档就行。

2.5 两个FAQ级问题：n8n中文、n8n能通过什么邮箱发邮件

先说中文问题。n8n官方是支持界面多语言的，但中文的支持进度在不同版本里不一样。较新版本在“个人设置（Settings）→ 显示语言（Display Language）”里可以直接切换为简体中文。如果你下载的版本里找不到这个选项，大概率是版本太旧，升级到最新版即可。

再说发邮件。n8n本身不是一个邮件服务器，它是一个邮件客户端。你需要在工作流里用“Send Email”这个节点，然后配置SMTP Credentials。也就是说，你只要有任意一个邮箱的SMTP授权，就能让n8n替你发信。常见的搭配是Gmail的SMTP（需要应用专用密码）、QQ邮箱SMTP（需要授权码而不是登录密码）、或者企业邮箱的SMTP服务。我生产环境用的是阿里企业邮的SMTP，配置过程和普通邮件客户端一样，填服务器地址 smtp.企业域名.com、端口465、账号密码即可。有个细节：很多邮箱服务商要求开启“SMTP服务”开关并生成专用授权码，这个授权码才是n8n里要填的密码，不是你邮箱的登录密码。

3. Docker部署n8n：从零到可用的完整过程

n8n的部署方式有几种：npm全局安装（适合本地快速试玩）、Docker容器（最推荐的自部署方式）、官方云服务（不用操心运维）、以及Kubernetes或Docker Swarm（企业级高可用方案）。我主要讲Docker方式，这是绝大多数场景下的最优解。

3.1 为什么Docker是自部署的默认选择

原因很简单：依赖隔离、升级方便、迁移容易。n8n是Node.js应用，如果直接用npm装，你得先在机器上配好Node环境，而且版本不匹配的问题会让你怀疑人生。Docker则把n8n运行环境完整打包，你只需要一个能跑Docker的Linux机器、NAS或者云服务器，docker run一拉，立刻可用。

我自己的经历是，第一次用npm装n8n，费了半天劲解决Node版本问题；后来改用Docker，5分钟就起来了。从那以后，我对身边所有想部署n8n的人只有一个建议：有Docker就上Docker，别折腾原生安装了。

3.2 单机Docker部署的两种写法

第一种，最快速调试用的docker run命令：

bash
docker run -d
--name n8n
-p 5678:5678
-v n8n_data:/home/node/.n8n
-e N8N_ENCRYPTION_KEY=你自己生成一个随机字符串
-e GENERIC_TIMEZONE=Asia/Shanghai
-e TZ=Asia/Shanghai
docker.n8n.io/n8nio/n8n

解释一下这几项：

• -d：后台运行。
• --name n8n：容器名字。
• -p 5678:5678：n8n默认Web服务端口是5678，宿主机的5678映射到容器内的5678。
• -v n8n_data:/home/node/.n8n：named volume，把n8n的数据目录（工作流定义、凭据、设置都存这里）持久化。容器删了，数据还在。
• N8N_ENCRYPTION_KEY：用于加密Credentials的密钥，务必设置一个固定值，别让它自动生成。
• GENERIC_TIMEZONE和TZ：设置时区，这直接关系到定时触发节点按哪个时区跑。不设置的话，默认UTC，你会发现定时任务总是“晚8小时”执行。

第二种，更推荐的方式是用docker-compose，因为配置可维护，还能顺便把postgres数据库一起编排起来。我强烈建议在生产环境用PostgreSQL作为n8n的数据库，而不是默认的SQLite。原因我在后面专门说。

这是一个最小可用的docker-compose.yml：

yaml
version: "3"

services:
postgres:
image: postgres:16-alpine
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: 你的数据库密码
POSTGRES_DB: n8n
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U n8n"]
interval: 10s
timeout: 5s
retries: 5

n8n:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
environment:
- N8N_ENCRYPTION_KEY=你的加密密钥
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=你的数据库密码
- GENERIC_TIMEZONE=Asia/Shanghai
- TZ=Asia/Shanghai
volumes:
- n8n_data:/home/node/.n8n
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped

volumes:
postgres_data:
n8n_data:

注意几个细节：

1. DB_TYPE=postgresdb，让n8n使用PostgreSQL而不是默认SQLite。
2. DB_POSTGRESDB_HOST=postgres，这里的postgres是compose里服务名，Docker内部DNS会自动解析到那个容器IP。
3. depends_on的condition: service_healthy，确保等PostgreSQL健康检查通过后再启动n8n，避免n8n启动时连不上数据库而报错退出。

3.3 为什么生产环境建议把SQLite换成PostgreSQL

n8n默认使用SQLite数据库存储元数据。SQLite作为单机嵌入式数据库，优点是零配置、轻量，但它的写入锁机制和并发能力有限。当你的n8n实例工作量大了，尤其是多个工作流同时执行、频繁记录执行日志时，SQLite很容易出现“database is locked”错误。

PostgreSQL则适合多进程、多连接场景，不容易出现写锁竞争，也更方便你做定时备份、数据恢复和二次开发。如果你的n8n只是个人小玩具，一天跑几次那种，SQLite完全够用；一旦你要把n8n当团队基础设施的一部分来稳定运行，直接上PostgreSQL。

我自己的习惯是：即便是试验阶段，我也直接用docker-compose方案，把PostgreSQL带上。因为后期从SQLite迁移到PostgreSQL并不像想象中那么顺滑，需要导出导入工作流定义，还会涉及Credentials迁移，折腾一次的时间足够我重新部署三回。

3.4 访问与初始设置

启动完成后，浏览器访问http://服务器IP:5678，第一次打开会让你创建管理员账号。这一步很简单，设置邮箱和密码即可。之后登录进去就是工作流编辑器。

一个我建议尽早做的操作：创建完账号后，去右上角“Settings → Usage and plan”之类的页面看看当前实例信息，并注意一下“Worker进程”的并发设置。如果只是单机部署，默认配置就行；如果你后面要跑很多高频工作流，可以考虑调整N8N_CONCURRENCY_PRODUCTION_LIMIT之类的环境变量。

3.5 容器镜像拉取速度慢或者拉不动怎么办

用过Docker的都知道，拉镜像有时会超时或速度感人。n8n官方镜像托管在Docker Hub上，在国内访问确实存在网络问题。遇到这种情况，常规解决办法就是给Docker配置镜像加速器。在/etc/docker/daemon.json里添加registry-mirrors配置，然后重启Docker服务。

如果你用的是特殊网络环境（比如某些云服务器或NAS），还是拉不动，那就只能考虑让镜像慢慢重试，或者找一台能正常拉取镜像的机器，用docker save / docker load的方式导出导入镜像。这个方法笨了点，但确实能把镜像挪到离线环境里。

注意：n8n官方文档里给出的镜像地址是docker.n8n.io/n8nio/n8n，而Docker Hub上同样有一个n8nio/n8n。如果你在Docker Hub直接搜n8n，通常能看到。我个人建议用官方文档指定的docker.n8n.io/n8nio/n8n，其实就是官方的一个别名仓库。

4. 企业级部署的进阶选择与运维细节

如果你的目标不只是“自己在服务器上跑一个n8n”，而是要把n8n作为团队内部甚至公司级的自动化平台来运行，那么有几个点值得认真考虑。我见过很多团队一开始用单机Docker跑得挺好，后来业务量上来，发现单节点扛不住，才开始研究集群方案，白白走了一段弯路。

4.1 单机部署 vs 集群部署的决策点

n8n支持将执行工作流的Worker和**提供Web界面及API的主实例（Main Instance）**分离。也就是说，你可以把n8n拆成多个角色：一个主实例负责提供编辑器、管理数据、存储工作流，多个Worker实例负责真正执行工作流。这些角色之间通过Redis（或内置的队列模式）通信。

这个架构带来的好处是明显的：

• 主实例和Worker可以部署在不同的机器上，Worker数量可以横向扩展。
• 工作流执行和Web界面互相不阻塞，某个Worker挂了，负载会被重新分派给其他Worker。
• 可以给不同Worker分配不同的执行权限，比如一个Worker专门跑涉及数据库的工作流，另一个Worker专门跑涉及外部API的工作流。

但代价是运维复杂度显著上升。你需要额外部署Redis、配置多容器通信、管理证书，还得考虑Worker和主实例的代码版本必须保持一致，否则可能出现协议不兼容的问题。

我的建议是：如果工作流数量少于几十个、每天执行次数在千次以下，单机Docker足够。不要为了“看起来更专业”而上集群，那是给自己找麻烦。等真正出现性能瓶颈或者可靠性要求（比如关键工作流不允许长时间宕机）时，再考虑队列模式。

4.2 队列模式部署的配置要点

假设你已经决定上队列模式，docker-compose的基本拓扑会变成这样：

yaml
version: "3"

services:
postgres:
image: postgres:16-alpine
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: 你的数据库密码
POSTGRES_DB: n8n
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U n8n"]
interval: 10s
timeout: 5s
retries: 5

redis:
image: redis:7-alpine
command: redis-server --requirepass 你的redis密码
volumes:
- redis_data:/data
healthcheck:
test: ["CMD", "redis-cli", "-a", "你的redis密码", "ping"]
interval: 10s
timeout: 5s
retries: 5

n8n-main:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
environment:
- N8N_ENCRYPTION_KEY=你的加密密钥
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=你的数据库密码
- N8N_QUEUE_MODE=enabled
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- QUEUE_BULL_REDIS_PASSWORD=你的redis密码
- GENERIC_TIMEZONE=Asia/Shanghai
- TZ=Asia/Shanghai
volumes:
- n8n_data:/home/node/.n8n
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy

n8n-worker:
image: docker.n8n.io/n8nio/n8n
command: worker
environment:
- N8N_ENCRYPTION_KEY=你的加密密钥
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=你的数据库密码
- N8N_QUEUE_MODE=enabled
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- QUEUE_BULL_REDIS_PASSWORD=你的redis密码
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
deploy:
replicas: 3

volumes:
postgres_data:
redis_data:
n8n_data:

几个关键点：

• N8N_QUEUE_MODE=enabled，这一项让进程以队列模式运行。
• Worker镜像和Main实例镜像必须一致，Worker通过command: worker指定以Worker角色启动。
• QUEUE_BULL_REDIS_PASSWORD，如果你的Redis设置了密码，这里必须对上。
• deploy.replicas: 3，在compose里声明启动3个Worker副本。实际生产可以用docker compose up -d --scale n8n-worker=5动态调整。

4.3 数据备份与恢复策略

这是很多人容易忽略的一块。n8n的数据包括三部分：数据库里的工作流定义和执行记录、Credentials加密串、以及/home/node/.n8n目录下的配置文件。

我建议的备份方案是：

• 定期对PostgreSQL做pg_dump，把数据库导出为一个SQL文件，备份到异地存储。
• 把n8n_data这个Named Volume里的内容也打包备份，因为里面可能有你在本地测试时用的config文件或者一些额外的credentials相关数据（虽然主要凭据在数据库里，但稳妥起见全量备份）。

恢复时，先重建一套完全相同的容器，然后把数据库dump导入PostgreSQL，把volume内容恢复回去，最后启动n8n。整个过程如果能做到自动化和脚本化，就别手搓。我个人的做法是写个shell脚本，凌晨3点跑一次，备份完成后上传到内网NAS和云存储各一份，出现问题时10分钟就能恢复。

5. 常见问题与排查技巧实录

这一节全是干货，基本是我在真实环境里踩过的坑。每一个问题我都给出了可直接照做的解决办法，按出现频率排序。

5.1 容器起来了，但浏览器访问5678端口打不开

先别怀疑防火墙，一步步来：

• 在服务器本地执行curl http://localhost:5678，如果本地通了，说明n8n正常，问题在防火墙或安全组。如果本地都连不通，看容器日志。
• 执行docker logs n8n查看启动日志。最常见的报错是数据库连接失败。如果是单机SQLite模式，检查volume挂载有没有生效；如果是PostgreSQL模式，检查DB_POSTGRESDB_*环境变量是否和实际数据库一致。
• 云服务器的话，记得在安全组（安全组规则）里放行5678端口。这部分不是容器的问题，是网络策略的问题。

5.2 定时任务到点不执行，或者时间对不上

时间对不上，99%的可能是时区没设置。n8n容器默认UTC时间，定时节点如果不显式指定时区，就会按UTC跑。解决办法就是我在部署部分反复强调的：设置GENERIC_TIMEZONE=Asia/Shanghai和TZ=Asia/Shanghai，并且在Schedule Trigger节点里也确认时区选项选的是本地时区。

定时任务完全不执行，通常原因是工作流没启用（Active状态）。n8n的每个工作流右上角有一个开关，只有拨到Active，工作流才能被定时触发。很多人保存了工作流，但忘了激活，然后在“为什么它不跑”里纠结一整天。

5.3 Webhook触发不生效

Webhook触发不生效，先看两个地方：

• 网络可达性：配置好的Webhook URL格式通常类似http://你的服务器IP:5678/webhook/某随机ID。这个地址必须能被外部访问到。如果外部访问不了，检查防火墙、安全组、Nginx代理配置。如果用了Nginx做反向代理，记得加长超时时间（proxy_read_timeout 300s;），否则一些响应慢的请求会被Nginx截断。
• URL是否带webhook路径：n8n对Webhook是有路径区分的，不是随便一个路径都能触发。在Webhook节点设置里可以自定义路径，保存后编辑器会生成完整的回调URL，直接复制那个URL用就行。

5.4 隔壁节点提示Invalid Credentials，但我明明填对了

这个问题的频率真的非常高。明明在Credentials里填了正确的API Key，执行时却报认证失败。排查顺序如下：

1. 确认API Key本身是否有权限。比如某些服务API Key分为只读和读写，你拿只读Key去执行写操作，报错很正常。
2. 确认凭据绑定是否正确。在n8n的节点配置里，Credentials下拉框旁边有个“Create New”的链接，如果你选错了凭据（多个账号同时存在时很容易选错），自然不行。
3. 确认凭据是否因为加密Key变化失效。如果你之前部署时没设置固定N8N_ENCRYPTION_KEY，后来重建容器，Key变了，所有存量凭据就无法解密，看起来就像“填对了但不能用”。这时候只能把相关凭据删除，重新创建。这是我最想让你避开的一个坑。

5.5 数据量大时，Workflow执行到一半失败

这个问题的原因是不同的。n8n默认单步最多处理多少数据、超时时间多少，都受环境变量影响。如果你在Workflow里处理上万条数据的数组，很容易把内存打满。

排查建议：

• 减小单节点处理的数据量，通过分页或者分批方式处理。
• 调整相关环境变量，比如N8N_EXECUTIONS_DATA_MAX_SIZE、N8N_EXECUTIONS_PROCESS和内存限制等。但注意这些配置在不同n8n版本里可能有差异，改之前先去对应版本文档确认。
• 检查机器可用内存是不是真的够。docker stats命令可以看到容器实时内存占用。n8n是Node.js应用，内存管理本身就比Go这类语言要“大方”一些，一个小工作流占个几百MB内存很正常，别配个1G内存的机器硬扛。

5.6 Credentials相关的备份和迁移

这里多说一句。n8n的Credentials和普通业务数据不一样，它们的加密密钥是N8N_ENCRYPTION_KEY。如果你想从一套环境迁移到另一套环境，必须把原环境里的N8N_ENCRYPTION_KEY原样带到新环境，否则数据库里的凭据数据无法解密。

很多人迁移时只备份了数据库和volume，没有备份环境变量，结果新环境能登录、能看工作流，但所有凭据全部失效。这个教训我分享过不止一次。

5.7 常见问题速查表

6. 一些实操经验和背后的“为什么”

这一节不是操作手册，而是我把几个关键决策的底层逻辑讲透。

6.1 工作流执行引擎到底是怎么跑的

很多人把n8n当做成一个“可视化脚本编辑器”，其实不太对。n8n的每个工作流，本质上是一个有向无环图（DAG）。n8n内置的执行引擎会做两件事：

1. 拓扑排序：判断哪些节点可以并行执行、哪些节点必须等前面的节点完成。
2. 数据流传播：把每个节点的输出，按照连线的方向传递给下游节点。如果上游输出是数组，且在“Run Once for Each Item”模式下，下游节点会针对数组里的每一项分别执行一次。

理解了这一点，你就明白为什么说n8n的调试和传统编程语言debug不太一样。你没法像断点调试那样单步跟踪，只能靠每个节点的执行日志（Output Panel）来查看输入输出。所以我的习惯是：在每个复杂节点前后各加一个“No Operation”节点，用来输出和查看当前处理到哪一步的数据。虽然会多两步节点，但排障效率提升非常明显。

6.2 我为什么会把它和“本地部署大模型”搭配使用

最近热词里好几个都和本地部署AI有关，比如Ollama、LM Studio、本地部署DeepSeek之类的。n8n和本地大模型之间是天然搭档。

场景是这样的：你想在工作流里调用一个大模型来做文本分类、信息抽取、自动回复。如果用云端的OpenAI API，确实方便，但有数据隐私顾虑，且每次调用都是按token付费。而如果你在本地服务器上部署了Ollama或者LM Studio，跑一个开源模型，n8n只需要一个HTTP Request节点，POST到本地的http://localhost:11434/api/generate接口，就能把本地模型变成你自动化流水线的“智能决策节点”。

具体怎么做？在n8n的HTTP Request节点里：

• Method选POST
• URL填http://你的Ollama服务地址:11434/api/generate
• Body选择JSON，填入类似：

json复制{
  "model": "qwen2.5:7b",
  "prompt": "请判断以下用户评价是正面还是负面：{{ $json.text }}",
  "stream": false
}

注意，如果你部署n8n的宿主机上同时跑着Ollama，URL可以是http://host.docker.internal:11434（Docker Desktop环境）或实际局域网IP（Linux云服务器场景）。很多人在这里卡住，是因为在容器里访问宿主机服务和直接访问不一样。

这样组合的好处是：一次部署，长期运行，数据不出内网，每月的“API调用费”就是一点电费。所以如果你对本地部署大模型有兴趣，n8n是把它集成到业务流程里的一个极佳入口。

6.3 别忘了n8n与“大模型部署”类工具的配合要点

如果你之前折腾过Dify、ComfyUI、vLLM这类部署工具，你会发现它们的部署方式和n8n有很多交集——都要考虑Docker、端口映射、健康检查、GPU资源分配等问题。n8n和其中一些工具也能直接单向集成。比如Dify可以用来做可视化Agent应用，n8n可以把Dify提供的API封装成内部自动化流程的一环；ComfyUI可以通过API方式被n8n调用执行图像生成流程，再自动把结果保存到指定文件夹或发送到通知群。

说白了，n8n不是一个孤立系统，它更像一个“胶水层”，把各种已经部署好的服务黏合成一个更完整的自动化闭环。你之前在其他项目里积累的部署经验，在这里全部都用得上。

7. 部署完成后的第一件小事：做一条最小可用的工作流

很多人在部署完n8n后，光看界面不知道从哪里下手。我的建议是，先做一个“定时给自己发邮件”的Hello World，用最小的代价把整个链路跑通。

在n8n编辑器里新建工作流后，按下面的操作：

1. 添加一个Schedule Trigger节点，设置成每5分钟执行一次。
2. 添加一个Send Email节点，连在Schedule Trigger后面。
3. 配置Send Email的SMTP Credentials，填入你的邮箱SMTP信息。
4. 在收件人（To Email）字段填你常用的邮箱，主题写“n8n部署成功”，正文写“如果你收到这封邮件，说明n8n工作流能正常跑”。
5. 先点“Execute Workflow”按钮手动跑一次，确认能收到邮件。
6. 确认无误后，把工作流右上角开关切换到Active状态，等待5分钟，看是否能自动收到邮件。

这一步的意义是什么？它同时验证了：工作流引擎能创建与执行、SMTP凭据配置正确、定时触发机制工作的时区设置正确、邮件服务能送达。如果这条链路上任何一个环节有问题，你现在就能发现，而不是等以后做复杂业务时才暴露。

我到现在还记得我第一次用n8n收到自动邮件时的感觉，就好像你把一个机器人终于唤醒，它开始按时按点帮你做事情了。往后你可以往这条流水线上加HTTP请求、加数据库查询、加AI调用，能力的边界会迅速扩展。

8. 结尾的几句大实话

用了n8n这么长时间，我最大的感受是：自动化平台的价值不在于它有多少个现成节点，而在于它能不能让你把思路里的“如果……就……”快速变成现实。n8n把这件事的复杂度降到了一个很低的水平——不需要你写一整套后端服务，只需要拖拖拽拽，填几个参数，画几条线，一个能长期稳定运行的自动化逻辑就诞生了。

如果你现在还在犹豫要不要在自己的服务器上部署一套n8n，我给的建议是：直接上Docker方案，先跑起来再说。第一个工作流可以很简单，甚至可以没多少实际用途，但“跑起来”这个动作本身，会帮你把之后所有的问题都变成具体可解决的问题——而不是停留在想象的层面。

最后说一个我踩过好多次坑之后总结出的习惯：每次在n8n里创建或修改Credentials时，先手动执行一次这个节点，确保凭据能用，再继续连下游节点。这个习惯帮我省下的排查时间，可能比任何优化都多。希望你能少走我走过的弯路。