2026 Headless CMS 服务器租用配置手册：Strapi 与 Directus 的媒体与 API 缓存账 + 构建避坑全解

2026 Headless CMS 服务器租用配置手册：Strapi 与 Directus 的媒体与 API 缓存账 + 构建避坑全解

schema 归谁，决定了资源账怎么算

给 Headless CMS 配服务器，最容易在上线三个月后才爆掉的不是 CPU，而是两件小事——媒体目录一直写在本机盘上，以及 API 的读放大没有缓存层接住；而这两件事分别由「schema 归谁所有」这个看似抽象的设计决定。

把两个项目放在一句话里区分：Strapi 创建并拥有数据库 schema，Directus 包裹既有的 SQL 数据库而不修改它。前者是代码优先（code-first），内容类型定义以 JSON schema 文件的形式落在代码库里；后者是数据库优先（database-first），服务启动时内省既有表结构，再据此自动生成 REST 与 GraphQL 端点。这个差别在功能对比文章里通常只占一行，但在资源账上它是分水岭：谁拥有 schema，谁就要为「改 schema」这件事付钱，只是付钱的地方不同。

先声明本文的口径与边界。文中出现的启动时间、内存占用、构建耗时、API 响应时间、社区规模等数字，均来自第三方自托管对比站与第三方技术博客，不同来源的统计口径并不一致，因此后文凡涉及容量推算，都会写明假设条件，读者须以自己实际部署的实测结果为准，这些数字不构成任何官方基准。同时划一条界：本文不是两个 CMS 的安装教程，不是功能横评，也不是前端框架选型指南，全篇只围绕一条链展开——媒体目录该不该留在本地盘、API 的读放大由哪一层缓存接住、构建这台机器要不要单独一台。

两种所有权的后果：变更成本被推到了完全不同的地方

代码优先的代价是时间。Strapi 的内容类型是代码库里的 JSON schema 文件，天然可版本控制、可 code review、对 CI/CD 友好，但一次字段调整的最小单位就变成了「一次完整部署」：改文件、提交、跑 CI、构建镜像、重启进程。第三方口径给出的数字是每次部署都要编译 React 编写的 admin 面板，构建耗时约 3–8 分钟且 CPU 密集。也就是说，Strapi 的变更成本被折算成了构建机的 CPU 时长与流水线的等待时间。

数据库优先的代价是锁与 IO。Directus 不拥有 schema，它读的是既有表，可视化改一个字段，落到底层就是一条 DDL。小表上这条 DDL 几毫秒完成，大表上它可能意味着重写整表、重建索引、短暂的写入阻塞，以及随之而来的复制延迟。Directus 的 Admin 基于 Vue.js，加上内置 DAM、内置 Flows 事件与定时自动化、内置 WebSocket 实时订阅，功能面很宽，但「改结构」这件事的账单最终交给数据库来结。

两种形态还决定了端点生成方式的差异，进而影响缓存策略：Directus 的端点是内省出来的，表结构一变端点跟着变；Strapi 的端点由代码决定，代码与数据库之间必须靠迁移对齐。前者灵活但缺少天然的评审环节，后者严谨但每次改动都要过一遍流水线。选型阶段要问自己的不是「哪个更好用」，而是「我们团队更能承受哪种成本」：承受 CI 等待，还是承受数据库维护窗口。补充一句背景：Strapi 采用 MIT 许可（v5），Directus 采用 BSL 1.1（年收入 500 万美元以下免费），许可差异主要影响商业化场景，对服务器配置本身不起决定作用。

构建这台机器：3–8 分钟 CPU 密集意味着什么，该不该单独一台

先算一笔发布账。假设一个团队每周发布 5 次，每次 Strapi 构建按第三方口径取中位 5 分钟，一周就是 25 分钟的满 CPU 时间。如果构建机与生产运行机是同一台，这 25 分钟会切成 5 段散落在工作时段里，而它们正好落在编辑人员上传内容、前端站点拉取 API 的时间窗内。编译进程抢占 CPU 的直接后果不是「慢一点」，而是请求排队导致 P95 抬升，健康检查如果在构建高峰超时，进程管理器会判定服务不健康并重启，重启又带来 Strapi 约 15–30 秒的启动时间（第三方口径），于是形成一次人为的抖动。

所以判断标准可以写得很直白：只要在发布窗口内，构建进程的 CPU 占用会影响到健康检查阈值或 P95 目标，构建机就应该独立。独立的粒度不必一开始就上物理机，一台按小时计费的构建节点、或者 CI 平台的 runner 都可以，关键是把这三样东西和运行时彻底分开：CPU 峰值、内存峰值、磁盘写入峰值。Directus 一侧没有这条压力线，它使用官方预构建镜像（公开资料举例为 directus/directus:11.16.0），docker compose up -d 大约 2–3 分钟就能起来，Strapi 没有官方镜像，需要 npx create-strapi@latest 建项目、自己写 Dockerfile 再构建，全程约 10–15 分钟（含构建时间）。这不是优劣判断，而是说 Strapi 的部署链路上天然多出一个需要单独配资源的环节。

CI/CD 侧要留的余量有四项。第一是超时设置，构建步骤的超时应该按实测峰值上浮，而不是按常见值设成 5 分钟然后靠重试。第二是缓存，node_modules 缓存、构建产物缓存、Docker 层缓存缺一不可，缺了任何一层，那 3–8 分钟都会往上翻。第三是并发，多个分支同时构建时，构建机的核数决定了流水线是否排队，排队时间同样计入发布延迟。第四是回滚，构建产物应该保留可回滚的历史版本，因为 Strapi 的 schema 变更一旦随部署上线，回滚动作就是回滚整个应用，而不是回滚一条 DDL。另外补一条容易被忽略的：小机器上改一次 admin 配置就要重建 admin UI，第三方口径约 1–3 分钟，这个动作在生产环境应该被明令禁止，它只属于开发环境。

镜像仓库的位置也要一并规划。Strapi 自建 Dockerfile 后，镜像体积取决于依赖与 admin 构建产物，构建机每次推送与生产机每次拉取都要走一次网络，把仓库放在与生产机同机房的内网里，能把发布时间里最容易失控的一段变成可控的局域网传输。反过来，如果镜像仓库在公网另一侧，一次发布可能卡在推送阶段，而这段时间流水线占着构建机，后续分支全部排队。

生产模式下的 schema 变更：一边必须重建，一边直接改表

Strapi 的可视化内容类型构建器只在开发模式可用，生产模式下被禁用，这是设计上的刻意选择：schema 必须走代码与重新构建。落到运维上，它的含义是「紧急加一个字段」这件事不存在，最短路径也是一次完整部署，量级是分钟到十分钟。缓解办法有两种，都是在规划期做的：一是预留可空字段或 JSON 类型字段，把未来的扩展塞进已有结构里，避免动表；二是把 schema 文件纳入强制 code review，让每次变更都附带迁移脚本与回滚脚本，这样发布的可靠性才配得上它的成本。

Directus 始终可以在 admin 中可视化操作，因为改的是数据库表结构。代价要摊开讲：DDL 直接作用在生产库上，大表上的 ALTER 可能触发表重写与长时间锁；没有代码评审这道关，变更历史散落在数据库自身；多人同时改结构会出现语义冲突；更要紧的是，它内省的是一张真实存在的业务表，如果这张表还被别的系统读写，一次结构变更的影响范围就不再只是 CMS。数据库优先在这件事上是双刃剑，它换来的是零构建时间，交出去的是变更的可见性。

一个现实的折中做法是把 Directus 的生产库变更也纳入变更窗口：变更前先做一次快照或备份确认，变更脚本用迁移文件形式留存，变更后再验证端点与索引。Strapi 一侧则相反，应该把「生产环境不改代码」作为纪律写进流程，所有结构变更先在开发模式里用构建器试出来，再把产出的 schema 文件提交评审。两条路都能管住风险，但管的手段完全不同。

媒体目录账：DAM 与「本地 + 插件」在磁盘、inode、备份窗口上的差别

媒体是 Headless CMS 唯一会持续增长的不可压缩数据。Strapi 自带媒体库，本地盘为主，接对象存储通常靠插件扩展；Directus 内置 DAM，原生支持 S3 / GCS / Azure。差别不在「能不能存」，而在于默认情况下你起步时落在哪一种形态上，以及后续搬家的成本有多高。

本地盘要算三笔账，而不是一笔。第一笔是容量：假设站点三年累计 10 万张原图、平均 300 KB，约 30 GB，这个数字看起来很温和。第二笔是文件数与 inode：如果开三档缩略图或响应式尺寸，派生文件数按 3 倍算就是 30 万个小文件，加上目录层级与临时文件，inode 消耗会先于容量告警——磁盘还有几百 GB 剩余但 inode 耗尽时，表现是「写不进去」，排查起来很绕。第三笔才是备份窗口：全量备份耗时约等于数据量除以有效吞吐，30 GB 在 100 MB/s 的有效吞吐下约 5 分钟，看起来也还好；但决定小文件场景备份时长的往往不是字节数，而是遍历与元数据操作，300 万文件的目录树扫描可以轻易把 5 分钟拖成几十分钟。以上推算仅用于说明口径与量级关系，实际数值必须在自己的目录结构和备份工具下实测。

形态差异还体现在扩容上。本地媒体目录意味着「内容与这台机器绑定」：一旦你需要起第二个应用副本做负载分担，两个副本的媒体目录就是两份互不可见的数据，编辑在 A 副本上传的图，B 副本的前端请求会 404。对象存储形态把这层耦合解开，代价是三项新开销：出网流量、请求次数计费、以及到对象存储链路的延迟与稳定性。所以媒体放哪里不是偏好问题，而是一道关于副本数与备份窗口的算术题。

六个维度下的资源账对照

下面这张表只列与服务器配置直接相关的维度，功能层面的差异仅作为背景。表中数值均为第三方口径，不同来源存在差异，须以实际部署实测为准。

API 读放大与缓存层：缓存该放在哪一层

Headless CMS 的读放大有三个来源。第一是端点展开：一个页面要拿文章列表、作者、分类、推荐位，前端可能发 4 到 8 个请求，每个请求又带关系字段展开。第二是重复：同一批内容在 TTL 内被成百上千次请求，首页与列表页尤其集中。第三是权限过滤：两者都支持按角色的字段级权限，权限判断会进入查询逻辑，让同一个端点在不同身份下产生不同的结果集。

缓存可以放三个位置，成本和效果差得很远。最外层是 CDN 或反向代理前的整段响应缓存，匿名只读内容命中率最高，成本最低，代价是失效粒度粗，一条内容更新要连带刷新相关路径。中间层是应用前的 Redis，缓存的是查询结果或渲染结果，命中率高、失效可以做得比较细，代价是要自己设计 key 与失效逻辑，也是第三方口径里 Directus 明显受益的一层——有来源称开启 Redis 后重复查询的平均响应可降到 20 ms 以下。最内层是数据库前的查询缓存或物化视图，收益最直接，但失效最难，一般只在报表类只读场景做。

要不要上 Redis，可以用一句判据：匿名或弱个性化请求占比越高、内容更新频率越低，Redis 的收益越大。按第三方口径，Strapi 的最小配置不需要 Redis，整体约 700 MB–1 GB；Directus 带 PostgreSQL 与 Redis 的整体占用约 800 MB–1.2 GB。反过来，如果请求高度个性化（按 token、按用户、按地域出不同内容），命中率会掉下来，这时候钱应该花在数据库索引和连接池上，而不是缓存上。失效设计上还有一条经验性的提醒：关系型内容的一处改动往往影响多个端点，失效 key 要按内容 ID 与关系路径组织，而不是按 URL 组织，否则发布之后脏数据很难清理干净。

内存与进程模型：为什么同一个项目的内存数字能差一倍

两个项目都基于 Node.js，有来源标注均为 Node.js 22（版本要求需以各自官方 release 说明为准）。Node.js 是单进程模型，堆内存有上限，超过上限就是 OOM，进程被系统或容器杀掉，表现是「服务突然没了」。所以内存规划的第一条不是算总量，而是先确定单进程上限，再确定进程数。

进程管理器（PM2 一类）在这里起三个作用：崩溃后自动拉起、以 cluster 方式起多个 worker 用满多核、以及滚动 reload 时维持连接。它带来的新约束也要一并算进去：每个 worker 都是一份完整的堆，N 个 worker 就是 N 倍单进程内存，再加上一份管理器自身的开销。以第三方口径举例，Strapi 应用本体有来源给 400–500 MB，另一来源给 200–500 MB；Directus 有来源给 300–400 MB，另一来源给 150–400 MB。两组数字不冲突的原因是口径不同：是否含 admin 面板会话、内容类型数量、插件数量、并发编辑人数、是否处于构建期，任何一个变量变化都能让结果挪动几百 MB。

于是总内存的算式应该这样写：总内存 = 单进程上限 × worker 数 + 数据库共享内存 + 缓存占用 + 文件系统缓存余量 + 构建峰值（仅当同机构建）。举一个说明性的反例：一台 4 GB 的机器上同时跑应用、PostgreSQL 与 Redis，再开 4 个 worker，即便每个 worker 只吃 300 MB，也已经 1.2 GB，剩下的空间分给数据库缓冲与文件系统缓存后，数据库很容易退化为频繁磁盘读，查询延迟抬升，编辑后台点一下卡一下。这类问题在监控上表现为内存够用但 IO 等待高，排查时经常被误判成 CPU 不足。

swap 与容器内存限制是这一层的两个常见误配。给容器设了 1 GB 上限却在里面开了两个各 500 MB 上限的 worker，OOM 杀手会先杀掉占用最多的那个，而进程管理器又会把它拉起来，于是服务进入反复重启的循环，监控上看到的是可用性忽上忽下，日志里全是启动记录。正确顺序是先定单进程堆上限，再乘 worker 数，最后才设容器上限，并在两者之间留出系统与其他进程的空间。

还有一项容易被忽略的运维参数：启动时间。第三方口径 Directus 约 5–10 秒、Strapi 约 15–30 秒。这个数字决定三件事——健康检查的初始延迟要设多长、滚动更新一批副本需要多久、进程崩溃后恢复需要多久。把健康检查的超时设成 5 秒去检查一个启动需要 30 秒的服务，结果是服务永远起不来。

数据库侧的账：内容模型复杂度如何变成查询复杂度

内容模型在 UI 上是一张表单，在数据库里是一组表和一组 JOIN。一对多、多对多关系字段在 API 层展开时，会变成额外的关联查询或更复杂的 SQL；嵌套层级越深，单次请求的查询次数或 JOIN 数量越多。多语言场景下，i18n 又给主表加了一层本地化关联，常见的 slug、状态、发布时间、语言组合查询，需要的是复合索引而不是单列索引。

字段级权限是另一个隐性成本。按角色过滤字段意味着查询计划里多出过滤条件与投影裁剪，如果索引没有覆盖到权限判断所用的列，优化器可能放弃索引走全表扫描。两者都支持按角色的字段级权限，因此这条成本是共有的，只是落到哪一侧：Strapi 代码优先，索引随 schema 定义走代码，改索引等于改代码；Directus 数据库优先，索引可以由 DBA 直接建在既有表上，改动快但要有 DBA 规范兜底。

连接数要单独算一次。占用连接的不只是 API 请求，还有 admin 面板会话、WebSocket 订阅、迁移与导入任务、以及 CI 里的测试连接。估算方式是：副本数 × 每副本连接池上限 + admin 会话数 + 任务数，再留 30% 余量，然后去和数据库的最大连接数上限对齐。超过上限的后果不是变慢，而是新连接直接被拒绝，前端表现为随机的 500。慢查询日志应当从第一天就打开。内容模型上线初期数据量小，几乎所有查询看起来都很快，等到内容量翻几倍、编辑同时在线人数上去了，缺少复合索引的查询才会集中暴露；把慢查询阈值设得比目标响应时间略低，每周看一次最慢的十几条语句，比事后一次性优化省事得多，数据库侧的维护动作也应当安排在低峰窗口，避开 CMS 的批量导入与发布时段。

数据库选型上，SQLite 适合单机小规模起步；PostgreSQL 在 JSONB、并发写与复杂查询上更宽容；Directus 还额外支持 CockroachDB、MS-SQL、OracleDB，这意味着它可以接进既有企业库，但那一侧的变更流程与审计要求会成为新的约束条件，反而可能抵消它零构建的优势。

什么时候拆成四层，什么时候一台就够

一台就够的边界条件应该写得可执行，而不是凭感觉。同时满足下面几条时，单机形态是合理的：媒体总量可预期在几十 GB 以内且派生文件数可控；全量备份耗时在维护窗口的三分之一以内；日 API 请求量低到数据库不会成为瓶颈；发布频率每周不超过一两次，能够与访问低谷错开；只有单个应用副本；业务可以接受单机故障带来的停机。这时把预算压在内存和 NVMe 本地盘上，比拆层的收益大得多。

出现下面任意一条，就该开始拆。第一条，媒体目录让全量备份超过了维护窗口的一半，媒体必须搬出本地盘到对象存储（S3 / GCS / Azure 一类），Directus 的 DAM 原生支持，Strapi 侧通常走上传插件。第二条，需要两个以上应用副本，本地媒体会造成副本间不一致，这一条与体量无关，是硬约束。第三条，API 读放大让数据库成为瓶颈，缓存层必须独立出来，而不是继续加应用内存。第四条，发布频率高或构建频繁，构建机必须独立，否则编译峰值会周期性干扰在线请求。第五条，数据库与应用在同一台机器上出现内存或 IO 争抢，表现为缓存命中率下降与 IO 等待抬升。

拆层之后要盯的是链路，而不是单机配置。应用到数据库的往返延迟会被单次请求内的多次查询放大，所以应用与数据库应当放在同机房或同可用区内，用内网互通，跨城拆数据库会把一次页面请求的几十毫秒变成几百毫秒。应用到对象存储的链路要看出网质量与稳定性，媒体直传通常比经过应用代理更省带宽。缓存到应用之间同理，Redis 放在另一个城市，20 ms 以下的收益会被网络 RTT 吃掉。四层不是四个产品，是四条需要用延迟预算串起来的链路。

容量之外还有一条组织层面的账：社区与生态规模会影响你自建功能的多少。第三方口径给出 Strapi 的 GitHub star 约 6.6 万、插件市场 1600+，Directus 约 3 万。插件生态丰富意味着很多需求不必自己写，但每多装一个插件就多一份内存与启动开销，也多一份升级时的兼容风险，插件数量应当作为内存估算的显式输入项，而不是装到哪算到哪。

在 Headless CMS 这类以读放大与媒体为主、CPU 长期低负载的节点上，一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。我们的取舍一贯是把预算优先压在内存余量、NVMe 本地盘与内网链路上，核数够用即可，具体机型与报价需实时询价。

Strapi 与 Directus 的媒体目录，什么时候必须搬出本地盘

把触发条件列成一张可执行清单，满足任意一条就动手，不要等磁盘告警。第一，媒体目录的全量备份耗时超过维护窗口的一半，这是最主要的触发条件，因为备份窗口只会增长不会缩回。第二，inode 使用率接近告警线，或者文件数已经达到数十万量级且派生尺寸档位还有增加计划。第三，计划起第二个应用副本，本地目录与多副本天然冲突。第四，媒体被除 CMS 之外的系统读写，例如移动端直传、批处理脚本生成缩略图，本地目录会让权限与一致性失控。第五，编辑分布在不同地区且需要就近上传，本地盘意味着上传链路要绕行到这台机器。第六，机器本身没有做 RAID 或缺少可靠的快照能力，媒体丢失后无法找回。

搬家的方式也需要顺序。先把对象存储的写路径打通并保持本地目录只读一段时间，确认新上传全部落到对象存储；再把历史文件分批迁移，批次大小以能在维护窗口内完成校验为准；最后切换读路径，并保留一段回源兼容期。Strapi 侧这一步通常依赖上传插件的配置改造，Directus 侧由内置 DAM 直接配置 S3 / GCS / Azure 的存储适配器。无论哪一侧，切换期间最容易出问题的是派生文件（缩略图、响应式尺寸）的路径规则，建议在切换前把派生规则固定下来并做一次全量一致性校验。这里给的是典型部署思路，并非特指某一真实客户。

一万网络给 Headless CMS 节点的配置取舍

回到开篇那句话：Headless CMS 的服务器不是被 CPU 拖垮的，是被媒体目录和读放大拖垮的。因此配置顺序应当是内存、本地盘类型、内网链路、出网与对象存储链路，最后才是核数。内存要给到能让应用 worker、数据库共享内存与文件系统缓存同时存在的量级，参考第三方口径的整体区间（带 PostgreSQL 与 Redis 约 800 MB–1.2 GB，Strapi 最小配置约 700 MB–1 GB），起步时留出足以容纳内容类型与插件增长的余量，比事后扩容便宜。本地盘优先 NVMe，因为媒体目录的小文件读写与备份遍历吃的是 IOPS 而不是吞吐。核数只要能覆盖构建峰值与常规并发即可，真正需要更多核的场景是同机构建，而那台机器最好不是生产机。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。针对 Strapi 与 Directus 这类节点，我们更建议把应用与数据库放在同机房内网、把媒体交给对象存储、把缓存层独立出来，再按需加一台按量计费的构建机，机柜托管与带宽接入的具体方案需以官网实时信息或咨询确认为准。