在 4GB 内存的低配 VPS 上部署 Next.js 这种内存黑洞，Openship 的分离架构真的救了命

很多自托管 PaaS 工具（比如 Coolify 或 Dokku）在宣传时强调的是“一键部署”的便捷，但实际部署到低配 VPS 上后，你会发现一个极其尴尬的痛点：部署工具本身成了系统稳定性的最大威胁。

最典型的场景就是 Next.js 的构建过程。当你触发一次部署时，构建进程会瞬间吃掉大量内存。在 4GB 内存的机器上，如果此时生产环境的容器还在运行，极大概率会出现 OOM（Out of Memory）导致内核直接把正在运行的应用进程给顶崩了。这时候你面对的不是部署失败，而是整个生产环境的不可用。

最近实测了 Openship，它最硬核的地方在于采用了“控制平面（Control Plane）与执行面（Execution Plane）分离”的逻辑。简单来说，它把最吃资源的构建流水线和控制面板剥离了出来。默认情况下，这些东西跑在你本地的电脑上，通过 SSH 协议驱动远程服务器。

这意味着你的 VPS 变成了一个纯粹的“运行环境”，上面只跑最终的容器镜像，而没有任何构建进程在后台抢资源。这种架构对于低配 VPS 用户来说简直是救命稻草，而且因为控制面不在公网暴露，天然减少了被扫描攻击的风险。当然，这种设计也有权衡：如果你使用桌面版，电脑关机后就无法进行管理，且不支持 Webhook 自动触发部署（除非你额外花一台服务器来部署控制面）。

在功能细节上，Openship 解决了一些非常琐碎但痛苦的问题。比如它内置了 SMTP 邮件服务器，直接把 DKIM 和 SPF 这些极其恶心人的配置给集成进去了，省去了去对接 AWS SES 或 Mailgun 的繁琐过程。此外，它基于 OpenResty 和 certbot 实现了 Let's Encrypt 证书的自动续签，网络层自动化做得比较干净。

如果你想尝试，根据需求有三种运行方式。最省资源的是桌面端，直接安装后填入服务器 SSH 信息即可。如果你需要团队协作或实现自动化，则需要使用 Docker 部署控制面板，这里需要注意环境变量的配置，执行以下命令：

docker run -d \
  -e OPENSHIP_TARGET=selfhosted \
  -p 3000:3000 \
  openship/openship

另外它还提供纯 CLI 模式，适合习惯终端操作、不需要 GUI 的开发者。

在语言支持方面，它覆盖了 Node, Python, Go, Rust 等主流生态，并且对 Monorepo 架构有较好的兼容。最让我惊喜的是它支持 MCP 协议，这意味着你可以通过 AI Agent 直接驱动部署流，而不是在 UI 界面上点来点去。

总的来说，Openship 并没有试图做一个简单的 Docker Compose 可视化界面，而是从架构层面解决了“部署工具抢资源”这个核心矛盾。虽然目前还处于早期阶段，但对于那些在低配 VPS 上挣扎、厌倦了构建时掉线的开发者来说，这种分离方案非常有竞争力。