了解 Cratenaut

Cratenaut 适合希望继续使用普通服务器和 Docker，同时又不想依赖零散脚本、手工命令或难以审查的操作记录的团队

它解决的问题

常见的服务器部署会逐渐出现这些问题：

• 同一个服务在不同服务器上由不同命令启动
• 配置修改后，不清楚会重启、重建还是删除哪些资源
• 数据目录由每个脚本随意决定，备份和迁移变得困难
• 密码进入配置文件、Shell 历史或进程参数
• 服务器上的实际容器已经被手工修改，本地配置却不知道
• 自动化工具或 AI 为了让命令成功，跳过了本应由人确认的风险

Cratenaut 把部署意图写成 TypeScript 配置，并在执行前生成计划。计划不只比较新旧配置，还会检查服务器实际状态，从而区分正常修改与状态漂移

它不是什么

Cratenaut 不是 Kubernetes 的替代实现，也不是托管式 PaaS。它不会引入控制平面、调度器或集群资源模型

它也不只是 Docker Compose 生成器。Compose 文件适合表达容器集合，Cratenaut 还需要表达：

• 配置选项的类型、默认值和校验
• 配置字段的变更风险
• 可复用部署单元的语义化版本
• 上次成功部署的状态
• 服务器实际状态与配置之间的漂移
• 部署前授权和部署后历史

什么时候适合使用

以下场景通常适合 Cratenaut：

• 个人服务器、自托管服务和小型团队基础设施
• 通过 SSH 管理的单台或多台 Linux 服务器
• 需要在代码评审中审查部署配置
• 希望为公司内部应用提供可复用部署规范
• Docker 已经足够，但 Shell 脚本和手工操作不再可靠

如果需求包含跨节点自动调度、自动扩缩容、服务网格或大规模集群容错，应优先评估 Kubernetes 等集群编排平台

一条明确的边界

Cratenaut 只管理配置中声明并由它创建的资源。它不会把服务器上所有 Docker 容器都视为自己的资源，也不会在没有 --prune 和相应授权时删除配置中已经移除的托管资源