先决条件(Prerequisites)#
这里提供的要求是基于 n8n Cloud 的示例，仅供参考。你的具体要求可能会根据用户数量、工作流和执行次数而有所不同。如需更多信息，请联系 n8n。
🌐 The requirements provided here are an example based on n8n Cloud and are for illustrative purposes only. Your requirements may vary depending on the number of users, workflows, and executions. Contact n8n for more information.
| 组件 | 大小 | 支持的环境 |
|---|---|---|
| CPU/vCPU | 最少 10 个 CPU 周期，可根据需要扩展 | 任何公共或私有云 |
| 数据库 | 512 MB - 4 GB SSD | SQLite 或 PostgreSQL |
| 内存 | 320 MB - 2 GB |
CPU 注意事项(CPU considerations)#
n8n 对 CPU 的需求不高，因此即使是小型实例（如 AWS 和 GCP 提供的实例）对于大多数用例来说也足够。通常，内存需求高于 CPU 需求，因此在规划基础设施时应优先考虑分配内存资源。
🌐 n8n isn't CPU intensive so even small instances (of providers such as AWS and GCP) should be enough for most use cases. Usually, memory requirements supersede CPU requirements, so focus resources there when planning your infrastructure.
数据库注意事项(Database considerations)#
n8n 使用其数据库来存储 凭据、过去的执行记录和工作流。
🌐 n8n uses its database to store credentials, past executions, and workflows.
n8n 的一个核心功能是可以灵活选择数据库。所有支持的数据库都有不同的优点和缺点，你需要分别考虑并选择最适合你需求的数据库。如果在指定位置没有现有数据库，n8n 默认会创建一个 SQLite 数据库。
🌐 A core feature of n8n is the flexibility to choose a database. All the supported databases have different advantages and disadvantages, which you have to consider individually and pick the one that best suits your needs. By default n8n creates an SQLite database if no database exists at the given location.
n8n 建议每个 n8n 实例都使用专用数据库。这有助于防止依赖和潜在的性能下降。如果无法为每个 n8n 实例提供专用数据库，n8n 建议使用 Postgres 的 schema 功能。
🌐 n8n recommends that every n8n instance have a dedicated database. This helps to prevent dependencies and potential performance degradation. If it isn't possible to provide a dedicated database for every n8n instance, n8n recommends making use of Postgres's schema feature.
对于 Postgres，数据库必须已经存在于数据库实例中。用于 n8n 进程的数据库用户需要对他们正在使用或创建的所有表具有完全权限。n8n 会创建并维护数据库模式。
🌐 For Postgres, the database must already exist on the DB-instance. The database user for the n8n process needs to have full permissions on all tables that they're using or creating. n8n creates and maintains the database schema.
最佳实践(Best practices)#
- SSD 存储
- 在容器化的云环境中，确保在停止或启动容器时卷能够被持久化并挂载。否则，所有数据将丢失。
- 如果使用 Postgres，不要使用
tablePrefix配置选项。它将在不久的将来被废弃。 - 请注意新版本的变更日志，并在降级之前考虑回滚迁移。
- 至少设置基本的数据库安全性和稳定性机制，例如 IP 允许列表和备份。
内存注意事项(Memory considerations)#
n8n 实例通常不需要大量可用内存。例如，一个空闲的 n8n Cloud 实例大约需要 100MB 内存。你的工作流性质以及处理的数据量决定了内存需求。
🌐 An n8n instance doesn't typically require large amounts of available memory. For example an n8n Cloud instance at idle requires ~100MB. It's the nature of your workflows and the data being processed that determines your memory requirements.
例如，虽然大多数节点只是将数据传递给工作流中的下一个节点， 代码节点 会创建数据的预处理和后处理副本。在处理大型二进制文件时，这可能会消耗所有可用资源。
🌐 For example, while most nodes just pass data to the next node in the workflow, the Code node creates a pre-processing and post-processing copy of the data. When dealing with large binary files, this can consume all available resources.
部署建议(Deployment recommendations)#
请参阅托管文档以获取详细的设置选项。
🌐 See the hosting documentation for detailed setup options.
用户数据(User data)#
n8n 建议你遵循 n8n Cloud 内部使用的相同或类似的做法：使用 Rook 保存用户数据，并且如果 n8n 服务器发生故障，新的实例将使用相同的数据在另一台机器上启动。
🌐 n8n recommends that you follow the same or similar practices used internally for n8n Cloud: Save user data using Rook and, if an n8n server goes down, a new instance starts on another machine using the same data.
因此，除非发生灾难性故障，或用户希望在你规定的保留期限内（n8n Cloud 为两周）重新激活其账户，否则你无需使用备份。
🌐 Due to this, you don't need to use backups except in case of a catastrophic failure, or when a user wants to reactivate their account within your prescribed retention period (two weeks for n8n Cloud).
备份(Backups)#
n8n 建议通过附加另一个容器来创建每夜备份，并将所有数据复制到这个第二个容器。这样，RAM 使用量可以忽略不计，因此不会影响服务器上能够容纳的用户数量。
🌐 n8n recommends creating nightly backups by attaching another container, and copying all data to this second container. In this manner, RAM usage is negligible, and so doesn't impact the amount of users you can place on the server.
重启(Restarting)#
如果你的实例宕机或正在重启，在此期间遗漏的执行（例如 Cron 或 Webhook 节点）是无法恢复的。如果对你来说保持 100% 的正常运行时间很重要，你需要在其前面构建另一个代理来缓存数据。
🌐 If your instance is down or restarting, missed executions (for example, Cron or Webhook nodes) during this time aren't recoverable. If it's important for you to maintain 100% uptime, you need to build another proxy in front of it which caches the data.