Openship 拆解：一个把控制面放进桌面应用的开源部署平台，和 Vercel、Coolify 差在哪

OpenShip（仓库 oblien/openship）是这半年 star 涨得比较快的一个开源部署平台。2026 年 3 月 5 日建仓，到 9 月 28 日已经 12,902 star / 1,168 fork，Apache-2.0，最新版本 v0.8.0（9 月 27 日发布）。官网的一句话是「Deploy anything. Own everything.」——把 Vercel 那种「push 一下就上线」的体验，搬到你自己拥有的机器上，而且控制面可以只跑在你的笔记本里。

先说清楚三件事：

1. 我是顺着一条推文（x.com/openshipio）去看的，但 X 对匿名请求不返回正文，推文我没读到。下面的所有事实都来自仓库本身（main 分支，2026-09-28 的快照）、官网和 apps/web/content/docs 里的官方文档。
2. 文中的 star / 版本 / 提交数都是 2026-09-28 当天的读数，这类数字变得很快。
3. 「特色」和「代价」我分开写。它有几个确实少见的设计，也有几个现在就该知道的坑，两边都摊开。

一句话定义：它到底做了什么

给它一个仓库（或者一个本地文件夹），它替你完成五件事，全程不需要你写 Dockerfile：

1. Detect：读 package.json、框架配置、lockfile，以及仓库里可能存在的 docker-compose.yml / openship.json，判断技术栈、包管理器、构建与启动命令、监听端口。零配置能跑；openship.json 用来覆盖它猜错的地方。
2. Build：在目标服务器或本地编排机上构建成 Docker 镜像，或一个 bare release（裸进程发布）。解析出来的配置会被冻结成快照——这样重新部署和回滚跑的是和当初完全一样的东西。
3. Run：跑成容器（只发布到 loopback，不占公网端口）或受监管的宿主进程（Linux 用 systemd、macOS 用 nohup）。
4. Route + secure：OpenResty（nginx 系）edge 写入反代 vhost，签发 Let’s Encrypt 证书。这里有个细节值得记：路由和 TLS 发生在应用起来之后，所以 DNS 没配好、证书签失败，只会让界面显示 action required，不会让这次部署失败，也不会把已上线的版本打下来。
5. Push-to-deploy：接上 GitHub webhook，目标分支一推就重跑流水线；monorepo 里只重建这次 push 真正碰到的服务。

官网上它把这条链路画成六个方框：Push → Build → Ship → Wire → Route → Roll back。其中 Roll back 是「上一个版本保持热着，一键切回去，不重新构建、不丢状态」。

三种跑法，三种控制面

这是它和绝大多数同类产品最不一样的地方。它不是「一种形态」，而是三种，取决于谁在用和你的机器关掉之后它要不要还活着：

你的情况	Openship 跑在哪	你的应用跑在哪
就我一个，不想运维	桌面应用（macOS / Windows / Linux，Electron）	你 SSH 连过去的一台服务器，或 Openship Cloud
团队用 / 要 push-to-deploy / 想把应用跑在这台机器上	自托管服务器（openship up）	就在这台机器上（compose 模式），或推给别的服务器 / 云（bare 模式）
什么都不想跑	Openship Cloud	托管沙箱，零配置

桌面应用这一档是最特别的：控制面就是本地的一个进程，只在你打开应用的时候运行，没有公网入口，没有常驻服务器，也不需要登录。它的代价也直接写在文档里——应用关掉控制面就没了，所以没有团队协作、没有手机访问，也没有 push-to-deploy（webhook 需要一个稳定的公网端点，笔记本给不了）。需要这些功能，就得把 Openship 装到一台常开的 Linux 机器上。

自托管有两种安装方式，作用域不一样：

• Linux + Docker → compose 模式（默认）：从已发布的镜像拉起完整栈——Postgres、Redis、API、dashboard，以及一个跑在 :80/:443 的 OpenResty edge 容器。这一档的特点是应用和平台跑在同一台机器上，域名和 TLS 都自动化。仓库里 docker/docker-compose.yml 是给这条路径用的，可以脱离 CLI 直接 docker compose up。
• 其他所有情况 → bare 模式（macOS、Windows，或者没装 Docker 的 Linux）：单个轻量进程加一个内嵌数据库（PGlite——把 PostgreSQL 编译进进程里，省掉一个数据库服务），常开、需要登录，主要用来把应用部署推出去。

顺带说一句数据在哪：自托管的项目、部署记录、域名、环境变量、日志，全部只存在你自己的实例数据库里，不往云上同步；整个实例可以导出成一个 JSON 文件（openship system data-transfer export），换机器搬走。这是「无锁定」里比较实在的一块。

和 Vercel / Netlify 的区别

这一层其实不复杂，一句话：Vercel 是托管服务，Openship 是一个你可以自己拿走的软件。Vercel 把「跑在别人的机器上」这件事做到了极致（边缘网络、预览评论、增量静态生成、随用随付），但它没有自托管版本，你也选不了机器。Openship 反过来：工程精致度差一截，但每一层都是你的。

维度	Openship	Vercel / Netlify
谁跑你的负载	你自己（云 / VPS / 独服 / homelab），或者它的托管云	只有它自己，没有自托管版本
控制面在哪	桌面应用（只在打开时运行）/ 你的服务器 / 它的云	只在它的云，且常开
代码去哪	桌面模式下从你的文件夹/仓库直连目标机；自托管模式下构建也在你的机器	上传到它的云，在它的云里构建
产物形态	标准 Docker 容器或裸进程，随时能搬	平台内的构建产物，换平台要重来
常驻组件	桌面模式无（代价是没有 webhook 自动部署）	全托管，你不需要维护任何东西
内置邮件	自带 SMTP 服务器（iRedMail 引擎），SPF/DKIM/DMARC 一键配	不提供，自己接 SendGrid / Resend / Postmark，按封计费
域名与证书	免费子域 *.opsh.io；自己的域名默认 HTTP-01，通配符走 DNS-01	自带 CDN 与全球边缘，证书自动化做得更早更细
计费	自托管免费、无计费；云版 $10/月起	按 seat + 用量，通常随规模线性上涨

上面这张表里，「内置邮件服务器」是我觉得最容易被忽略、但实际最省事的一项。在 Vercel 上发一封「从你自己的域名发出的」事务邮件，你要买第三方邮件服务、配 SPF/DKIM/DMARC、处理退信；Openship 直接在你自己的机器上跑一个真的邮件服务器（收件、webmail 都在本地），出站再中继给 SES 或你自己的 SMTP，让信从一个信誉好的 IP 发出去。

和主流开源方案的区别

把 Coolify、Dokploy、Dokku、CapRover、Kamal 放在一起看，差别集中在四个问题上：控制面放哪、目标机动不动、产物是不是标准容器、能不能接管已经在跑的东西。

	Openship	Coolify	Dokploy	Dokku	CapRover	Kamal
Star（2026-09-28）	12.9k	62.3k	37.5k	32.2k	15.2k	14.6k
语言	TypeScript	PHP	TypeScript	Go	TypeScript	Ruby
建仓时间	2026-03	2021-01	2024-04	2013-06	2017-10	2023-01
许可	Apache-2.0（内嵌 GPL 组件，见下）	Apache-2.0	Apache-2.0 + 部分 proprietary（DSAL）	MIT	Apache-2.0	MIT
控制面	桌面应用 / 你的服务器 / 云	必须有一台常开的机器	必须有一台常开的机器	就在目标机上	就在目标机上	本地 CLI，无常驻服务
默认在哪里构建	你的机器，产物传过去	控制面机器	控制面机器	目标机	目标机	你的机器
目标机装什么	Docker + SSH；edge 由 Openship 管	Docker；Traefik	Docker；Traefik	Dokku 本体	CapRover + nginx	Docker
接管已有容器	✅ 原地收编，不重建	✗	✗	✗	✗	✗
接管已有反代	✅ 可接管 Traefik/nginx/Caddy，可回滚	✗	✗	✗	✗	✗
图形界面	桌面 + Web	Web	Web	✗	Web	✗
内置邮件服务器	✅ 自带 SMTP + 一键配 SPF/DKIM/DMARC	✗ 自己装镜像并配 DNS	✗ 自己装镜像并配 DNS	✗	✗	✗
MCP（给 AI agent 用）	✅	✗	✗	✗	✗	✗

几处需要展开说：

• 控制面必须常开 vs 不必。Coolify、Dokploy、CapRover 都要求你有一台跑了控制面板的机器，这台机器得一直在线——哪怕你的应用在别的机器上。Openship 的桌面应用把这台机器省掉了（代价前面说了：没有 webhook 自动部署）。如果你就一台 VPS，这个差别为零；如果你是「笔记本 + 一台服务器」，这个是实打实的少一个组件。
• 「目标机上不装 agent」这句话要读准确。它说的是没有一个常驻的 openship-agent 需要保活、需要心跳：构建在你这边完成，成品通过普通 SSH 流过去，在那边起一个容器。但目标机仍然需要 Docker（或走裸进程），edge（OpenResty）也由 Openship 管理；compose 模式下控制面自己的 api 容器还会挂载宿主机的 Docker socket，等于对宿主有特权。这不是「什么都不装」，是「装的东西不参与你的应用生命周期」。
• 接管已有容器，是这几家里独一份的能力。Openship 的迁移路径是：SSH 进你的服务器，只读扫描所有容器、卷、网络，读它们的 compose 配置，再把你的反代 vhost 按端口对回容器，从而恢复出「这个容器现在挂的域名和证书」；然后建一个镜像当前运行状态的 services 项目——沿用现有镜像、不带构建上下文、绝不重建；域名接管是单独一步，会先备份旧反代的配置再换 OpenResty，失败或中途重启会自动回滚；最后一步「停掉旧容器」默认不做，要你确认。官方文档明确写了「所有其他同类平台都只能部署新负载」。对已经在 Coolify/Dokploy/Dokku 上跑着一堆东西、又不想推倒重来的人，这是唯一的迁移入口。
• 许可与「开源」的边界。Openship 自己写的代码是 Apache-2.0，但仓库里内嵌了 iRedMail 引擎（GPL v3），而且它会随 API 镜像、CLI 包、桌面应用一起分发——即使你不用邮件功能。仓库里的 docs/licensing.md 把这条边界写得很清楚，也承认 Zero Email 部分的来源说明还没审完。对比之下，Dokploy 是 open-core（/proprietary 目录走 DSAL 授权，生产使用需要商业协议），所以「开源」这两个字的含金量，三家并不一样。要拿它进企业，值得先过一遍那份许可清单。

四个我认为值得抄的设计

抛开功能清单，这个项目里有几个决策是有想法的，值得单独拎出来。

1. 生产服务器不负责构建。 它把「在哪构建」和「在哪运行」拆成两个独立选择：可以在你的笔记本上构建、只把成品传过去，也可以在目标机上构建。默认按框架推荐（多数技术栈推荐在本地构建），也可以每次部署单独改。好处很直白：小 VPS 不用为了构建临时扛一波内存峰值，生产机专心服务；代价是你的机器要在部署时可用。

2. 路由和 TLS 的失败不升级成部署失败。 这个顺序是刻意的：先起新容器、确认健康，再去写 vhost、签证书。DNS 还没生效、证书还没签发，界面提示 action required 让你去处理，应用本身已经是好的、旧版本也还在跑。把「基础设施没准备好」和「代码坏了」分成两类故障，是个很务实的取舍——大多数部署系统会把这两件事搅在一起，然后你就分不清该回滚还是该去改 DNS。

3. 监控：edge 记账，控制面收集。 这是我认为最漂亮的一处。它的访问统计不是「每个请求写一条记录」，而是在 OpenResty 的 log_by_lua 阶段——响应已经写给客户端之后——对 nginx 自己的共享内存字典做十几次原子自增：这一分钟的请求数、进出的字节数、某个国家的命中数、某个状态码的数量。没有 socket、没有 HTTP 调用、没有文件写、没有数据库驱动。请求路径上 I/O 为零，每请求写库行数为零；一个定时任务每 30 分钟把已经聚合好的数字搬进 Postgres。因为写的是计数器而不是新行，第一百万个请求和第一个请求碰的是同样的 key，成本不随流量增长。仓库里给的自测数字是每请求约 1.4 µs（开启 Top Paths 后约 4.5 µs）。这个数字是项目自己测的、不是第三方验证，但设计本身——聚合而非插入、在响应之后记账——是可查的，docs/monitoring.md 把 site_logger.lua 的每一行和哪个 key 都列了出来。

4. MCP 端点没有为了「能接 AI」而开口子。 它提供一个 MCP（Model Context Protocol）端点，让 Claude、Cursor 这类客户端把 Openship 当成一组工具来驱动，甚至有配套的 prompts/list 引导流程（部署、集群、备份、迁移）。值得抄的是它的权限做法：tools/list 只会返回你的 token 真正能用的工具，但这个过滤不是鉴权；每一次 tools/call 都会在内部重新构造一个 HTTP 请求、走一遍真实的 Hono 应用，路由、校验、认证、按资源的权限检查全部照跑一遍。另外只有主动选择暴露的路由才会变成工具，凭据和 token 相关的路由永远不会成为工具，端点还按 IP 限流（300 req/min）。「让 AI 帮我部署」这件事最容易出事的就是权限，这里处理得比大多数只加了句「支持 MCP」的产品认真。

该泼的冷水

它太年轻，而且高度依赖一个人。 建仓到 12.9k star 只用了六个半月，这既是增长快，也意味着它没有经历过足够多的生产事故。71 位贡献者里，第一名的提交数是 1018，第二名是 50——这基本上是一个人的项目加上社区补丁。过去 30 天有 565 次提交，节奏很快，但也意味着接口和文档还在动：0.8.0 的 CHANGELOG 里，同一个实例导出功能的行为在「Unreleased」一节里被改了（导出默认不再带密码、而直接包含明文环境变量值），和官方文档里「不设密码就完全不带密钥」的描述对不上。这种文档与代码的漂移，在一个快速迭代的项目里会反复出现。

README 里的「即将到来」已经落后于代码。 README 的 Status 一节还写着「多节点集群、负载均衡 UI、私有网络、进阶监控」是 next；而 0.8.0 的发布说明里，基于 k3s 的集群、WireGuard 私网、跨服务器扩展 Postgres/Redis 都已经进来了（docs/self-hosted-clusters-and-private-networking.md 里那份设计文档标注「架构 2026-09-16 定稿、实现 2026-09-21 更新」，读起来像一份内部交付记录，细节多到有点吓人）。这既是好消息（功能比宣传的多），也是提醒（别拿 README 当功能清单，要去看 CHANGELOG 和源码）。

「42 项能力，一个平台」是营销口径。 官网说「全部平台，42 项能力，没有插件市场」。逐个看，其中不少是基础项（自定义域名、免费 SSL、WebSocket、日志），也有几项是刚落地、缺少实战检验的（自托管多节点集群、自动扩容）。官方文档自己也写了「docs are actively being filled out」。把它和 Coolify 那种 62k star、五年迭代、280+ 一键服务的成熟度放在一起比，要留出差距。

桌面应用的边界比听起来窄。 它不托管你的应用，也不是「本地开发服务器」——应用还是跑在你 SSH 连过去的那台机器上。而且「控制面只在应用打开时运行」这句话的另一面是：关掉笔记本，你的部署平台的 Web 界面、API、webhook 全部消失。如果你的团队里有人指望用浏览器打开控制台看日志，桌面模式不成立。

主机上的特权面不小。 compose 模式下，api 容器挂载宿主机 Docker socket，文档自己写明了「这是宿主特权，只在可信宿主机上跑」；docker/docker-compose.yml 这条路径还缺 openship up 才建立的 container→host SSH 通道，:80/:443 接管、邮件引擎、宿主机终端这些能力要靠手动补五步配置。这些都在文档里写清楚了，但「文档写清楚」和「部署的人真的会读」是两件事。

谁适合用

适合：

• 有几台自己的机器（VPS / 独服 / homelab），想要 Vercel 式的 push-to-deploy 又不想被托管。
• 已经跑在 Coolify / Dokploy / Dokku 上，想把现有容器原地接管过来、不想重新部署一遍。
• 需要「邮件、备份、CDN、监控、证书」一起解决，不想再拼五个 SaaS。
• 想让 AI agent 参与部署，同时又在意权限边界。

暂时不适合：

• 团队规模大、需要 SSO、审计合规、成熟 SLA——Coolify 或直接买 Vercel 更稳。
• 只需要部署一两个静态站——这套平台对你过重。
• 完全不想碰服务器——那本来就不是它的目标用户，用 Openship Cloud 也行，但你失去的正是它唯一的主张。

最后一句

Openship 有想法的地方，不在于它功能多，而在于它把几个别人默认接受的前提反过来了：控制面不一定非要是一台服务器；构建不一定非要在生产机上；部署失败和信息不完整是两件事；访问统计不一定非要每个请求写一次库。这些决策单独看都不惊天动地，但凑在一起，指向的是同一个立场——你部署的东西应该是标准容器，你用的工具应该是可以随时搬走的软件。

至于它能不能撑起这个立场，取决于接下来这半年：多节点集群能不能从「架构定稿」变成「别人跑在生产上」，文档能不能追上代码，以及那 1000 次提交的第二名什么时候出现。

• 仓库：github.com/oblien/openship（Apache-2.0，内嵌 GPL 组件见 docs/licensing.md）
• 官网：openship.io ｜ 文档：openship.io/docs ｜ 版本：v0.8.0（2026-09-27）