先决条件#

以下要求基于 n8n Cloud 的示例，仅供说明。实际需求可能因用户数、工作流数与执行量而异。更多信息请联系 n8n。

CPU 考虑事项#

n8n 不是 CPU 密集型的，所以即使是小型实例（如 AWS 和 GCP 等提供商）对于大多数用例也应该足够。通常，内存要求超过 CPU 要求，因此在规划基础设施时应将资源重点放在那里。

n8n 使用其数据库来存储凭据、过去的执行和工作流。

n8n 的核心功能是选择数据库的灵活性。所有支持的数据库都有不同的优缺点，您必须单独考虑并选择最适合您需求的数据库。默认情况下，如果给定位置不存在数据库，n8n 会创建一个 SQLite 数据库。

n8n 建议每个 n8n 实例都有一个专用数据库。这有助于防止依赖关系和潜在的性能下降。如果无法为每个 n8n 实例提供专用数据库，n8n 建议使用 Postgres 的架构功能。

对于 Postgres，数据库必须已经存在于 DB 实例上。n8n 进程的数据库用户需要对他们正在使用或创建的所有表具有完全权限。n8n 创建和维护数据库架构。

n8n 实例通常不需要大量可用内存。例如，空闲时的 n8n Cloud 实例需要约 100MB。决定内存要求的是工作流的性质和正在处理的数据。

例如，多数节点只把工作流中的数据传给下一节点，而 Code 节点会创建数据的预处理与后处理副本。处理大型二进制文件时，这可能耗尽可用资源。

详细安装选项请参阅托管文档。

n8n 建议你采用与 n8n Cloud 内部相同或相近的做法：使用 Rook 保存用户数据；若某台 n8n 服务器宕机，在另一台机器上启动新实例并挂载相同数据。

因此，除灾难性故障或用户希望在你规定的保留期内（n8n Cloud 为两周）重新激活账户外，通常不必依赖备份。

n8n 建议通过挂载另一个容器并在夜间将数据复制到该容器来创建备份。这样 RAM 占用可忽略不计，不会影响单台服务器可承载的用户数。

若实例停机或重启，此期间错过的执行（例如 Cron 或 Webhook 节点）无法补跑。若你需要接近 100% 的可用性，需在前面增加可缓存数据的代理层。