简介这份资源是面向开发者与运维人员的N8N本地部署可运行源码包适合希望借助Docker快速搭建开源自动化工作流工具、并进一步研究其源码结构的技术爱好者。N8N支持Webhook、CRON作业、数据库操作、邮件与社交媒体等多类节点可用于企业内部流程自动化、IT运维与数据处理等复杂场景。压缩包共4个文件约12KB包含sh部署脚本、inscode配置、html介绍页面与gitignore文件分别用于环境初始化、项目配置、功能说明与版本管理结构精简便于快速上手。目前已有207人学习下载。通过阅读与运行这些源码读者可掌握N8N的容器化部署思路、端口与账号配置要点并基于可运行代码进行二次开发与流程扩展为深入理解其工作原理与架构设计打下基础。1. n8n 本地部署为什么我劝你先别急着 docker runn8n 本地部署这件事我前前后后在不同环境里折腾过七八次从个人笔记本到公司内网服务器都跑过。第一次部署时我直接docker run拉起来结果数据丢了、凭据加密密钥没固定、重启后工作流全挂——那次翻车让我意识到n8n 本地部署不是「跑起来就行」而是要把数据持久化、加密密钥、执行模式、反向代理这几件事一次性想清楚。n8n 是一个开源的工作流自动化工具你可以把它理解成「自己家的 Zapier」用节点拖拽的方式把 HTTP 请求、数据库、大模型、消息推送串成自动化流程。它最大的价值在于数据不出内网配合 ollama 本地部署的大模型、本地部署 deepseek 这类推理服务能搭出一套完全私有化的 AI 工作流。这篇内容适合两类人一是想把 n8n 跑在自己服务器上做长期自动化的后端或运维二是想把 n8n 工作流和本地大模型接起来、但被 credentials 和网络配置卡住的开发者。下面我按「先跑通最小可用 → 再补生产配置 → 最后接本地模型」的顺序讲每一步都给可复制的命令和参数说明。2. 把 n8n 跑起来三种部署方式的选型与最小命令2.1 先想清楚用哪种方式跑别上来就 dockern8n 本地部署常见有三条路npm 全局安装、Docker 单容器、Docker Compose 带数据库。选型不是看哪个时髦而是看你要不要长期跑、数据量多大、要不要接外部数据库。npm 方式最轻适合临时验证和开发调试一条npx n8n就能起但它的数据默认落在用户目录的.n8n文件夹里进程一停、机器一换就容易丢而且 Node 版本升级可能把依赖搞崩。我一般只在「想快速看看某个节点长什么样」时用它。Docker 单容器是大多数人的起点镜像官方维护升级就是换个 tag。但它默认用 SQLite 存数据工作流一多、执行记录一堆积SQLite 的写入锁会成为瓶颈而且容器删了数据就没了必须挂 volume。Docker Compose 带 PostgreSQL 是我推荐的生产起步方案。Postgres 扛并发、方便备份、执行记录可以定期清理配合 volume 和固定加密密钥重启、迁移都不慌。下面直接给 Compose 方案因为它把「持久化」这件事一次性解决了。2.2 用 Docker Compose 起一套带 Postgres 的 n8n先建目录和.env文件把密钥和数据库密码抽出来别写死在 compose 里mkdir -p /opt/n8n cd /opt/n8n # 生成一个固定的加密密钥这个值一旦定了就不能改否则已存的 credentials 全部解不开 openssl rand -hex 32把输出记下来填进.env# /opt/n8n/.env N8N_ENCRYPTION_KEY把上面生成的32位hex填这里 POSTGRES_USERn8n POSTGRES_PASSWORD换成你自己的强密码 POSTGRES_DBn8n # 时区按自己所在时区改影响定时触发节点 GENERIC_TIMEZONEAsia/Shanghai然后是docker-compose.yml# /opt/n8n/docker-compose.yml services: postgres: image: postgres:16 restart: unless-stopped environment: - POSTGRES_USER${POSTGRES_USER} - POSTGRES_PASSWORD${POSTGRES_PASSWORD} - POSTGRES_DB${POSTGRES_DB} volumes: - ./pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER}] interval: 10s timeout: 5s retries: 5 n8n: image: n8nio/n8n:latest restart: unless-stopped ports: - 127.0.0.1:5678:5678 # 只绑本机对外走反向代理 environment: - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_DATABASE${POSTGRES_DB} - DB_POSTGRESDB_USER${POSTGRES_USER} - DB_POSTGRESDB_PASSWORD${POSTGRES_PASSWORD} - N8N_ENCRYPTION_KEY${N8N_ENCRYPTION_KEY} - GENERIC_TIMEZONE${GENERIC_TIMEZONE} - N8N_HOSTn8n.example.com # 换成你的域名或内网地址 - N8N_PROTOCOLhttps - WEBHOOK_URLhttps://n8n.example.com/ - EXECUTIONS_DATA_PRUNEtrue - EXECUTIONS_DATA_MAX_AGE168 # 执行记录保留7天单位小时 volumes: - ./n8n_data:/home/node/.n8n depends_on: postgres: condition: service_healthy启动docker compose up -d docker compose logs -f n8n # 看到 Editor is now accessible 就说明起来了逻辑说明postgres服务用 healthcheck 保证数据库真正就绪后 n8n 才启动避免 n8n 先起来连不上库反复重启。n8n的端口绑到127.0.0.1意味着只有本机能访问外部访问必须经过反向代理这是安全底线。WEBHOOK_URL必须填外部能访问到的地址否则 webhook 节点生成的 URL 是容器内部的外部触发不了。参数说明N8N_ENCRYPTION_KEY是整套部署里最不能丢的东西它负责加密 credentials丢了等于所有凭据作废。EXECUTIONS_DATA_MAX_AGE控制执行记录保留时长不设的话数据库会一直涨我见过跑三个月涨到几十 G 的。GENERIC_TIMEZONE影响 Cron 节点设错了定时任务会在你睡觉的时候跑。2.3 反向代理和 HTTPS 的最小配置n8n 的 webhook 和 OAuth 回调都要求 HTTPS所以反向代理不是可选项。用 Nginx 的话核心是转发时保留原始协议头server { listen 443 ssl; server_name n8n.example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location / { proxy_pass http://127.0.0.1:5678; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; 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; # 长工作流执行时间可能超过默认60s调大读超时 proxy_read_timeout 3600s; } }Upgrade和Connection两行是为了让 n8n 编辑器的 WebSocket 能通少了它们编辑器会频繁断连、节点状态不刷新。proxy_read_timeout调大是因为有些工作流跑几分钟甚至更久默认 60 秒会被 Nginx 掐断表现为「执行到一半报 504」。3. n8n credentials 与执行模式生产环境必须调的几个参数3.1 credentials 加密机制和迁移时的坑n8n 的 credentials数据库密码、API Key、OAuth Token不是明文存的而是用N8N_ENCRYPTION_KEY做对称加密后写进数据库。这带来一个很实际的约束同一套数据库必须配同一个加密密钥。我踩过的坑是本地测试时用默认密钥n8n 首次启动自动生成存在.n8n/config里迁到服务器时只搬了数据库没搬密钥结果所有 credentials 显示「Could not decrypt credentials」只能全部删掉重录。所以迁移或备份时要一起备份两样东西Postgres 数据以及N8N_ENCRYPTION_KEY。如果你用 volume 挂载.n8n目录密钥文件就在里面如果像上面那样用环境变量显式指定就把它存进密码管理器。恢复时先设好密钥再启动顺序反了会生成新密钥同样解不开旧数据。另外n8n 支持把 credentials 拆到外部密钥管理但对大多数自部署场景管好这一个环境变量就够了。别在多个环境之间共用同一个密钥测试和生产分开。3.2 执行模式own 还是 queue什么时候该上 Redisn8n 有两种执行模式。默认是own主进程内执行所有工作流在主进程里跑。好处是简单坏处是一个跑飞的工作流比如死循环、大文件处理会把整个 n8n 拖住编辑器都打不开。当你的工作流变多、或者有耗时任务时要切到queue模式主进程只负责调度实际执行交给独立的 worker 进程中间用 Redis 做队列。配置大致是这样# 在 n8n 服务里追加 environment: - EXECUTIONS_MODEqueue - QUEUE_BULL_REDIS_HOSTredis - QUEUE_BULL_REDIS_PORT6379 # 再起一个 worker 服务镜像和环境变量与 n8n 相同但命令不同 n8n-worker: image: n8nio/n8n:latest command: worker # ... 同样的 DB 和加密密钥环境变量 depends_on: - redis参数说明EXECUTIONS_MODEqueue是开关QUEUE_BULL_REDIS_HOST指向 Redis。worker 数量按 CPU 核数和任务类型调IO 密集型的可以多起几个。注意 queue 模式下 webhook 请求先进 Redis 再分发延迟会比 own 模式略高一点点但换来的是稳定性。我的经验是个人用、工作流少于 20 个、没有长任务own 模式足够一旦有对外 webhook 或者定时批量任务尽早切 queue别等出事了再改。3.3 环境变量里最该改的几个默认值除了上面提到的还有几个默认值我建议一开始就调变量默认建议值作用N8N_PAYLOAD_SIZE_MAX1664单次请求体上限(MB)传文件时容易撞EXECUTIONS_TIMEOUT-1600单个执行超时秒数防止跑飞N8N_METRICSfalsetrue开 Prometheus 指标方便监控N8N_LOG_LEVELinfoinfo排查问题时临时调 debugEXECUTIONS_TIMEOUT特别值得设我遇到过工作流里一个 HTTP 节点对端不响应连接一直挂着把 worker 占满的情况。设了超时后超时的执行会被标记失败并释放资源。4. 把本地大模型接进 n8n 工作流ollama 与 OpenAI 兼容接口4.1 为什么优先走 OpenAI 兼容接口而不是专用节点现在很多人想在 n8n 里调本地部署的大模型比如 ollama 本地部署的模型、本地部署 deepseek 这类。n8n 有专门的 Ollama 节点但我更推荐用 OpenAI 兼容接口原因是ollama、vLLM、LM Studio、以及大多数本地推理框架都提供/v1/chat/completions兼容端点用统一的 OpenAI 节点配置换后端时只改 Base URL工作流不用动。专用节点虽然方便但换框架就得重配。前提是你的本地模型服务已经跑起来。以 ollama 为例它默认监听11434OpenAI 兼容端点是http://localhost:11434/v1。注意如果 n8n 跑在 Docker 里localhost指的是容器自己要改成宿主机地址。Linux 上用host.docker.internal需要额外配置最省事的做法是让 n8n 和 ollama 在同一个 Docker 网络里用服务名互访。4.2 在 n8n 里配一个指向本地模型的 credential在 n8n 界面里新建 credential类型选OpenAI然后Base URL 填http://ollama:11434/v1假设 ollama 容器服务名是 ollamaAPI Key 随便填一个非空字符串本地服务一般不校验但 n8n 要求必填保存后点测试能通就说明网络和端点都对如果测试报连接错误先在 n8n 容器里手动验证# 进 n8n 容器 docker compose exec n8n sh # 测试能否访问 ollama 的兼容端点 wget -qO- http://ollama:11434/v1/models能返回模型列表就说明网络通问题在 credential 配置返回连接拒绝就是网络或服务名不对。这一步是排查「n8n 连不上本地模型」最快的方法比在界面里反复点测试强。4.3 一个最小可用的本地模型工作流配好 credential 后拖一个OpenAI Chat Model节点或者用HTTP Request节点直接打兼容端点。后者更灵活适合需要精细控制参数的场景{ method: POST, url: http://ollama:11434/v1/chat/completions, body: { model: qwen2.5:7b, messages: [ { role: system, content: 你是一个简洁的助手 }, { role: user, content: {{ $json.question }} } ], temperature: 0.3, stream: false } }逻辑说明model填你本地实际拉下来的模型名用ollama list能看到。messages里用 n8n 表达式{{ $json.question }}把上游节点的输出注入进来。stream设 false因为 n8n 的 HTTP 节点对 SSE 流式响应处理起来麻烦非流式更稳。temperature按任务调做抽取、分类这类要稳定的任务调到 0.1~0.3做创意生成再往上加。参数说明如果模型返回慢HTTP 节点默认超时可能不够在节点选项里把 Timeout 调到 120000 毫秒以上。本地模型首次加载进显存会慢第二次就快了别以为是配置错了。5. 避坑与排查n8n 本地部署最常见的五个翻车点5.1 重启后工作流全没了现象容器重启或重新docker compose up后之前建的工作流、credentials 全部消失回到初始设置页。原因没有挂载持久化 volume或者挂载路径写错了。n8n 容器里数据默认在/home/node/.n8n如果 compose 里没写这个 volume容器一删数据就没了。用 Postgres 时工作流存在数据库里但加密密钥还在.n8n目录两者缺一不可。解决确认 compose 里 n8n 服务有./n8n_data:/home/node/.n8npostgres 服务有./pgdata:/var/lib/postgresql/data。已经丢过数据的检查是不是用了匿名 volumedocker volume ls能看到一堆随机名的卷那种重启后可能被回收。5.2 credentials 报 Could not decrypt现象迁移服务器或改了环境变量后打开 credentials 提示无法解密。原因N8N_ENCRYPTION_KEY变了。要么是迁移时没带旧密钥要么是环境变量没生效导致 n8n 用了自动生成的新密钥。解决找回旧密钥填回去。如果旧密钥彻底丢了只能删掉所有 credentials 重新录入。预防办法就是一开始就用环境变量显式指定密钥并单独备份。5.3 webhook 外部触发不了现象工作流里 webhook 节点给的 URL从外部访问返回 404 或超时。原因WEBHOOK_URL没设或设成了容器内部地址导致生成的 URL 是http://localhost:5678/webhook/xxx外部根本访问不到。或者反向代理没转发/webhook路径。解决设WEBHOOK_URL为外部可访问的完整地址带协议和结尾斜杠。反向代理确认/路径全量转发不要只转发/rest。改完重启 n8n 生效。5.4 执行记录把数据库撑爆现象跑了一段时间后Postgres 磁盘占用飙升n8n 变慢。原因默认执行记录会一直保留每个执行的输入输出都存着工作流一多就是灾难。解决设EXECUTIONS_DATA_PRUNEtrue和EXECUTIONS_DATA_MAX_AGE按小时控制保留时长。已经涨起来的进数据库手动清理execution_data和execution_entity表或者用 n8n 的 CLI 清理命令。我一般保留 7 天够排查问题又不至于失控。5.5 本地模型调用超时或返回空现象HTTP 节点调本地模型要么超时要么返回空内容。原因三种可能——模型名写错ollama 里没有这个 tag、容器网络不通、超时设太短。本地模型首次加载慢7B 模型冷启动可能要十几秒。解决先docker compose exec n8n wget -qO- http://ollama:11434/v1/models确认能列出模型再确认model字段和列表里的一致最后把 HTTP 节点超时调到 120 秒以上。返回空内容常见于stream设了 true 但节点没处理流式响应改回 false。6. 进阶用 n8n 的 CLI 和 API 做批量运维跑通之后真正省时间的是把 n8n 当服务来管而不是每次点界面。n8n 自带 CLI可以在容器里直接操作工作流和凭据。比如导出所有工作流做备份# 导出全部工作流到当前目录 docker compose exec n8n n8n export:workflow --all --output/home/node/.n8n/backup/ # 导出 credentials注意导出文件里凭据是加密的仍需同一个密钥才能导入 docker compose exec n8n n8n export:credentials --all --output/home/node/.n8n/backup/导入时用n8n import:workflow --input文件路径。这套导出导入配合定时任务就是最朴素的灾备方案。注意导出的 credentials 文件依赖加密密钥换环境导入前先把密钥设对。另一个实用技巧是用 n8n 的 REST API 触发工作流适合被外部系统调用。先在界面里给工作流加一个 webhook 触发节点拿到 URL 后curl -X POST https://n8n.example.com/webhook/your-path \ -H Content-Type: application/json \ -d {question: 帮我总结这段文本}如果 webhook 设了认证在 header 里带上对应的 token。这样 n8n 就成了一个可以被任意系统调用的自动化后端配合本地模型整条链路数据都不出内网。最后说个我自己的习惯每次改完 compose 或环境变量先docker compose config验证语法再up -d然后logs -f盯一分钟。n8n 启动时如果密钥或数据库有问题日志里会直接报比在界面里瞎点快得多。部署这类工具后悔药就是备份和日志别省这两步。希望帮到你。本文还有配套的精品资源点击获取