一天一个开源项目（第219篇）：Openship —— 自托管部署平台，把 Vercel 的体验搬到你自己的服务器上

本文目录

你将学到什么
前置知识
项目简介
作者与团队
项目数据
解决什么问题
三种运行模式
部署流程
支持的技术栈
内置服务全家桶
操作接口
"构建在本地，部署到远端"的架构价值
OpenResty 路由层的设计
与同类工具的定位对比
为什么"删除项目后容器继续运行"很重要
官方资源
相关资源
核心要点回顾
适合谁
一句话评价

引言 --

"Deploy anything. Own everything."

这是"一天一个开源项目"系列的第 219 篇。今天的项目是 Openship。

Vercel 的体验很好——push 代码，几分钟后应用就上线了，SSL 证书、域名路由全部自动搞定。但它有一个根本问题：你的应用运行在别人的服务器上，定价完全由厂商决定，一旦有流量峰值账单就会爆炸，想走还得把所有东西迁出来。

另一个方向是自己跑 Docker，完全控制，但 SSL、CI/CD、域名路由、数据库……每一件事都得自己配，门槛不低。

Openship 站在这两者中间：给你 Vercel 级别的操作体验，但应用运行在你自己的服务器上。push 代码，自动构建成 Docker 镜像，通过 SSH 传到你的服务器，OpenResty 接管路由和 TLS，完成——你的服务器，你的数据，你的账单。

12.3k Stars，Apache 2.0，自托管完全免费。

你将学到什么

Openship 的三种运行模式（桌面应用 / 自托管服务器 / Openship Cloud）
构建在本地、通过 SSH 传输镜像的架构设计及其优势
与 Vercel/Netlify 和 Coolify/Dokploy 的定位差异
内置服务全家桶：数据库、邮件服务器、对象存储、备份
为什么"删除项目后容器继续运行"是一个重要设计决策

前置知识

了解 Docker 的基本概念
有过部署 Web 应用的经验
可选：了解 SSH、Nginx/反向代理

项目背景

项目简介

Openship 的定位是开源自托管 PaaS（平台即服务）。它把商业 PaaS 平台（Vercel、Railway、Render）的操作体验复制到你自己的基础设施上。

核心承诺是无厂商锁定：Openship 基于标准构建——Docker、OCI 镜像、S3 协议、SMTP、ACME（Let's Encrypt 的自动证书协议）。这意味着如果哪天你不想用 Openship 了，你的容器、数据库、镜像都是标准格式，可以直接迁走。

更有意思的一个设计：删除 Openship 项目后，服务器上的容器继续运行——这和大多数 PaaS 平台截然相反（在 Vercel 上删除项目，你的部署就消失了）。

作者与团队

作者：oblien（GitHub: @oblien）
官网：openship.io
协议：Apache License 2.0

项目数据

⭐ GitHub Stars：12,300+
🍴 Forks：1,100+
📄 协议：Apache 2.0（商业使用免费）
🌐 官网：openship.io

主要功能

解决什么问题

方案 <span>A</span>：用 Vercel/Netlify 等商业 PaaS
  ✅ Push 即部署，体验极佳
  ✅ SSL/域名/CI 全自动
  ❌ 应用运行在厂商服务器，无数据主权
  ❌ 流量大了账单飞涨
  ❌ 换平台要迁移所有工作负载

方案 <span>B</span>：自己搭 Docker + Nginx + CI 全套
  ✅ 完全控制，数据在自己手里
  ❌ 配 SSL 证书、反向代理、CI/CD、数据库……门槛高
  ❌ 每个服务都要手动维护

方案 C：Openship
  ✅ Push 即部署（和 Vercel 一样的体验）
  ✅ SSL/域名/数据库/邮件全内置
  ✅ 应用运行在你自己的服务器
  ✅ 基于标准，随时可迁出
  ✅ 自托管完全免费

三种运行模式

模式一：桌面应用（个人开发者）

下载 macOS / Windows / Linux 桌面客户端，本地运行控制平面。通过 SSH 管理远程服务器，无需在服务器上安装任何 agent，也不需要把控制台暴露在公网上。

适合：个人项目、side project、不想维护额外服务的场景。

模式二：自托管服务器（团队）

curl -fsSL https://get.openship.io | sh
openship   <span># 交互式向导完成初始化</span>

在服务器上运行控制平面，团队成员通过 Web 仪表板协作管理。

模式三：Openship Cloud（零运维）

托管服务，起价 $10/月，不需要自己维护控制平面，但部署目标仍可以是你自己的服务器（混合模式）。

部署流程

<span>1.</span> 连接代码仓库（GitHub/GitLab/Bitbucket）

<span>2.</span> Push 代码
   ↓
<span>3.</span> Openship 检测技术栈（Node/Python/Go/…）
   ↓
<span>4.</span> 在本地机器构建 Docker 镜像（不占用生产服务器资源）
   ↓
<span>5.</span> 通过 SSH 将镜像传输到目标服务器
   ↓
<span>6.</span> 服务器上启动容器
   ↓
<span>7.</span> OpenResty 接管路由 + Let's Encrypt 自动签发 SSL
   ↓
应用上线 ✓

关键设计：构建在本地发生，而不是在服务器上。这意味着生产服务器的资源不会被构建任务消耗，构建失败也不会影响线上服务。

支持的技术栈

语言/运行时	数据库	其他服务
Node.js	PostgreSQL	对象存储（S3 兼容）
Python	MySQL	内置邮件服务器（SMTP）
Go	MongoDB	定时备份
Rust	Redis	Let's Encrypt SSL
PHP		自定义域名
Ruby		私有网络
Java		DDoS 防护
.NET

内置服务全家桶

这是 Openship 和很多同类工具拉开差距的地方——不需要接入第三方服务：

内置邮件服务器：完整的 SMTP 服务，支持 DKIM/SPF/DMARC，无需购买 SendGrid 或 Mailgun。

内置数据库：Postgres、MySQL、MongoDB、Redis，一键创建，自动备份。

定时备份：设定时间自动备份数据库和文件，支持一键还原。

SSL 证书：Let's Encrypt 证书自动申请和续期，支持通配符域名。

操作接口

接口	适用场景
桌面应用（Mac/Windows）	个人开发者，本地控制
Web 仪表板	团队协作，浏览器访问
CLI	脚本自动化，DevOps 流水线
REST API	程序化集成
MCP 端点	AI Agent 调用（Claude Code 等）

深入剖析

"构建在本地，部署到远端"的架构价值

大多数自托管部署平台（Coolify、Dokploy、Caprover 等）的构建方式是：在目标服务器上拉取代码、在服务器上运行构建过程。

Openship 反过来：构建在运行 Openship 控制台的机器上完成，然后把产出的 Docker 镜像通过 SSH 传输到目标服务器。

Coolify / Dokploy 模式：
  代码 → 目标服务器（拉取 + 构建 + 运行）
  ↑ 构建过程消耗服务器 CPU/内存
  ↑ 构建中的服务器同时在跑线上服务，互相竞争资源

Openship 模式：
  代码 → 控制台机器（构建）→ SSH 传输镜像 → 目标服务器（只负责运行）
  ↑ 构建和运行物理隔离
  ↑ 目标服务器资源 <span>100</span><span>% 给线上服务</span>
  ↑ 构建失败不影响线上

对于资源有限的 VPS（比如 Hetzner 的 2 核 4G 小机器），这个架构差异尤其明显——同等配置下，Openship 方式的线上服务性能更稳定。

OpenResty 路由层的设计

Openship 用 OpenResty（Nginx + Lua 扩展）作为边缘代理，负责三件事：

HTTP 路由：把域名映射到对应容器
TLS 终止：Let's Encrypt 证书的申请、续期和 HTTPS 处理
零停机切换：新版本容器启动后，流量才从旧容器切到新容器

关于 TLS 和路由的顺序有个设计细节：路由和 TLS 在应用容器启动之后才接管。这意味着如果 DNS 解析或证书申请出了问题，它会在控制台显示为"需要处理"，而不是让整个部署失败并回滚——这比"一个环节失败全盘崩溃"更容易排查问题。

与同类工具的定位对比

Openship 在竞品地图里的位置：

商业 PaaS（Vercel/Railway/Render）
  ↑ 最简单，最贵，无数据主权

自托管 PaaS（Coolify / Dokploy / Caprover）
  ↑ 自己控制，免费，但内置服务少，无桌面端

Openship
  ↑ 在自托管 PaaS 中，内置服务最全（邮件服务器、备份、对象存储）
  ↑ 唯一有桌面客户端的自托管 PaaS
  ↑ 唯一支持 MCP 端点的自托管 PaaS
  ↑ 本地构建架构

原始 Docker + Nginx + CI 自建
  ↑ 最灵活，门槛最高

维度	Vercel	Coolify	Dokploy	Openship
数据主权	❌	✅	✅	✅
Push 即部署	✅	✅	✅	✅
内置邮件服务器	❌	❌	❌	✅
桌面客户端	❌	❌	❌	✅
MCP 端点	❌	❌	❌	✅
本地构建	❌	❌	❌	✅
删除后容器存活	❌	❌	❌	✅
自托管免费	—	✅	✅	✅
Stars	—	40k+	15k+	12.3k

为什么"删除项目后容器继续运行"很重要

这个设计决策体现了 Openship 的核心哲学：平台是工具，不是锁链。

在 Vercel 上，你的部署生命周期和 Vercel 平台绑定——删除项目，部署消失，无法分离。

Openship 的逻辑是：你的容器运行在你的服务器上，Openship 只是帮你管理它，而不是拥有它。删除 Openship 里的项目配置，服务器上的容器仍然在运行，可以通过标准 Docker 命令继续操作，也可以之后重新导入 Openship 管理。

这让迁移或切换平台几乎没有风险——最糟的结果是"换回手动管理"，而不是"服务消失"。

项目地址与资源

官方资源

🌟 GitHub：github.com/oblien/open…
🌐 官网：openship.io
📚 文档：openship.io/docs
🐛 Issues：GitHub Issues

总结与展望

核心要点回顾

本地构建架构：构建在控制台机器完成，生产服务器只负责运行，资源分离
内置服务全家桶：数据库、邮件服务器、对象存储、备份——不需要接入第三方服务
桌面客户端：个人开发者无需部署额外服务器即可通过 SSH 管理远端部署
删除即分离，不是删除即销毁：平台管理你的容器，但不拥有它们
MCP 端点：AI Agent 可以直接调用 Openship 执行部署操作

适合谁

厌倦了 Vercel 账单的开发者：想要同等体验但应用跑在自己 VPS 上
有家庭服务器或 VPS 的折腾党：想要一个完整的 PaaS 体验而不是纯手工运维
重视数据主权的团队：不愿意把代码产物和数据库放在第三方平台上
AI 应用开发者：需要通过 MCP 让 Agent 自动触发部署流水线

一句话评价

Openship 解决的是一个经典矛盾：你想要 Vercel 的体验，但你不想要 Vercel 的账单和厂商锁定——它把两者拆开来了。

欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页