EmDash CMS 自托管 Node 部署参考
在你自己的基础设施上运行 EmDash，从 SQLite 渐进到 PostgreSQL 与对象存储。
何时选自托管
在运营、合规或架构约束下选自托管：
- 数据驻留要求严格
- 你已在内部运行共享平台服务
- 需要完全控制运行时、进程模型与网络路径
- 早期希望避免与托管云强耦合
自托管并不自动更便宜，通常更可控。
推荐的渐进模型
不要一上来就最大复杂度，分阶段推进：
- Node.js + SQLite + 本地文件存储
- PostgreSQL，以保障多实例安全与更强持久性
- S3 兼容对象存储，提升媒体可移植性
- 进程监管与可观测性加固
该顺序在保持清晰生产路径的同时，尽量减小迁移冲击。
基线架构（阶段 1）
单节点生产或早期上线：
- 应用运行时：Node 适配器（
standalone） - 数据库：持久盘上的 SQLite 文件
- 媒体：本地上传目录
- 反向代理：Nginx 或 Caddy
该配置足以支撑低至中等编辑负载、单运行时实例。
# Production build and run
npm install
npm run build
npm run start阶段 2 升级标准（迁到 PostgreSQL）
在出现以下任一情况时升级数据库：
- 并发写争用变得频繁
- 备份/恢复目标超出文件拷贝策略
- 需要更安全的多实例部署
在增加应用水平扩展前使用 PostgreSQL。在 SQLite 上扩多个应用节点会迅速带来运维风险。
存储策略：本地文件与对象存储
本地文件（从这里开始）
适合单实例环境、存储增长可预测。
S3 兼容对象存储（为扩展迁到这里）
在以下情况使用：
- 多个应用实例需要共享媒体访问
- 备份与灾备需要标准化
- CDN 与边缘缓存策略依赖稳定的对象 URL
私有基础设施上可用 MinIO 提供 S3 兼容行为。
运行时进程与代理基线
进程管理
任选其一：
- Linux 上用
systemd做原生服务控制 - 团队需要进程指标与快速重启时用
pm2
反向代理
在代理处终结 TLS 并转发到 Node 应用：
- 保留
Host与X-Forwarded-*头 - 配置健康检查路径
- 设置与上传策略一致的正文大小限制
备份与恢复策略
把备份策略视为上线阻塞项，而非上线后任务。
最低基线：
- 按计划做数据库快照
- 媒体存储备份或复制
- 在公开发布前至少做一次恢复演练
从未在测试中恢复过的备份只是传言，不是控制措施。
运维就绪清单
在生产切换前确认：
- 冷启动无需手工改配置即可工作
- 应用日志已集中且可检索
- 5xx 告警已启用
- 磁盘用量与存储增长已监控
- 密钥轮换流程已文档化
从面向 Cloudflare 的搭建迁移的说明
若项目最初按 Cloudflare 假设搭建：
- 从运行时配置中移除仅适用于云的绑定
- 将 D1/R2 适配器替换为 Node 兼容的数据库与存储适配器
- 在反向代理后重新校验认证与回调 URL
迁移风险主要在环境假设，而非页面级代码。
团队决策框架
使用这条规则：
- 若需要速度与最少运维，优先托管云路径
- 若需要控制力与现有基础设施集成，优先自托管路径
每个环境选定一个默认路径。混合部署可行，但会增加认知负担与支持成本。