VPS知识分享站低频、个人使用的 n8n 可以从 1 核 2G Linux 服务器测试；同时运行多个工作流、持续接收 Webhook，或把数据库也放在同一台服务器时，2 核 4G 通常是更稳妥的评估起点。如果流程包含无头浏览器、大文件、Code 节点、较高并发或本地 AI 模型，则需要按真实执行峰值选择更高配置或拆分服务。
n8n 的资源需求主要由“同时执行什么”决定，而不是只由工作流数量决定。100 个几乎不运行的流程，可能比一个并发处理大文件或启动浏览器的流程更轻。
本文中的配置用于确定测试起点，不是固定并发量或稳定性承诺。自托管意味着你需要负责系统更新、HTTPS、访问控制、密钥、备份、监控和故障恢复。n8n 官方也明确提醒，自托管需要服务器、容器、安全与运维能力。
快速选择：从什么配置开始测试
| 使用方式 | 可用于评估的起点 | 重点观察 |
|---|---|---|
| 学习、个人低频流程、少量定时任务 | 1 核 2G | 单次执行峰值、日志、更新和备份 |
| 持续 Webhook、多个 API 集成、工作流偶有重叠 | 2 核 4G 更有测试余量 | 并发、数据库连接、执行历史和外部 API |
| 小团队共用、多个活跃流程、数据库同机 | 2 核 4G 或更高，需压测 | 同时编辑、执行峰值、备份和恢复时间 |
| 大文件、二进制数据、Code 节点或无头浏览器 | 按任务峰值从更高配置评估 | 内存、临时磁盘、超时和清理策略 |
| 高频队列、关键业务、需要水平扩展 | 不能只选一台 VPS 规格 | 数据库、队列、工作进程、冗余和可观测性 |
| 本地运行 AI 模型 | 与 n8n 分开评估 | 模型、GPU、显存、内存和推理并发 |
AI 工作流并不一定需要 GPU。如果 n8n 只是调用外部 AI API，本地服务器主要承担编排、数据转换和等待网络响应；如果在同一服务器运行本地模型，需求完全不同，应按模型官方要求单独选型。
决定 n8n 配置的七个变量
1. 同时执行数量
平均每天执行多少次并不能直接反映高峰。更重要的是：
- 最繁忙的 1 分钟内会触发多少次；
- 定时任务是否在整点集中运行；
- 一个流程平均持续多久；
- 外部 API 变慢时是否积压；
- 失败重试会不会放大并发。
如果五个任务各运行一分钟且同时触发，资源压力通常高于五个任务分散在一天内运行。
2. 每次执行做什么
纯 API 转发和字段映射通常较轻；以下操作可能明显增加 CPU 或内存：
- 大数组合并、排序和复杂数据转换；
- Code 节点执行自定义逻辑；
- 下载、解压或生成大文件；
- 图片、音频和视频处理；
- 无头浏览器或页面抓取；
- 一次读取大量数据库记录；
- 子工作流递归或意外循环。
不要只看节点数量。十个简单 HTTP 节点可能比一个处理大文件的节点更轻。
3. 二进制数据和文件
附件、图片、表格、PDF 和其他二进制数据会影响内存、临时磁盘、持久化存储与备份。必须确认：
- 单个文件的典型与最大大小；
- 文件是否会同时处理；
- 执行结束后保留多久；
- 数据存放方式是否适合当前版本和许可；
- 备份是否包含这些数据；
- 清理失败时磁盘多久会用满。
n8n 的存储和扩展能力会随版本、部署方式及许可计划不同。不要未经核对就假设某个外部存储功能在当前方案中可用。
4. 数据库和执行历史
n8n 需要保存工作流、凭据相关数据和执行记录。个人测试与长期团队使用对数据库的要求不同。
部署前应查看当前 n8n 官方文档支持的数据库与配置方式，并制定执行数据保留策略。执行历史无限增长会增加磁盘、查询和备份压力。
5. 外部 API 的速度和限制
流程等待第三方 API 时，CPU 可能很空闲，但大量等待中的执行仍会占用连接、内存和执行槽。还要处理：
- API 速率限制；
- 超时；
- 分页；
- 429 或 5xx 重试；
- 重复提交和幂等；
- 第三方服务长时间不可用。
盲目缩短重试间隔可能同时耗尽服务器资源和第三方 API 配额。
6. 编辑用户和触发入口
单人偶尔进入后台，与多人同时编辑、查看执行记录和调用生产 Webhook 的负载不同。还要区分：
- 后台编辑器访问；
- 定时触发；
- 公开 Webhook；
- 内部服务调用；
- 手动重跑失败任务。
公开 Webhook 应设置应用层验证、速率限制和最小权限，不能只依赖一个难猜的 URL。
7. 恢复目标
如果工作流停机一小时影响不大，可以采用更简单的单机方案；如果它承载订单、告警或客户数据同步，就需要明确：
- 最长可接受停机时间；
- 最多能丢失多少数据；
- 外部系统是否会重发事件；
- 失败执行如何补偿；
- 恢复到新服务器要多久。
资源配置只是可靠性的一部分。单台更大的服务器仍然可能是单点故障。
n8n 资源预算工作表
在购买前填写这张表：
| 项目 | 需要记录的值 | 如何验证 |
|---|---|---|
| 活跃工作流数 | 实际会触发的流程，不是全部草稿 | 导出清单并标记频率 |
| 高峰触发数 | 最繁忙时间段的执行数 | 查看现有日志或模拟触发 |
| 最大同时执行 | 包含重试和长耗时任务 | 测试环境观察 |
| 单次执行时长 | 中位数和异常慢执行 | 执行记录与外部 API 时间 |
| 单次数据量 | JSON、文件和二进制大小 | 使用典型与极端样本 |
| 特殊节点 | Code、浏览器、文件处理、数据库 | 逐个运行并监控 |
| 执行历史保留 | 成功、失败数据各保留多久 | 对照审计和排错需求 |
| 数据库 | 类型、位置、备份与恢复方式 | 按当前官方支持核对 |
| 恢复目标 | 可接受停机和数据丢失 | 由业务负责人确认 |
如果这些问题没有答案，先搭建测试环境，不要直接为关键业务承诺容量。
一台 n8n 服务器通常包含什么
一个可维护的基础架构通常包括：
- 反向代理与 HTTPS：负责域名、TLS 和进入 n8n 的请求；
- n8n 应用：运行编辑器、触发器和工作流；
- 数据库：保存工作流和执行相关数据；
- 持久化目录或卷：保存需要跨容器重启保留的配置和数据；
- 备份与监控：用于发现故障并恢复。
初期可以把这些组件部署在一台 VPS 上，减少复杂度；当数据库、执行队列或可用性要求增长时，再评估拆分。不要因为“以后可能扩展”就一开始搭建无法维护的复杂集群。
如果需要部署步骤，可继续阅读现有的n8n 自托管部署教程。本文只负责配置与资源判断，不重复安装流程。
如果 CPU、内存、磁盘、带宽或地域尚未确定，可先用云服务器配置选择指南建立整体预算。
1 核 2G 什么时候够用
以下条件同时成立时，1 核 2G 值得作为测试起点：
- 个人或少数维护者使用；
- 工作流低频且很少重叠；
- 主要调用外部 API；
- 不处理大文件和无头浏览器；
- 执行数据有保留上限；
- 可以在监控后升级；
- 短时性能下降不会造成重大业务损失。
测试时不要只打开编辑器。至少连续运行一组真实流程，覆盖定时触发、Webhook、失败重试、备份和一次版本更新。
什么时候从 2 核 4G 或更高配置开始
出现以下情况，2 核 4G 通常能提供更合理的测试余量，但仍不能替代实测：
- 多个流程可能同时执行；
- Webhook 持续进入；
- n8n 与数据库同机；
- 流程包含中等数据转换或较多节点；
- 多人查看后台和执行历史；
- 更新、备份和业务会重叠；
- 业务不希望单核长任务阻塞其他操作。
如果包含大文件、浏览器、较高并发、复杂 Code 节点或本地模型，应测量单次与并发峰值，再评估 4 核 8G 或更高配置、拆分工作进程或托管方案。
Docker 部署 n8n 时要注意什么
n8n 官方提供 Docker 自托管方式。使用 Docker 时至少完成：
- 使用明确版本并阅读升级说明；
- 把需要保留的数据映射到持久化卷；
- 配置正确的域名、HTTPS 和回调 URL；
- 不直接公开数据库端口；
- 保护环境变量、凭据和加密相关配置；
- 设置日志和执行数据保留策略；
- 备份数据库、持久化数据、部署文件和必要密钥；
- 在测试环境验证更新与回滚。
Docker 容器默认没有资源限制。需要设置限制时，先测量正常高峰，再验证触发限制后的错误和恢复行为。可参考《Docker 部署应用需要多大 VPS 配置》中的资源预算方法。
安全配置不能等上线后再补
使用 HTTPS 和受控域名
编辑器和 Webhook 都可能传输敏感信息。应使用 HTTPS，正确配置反向代理，并避免直接把管理端口暴露到公网。
限制网络入口
只开放必要端口，数据库和内部服务限制来源。可参考云服务器安全组设置方法。
保护凭据和密钥
不要把 API 密钥、数据库密码或其他 secret 写入公开仓库、镜像或文章截图。限制配置文件权限，并把恢复所需密钥安全地备份到独立位置。
及时更新并先测试
n8n、Docker、数据库、反向代理和操作系统都需要安全更新。生产更新前备份，并在测试环境阅读版本说明、验证关键工作流和回滚。
使用官方安全审计能力
n8n 提供安全审计功能，可用于发现部分常见风险。它不是渗透测试或完整安全保证，但可以加入定期检查。具体命令和 API 用法以当前n8n 安全审计文档为准。
执行历史、日志和磁盘如何控制
磁盘问题往往比 CPU 更晚被发现。需要同时盘点：
- 成功与失败执行记录；
- 手动执行和调试数据；
- 二进制文件；
- Docker 日志；
- 数据库日志；
- 本地备份；
- 更新留下的旧镜像。
为每类数据设定用途、保留时间和删除方式。删除前确认审计、排错和恢复需求；清理后监控磁盘增长是否符合预期。
备份应独立于当前实例，并覆盖数据库、持久化数据、部署配置和恢复所需密钥。可参考云服务器备份与恢复方法，把“已生成备份”升级为“已验证能够恢复”。
至少设置以下告警：
- 磁盘空间接近预警线；
- 内存持续不足或出现 OOM；
- 容器反复重启；
- 工作流失败率异常；
- 队列或执行等待持续增长；
- Webhook 健康检查失败；
- 备份未完成或恢复测试过期。
一套上线前测试流程
1. 记录空闲基线
uptime
free -h
df -h
docker stats --no-stream2. 用真实样本逐个运行关键流程
记录执行时间、CPU、内存、网络、磁盘变化和第三方 API 响应。使用脱敏测试数据，不要把真实密钥写入记录。
3. 制造可控的并发
在测试环境同时触发计划中的高峰数量，观察是否积压、超时或出现 OOM。不要在没有限流与回滚的生产 Webhook 上直接压测。
4. 测试外部故障
模拟第三方 API 超时、限流和返回错误，确认重试有上限、不会重复创建订单或消息，也不会形成无限执行。
5. 测试更新、重启和恢复
备份后升级测试环境，验证关键工作流；再重启主机，确认服务和证书恢复。最后把备份恢复到另一套测试环境，证明恢复资料完整。
什么时候应该扩容或拆分
| 现象 | 先处理 | 进一步方案 |
|---|---|---|
| CPU 持续满载 | 找到具体流程和节点 | 优化、错峰或增加 vCPU |
| OOM、Swap 持续增长 | 检查并发、大文件和泄漏 | 限制并发、拆分任务或增加内存 |
| 磁盘快速增长 | 执行历史、日志、文件和备份 | 设置保留、外部备份或扩展存储 |
| 数据库成为瓶颈 | 慢查询、保留策略和连接 | 优化或把数据库拆分到合适服务 |
| 任务持续排队 | 外部 API、并发和执行模式 | 限流、队列化或评估扩展架构 |
| 单机故障影响关键业务 | 备份和恢复是否有效 | 评估冗余、托管方案和故障切换 |
升级前先定位瓶颈。网络慢、第三方 API 慢或流程逻辑错误，增加服务器配置不一定有效。
如果 n8n 计划长期承载关键流程，还应结合云服务器长期稳定运行检查项补充更新窗口、告警、容量趋势与故障演练。
常见问题
n8n 需要 GPU 吗
n8n 本身用于工作流编排，通常不要求 GPU。调用外部 AI API 时，模型运行在对方服务上；只有同机运行本地模型或 GPU 任务时，才需要按模型要求评估 GPU、显存和内存。
1 核 2G 能长期运行 n8n 吗
它可以作为个人低频工作流的测试起点，但“长期”取决于执行类型、并发、数据库、日志、更新和恢复要求。必须在真实高峰和后台任务下监控。
n8n 应该使用 SQLite 还是 PostgreSQL
选择取决于当前 n8n 版本的官方支持、业务规模、并发与运维能力。个人测试可以优先使用官方文档支持的简单方案；生产或团队场景应按官方数据库建议评估 PostgreSQL，并验证备份和恢复。不要在未核对版本文档时照搬旧教程。
n8n 和数据库可以放在同一台服务器吗
小规模环境可以简化部署，但两者会共享 CPU、内存、磁盘和故障范围。工作流增长后，应分别观察应用与数据库，再决定扩容还是拆分。
服务器配置越高，工作流就一定越快吗
不一定。流程可能主要等待第三方 API、被速率限制、存在低效逻辑或受数据库查询影响。只有确认本机资源是瓶颈时，升级才会直接改善。
结论：按执行峰值选型，不按工作流数量猜测
n8n 服务器选型应从同时执行、节点类型、数据量、数据库、保留策略和恢复目标出发。个人低频流程可从 1 核 2G 测试；有持续 Webhook、多个活跃流程或数据库同机时，2 核 4G 更有评估余量；重型任务和关键业务则需要更高配置或拆分架构。
如果已完成资源预算，可以查看萤光云 n8n VPS 当前配置。价格、地域、库存、镜像、安装方式和升级规则以产品页及结算页面实时信息为准。
参考资料
- n8n Docs：Hosting n8n
- n8n Docs：Security audit
- n8n Docs：External storage
- Docker Docs：Resource constraints
资料最近核对日期：2026 年 7 月 22 日。n8n 功能、部署方式和许可可能更新，上线或升级前应重新核对对应版本的官方文档。
