openship
德可以分为两种：一种是智慧的德，另一种是行为的德，前者是从学习中得来的，后者是从实践中得来的。——亚里士多德
Openship：把部署这件事，从一串命令变成一条完整航线
项目地址：https://github.com/oblien/openship
部署应用，常常像一次看似简单却暗藏岔路的远航。
代码写好了，接下来还要构建镜像、准备运行环境、配置域名、处理 HTTPS、连接数据库、查看日志、安排备份。等到需要持续部署、预览环境、回滚版本、邮件服务或多台机器协作时，原本只想把应用发布出去的愿望，很容易被一层又一层基础设施细节包围。
Openship 是一个开源、支持自托管的部署平台，并且内置 CI/CD 能力。
它希望把部署过程收拢到同一个地方：只要将项目仓库、本地目录或预构建产物交给 Openship，它就可以识别项目、构建应用、启动服务、配置路由、处理 TLS 终止，并提供桌面应用、Web 控制台与命令行三种操作入口。
从源代码到可访问的应用，Openship 试图让这段距离变得更完整，也更连贯。
一个平台，承接从构建到上线的全过程
Openship 的工作方式可以概括为一条端到端的部署流水线。
首先，它会识别项目。
它会读取 package.json、框架配置、锁文件，以及 docker-compose.yml 或 openship.json 等文件，从中判断技术栈、包管理器、构建命令、启动命令和端口信息。
接着，它会构建项目。
构建可以发生在目标服务器上，也可以发生在编排器本地。应用会被构建为 Docker 镜像或裸机发布版本，而解析得到的配置会被冻结到快照中。这样一来，重新部署与回滚时，都会沿用同一份配置重新执行。
随后，应用开始运行。
它可以作为容器运行，并只发布在回环地址上，而不是直接暴露公共端口。它也可以作为由系统监管的宿主机进程运行。
应用准备完成后，路由与安全配置接手工作。
OpenResty 边缘层会为域名写入反向代理虚拟主机配置，并通过 Let’s Encrypt 签发证书。由于路由与 TLS 配置发生在应用启动之后，即使 DNS 配置尚未就绪，也不会影响应用先完成部署。
最后，推送部署能够让这条流程自动再次启动。
当 GitHub 仓库被跟踪的分支发生推送时，Webhook 会重新运行部署流水线。对于单体仓库中的多个服务，Openship 会只重建本次推送实际触及的服务。
识别、构建、运行、路由、安全与持续部署，被放在同一条航线里，不再需要由多套工具分别拼接。
三种运行方式，面向不同的部署节奏
Openship 首先让使用者决定一件事：控制平面如何运行。
对于个人开发者、单机使用者，以及不希望维护长期运行服务的人，桌面应用是一条直接的路径。
对于团队、持续部署场景，或希望在自己的机器上托管应用的人，可以将 Openship 运行在自托管服务器上。
对于不想运行任何基础设施的人，则可以使用 Openship Cloud，在托管沙箱中部署应用。
这三种方式服务于不同的工作习惯，但它们都围绕同一个后端能力展开。
桌面应用：让控制平面留在自己的机器上
桌面应用适合个人使用。
控制平面只会在桌面应用打开期间运行在本地机器上，不需要长期运行的服务器，也不会暴露公共访问面。应用本身并不会托管在笔记本电脑上，而是由桌面应用通过 SSH 驱动连接的服务器，或者部署到 Openship Cloud。
这种方式不需要登录，不需要打开终端，也不需要先准备公网控制面。
打开桌面应用后，可以连接一台服务器，或者连接 Openship Cloud，然后将应用部署到对应目标。
它把本地电脑变成一张控制台，而不是一台需要对外提供服务的主机。
自托管服务器：为团队与持续部署准备的控制平面
当部署需要持续运行、需要推送即部署，或者希望在自己的服务器上托管应用时，自托管模式提供了一条更稳定的路径。
安装 CLI 后，可以直接运行交互式向导：
1 | curl -fsSL https://get.openship.io | sh |
向导会创建第一个管理员、配置域名，并将 Openship 安装为开机服务。
如果运行环境是 CI 或无交互服务器，也可以跳过向导，直接使用 openship up：
1 | openship up |
这会安装并将 Openship 作为后台服务启动，同时支持开机启动与自动重启。
如果希望将控制台服务在自己的域名下，还可以指定公开地址：
1 | openship up --public-url https://openship.example.com |
在 Linux 且已安装 Docker 的环境中，openship up 默认使用 Compose 模式。它会启动完整服务栈，包括 Postgres、Redis、API、控制台以及运行在 80 和 443 端口上的容器化 OpenResty 边缘层。
在 macOS、Windows，或未安装 Docker 的 Linux 环境中，Openship 会使用裸机模式。此时控制平面以单个轻量级进程运行，并使用嵌入式数据库，再将应用部署到服务器或云端。
自托管实例始终需要登录，登录账号就是初始化过程中创建的管理员。
常用的实例管理命令包括：
1 | openship open |
openship open 用于打开控制台，openship stop 用于停止服务，openship update 用于升级。
从一个目录开始部署项目
部署项目时，流程可以从项目目录中开始。
1 | cd your-project |
openship init 用于将当前目录关联到项目。
openship deploy 则开始执行部署。
这组命令背后并不只是一次上传，而是让 Openship 读取项目结构、判断运行方式、生成构建配置、完成启动与路由配置的完整过程。
对于习惯从代码目录开始工作的开发者来说，部署不再需要先在多个平台之间来回切换。项目就在当前目录里，部署入口也同样在当前目录里。
同一个后端，三种操作界面
Openship 提供三种操作方式，并且它们驱动的是同一个后端。
桌面应用
桌面应用提供完整图形界面、实时日志和一键操作体验，适合个人使用。
它把服务器连接、应用部署和日志查看等过程放到图形界面中，让控制平面在本地桌面上运行。
Web 控制台
Web 控制台提供浏览器中的操作界面，更适合团队协作场景。
当自托管控制平面长期运行后，控制台可以成为团队查看部署状态、管理项目和使用平台能力的统一入口。
命令行
CLI 面向脚本化与 CI 场景。
它既可以用于安装和管理自托管实例，也可以用于初始化项目、执行部署，以及生成 Shell 补全脚本。
例如，可以为 Bash、Zsh 或 Fish 生成静态补全文件：
1 | openship completion bash > /etc/bash_completion.d/openship |
也可以在 Zsh 配置中使用动态加载方式：
1 | echo 'source <(openship completion zsh)' >> ~/.zshrc |
图形界面适合观察与操作，命令行适合自动化与集成，而 Web 控制台则让团队可以在浏览器中使用同一套能力。
不同界面像不同的舵轮，却共同指向同一艘船。
内置 CI/CD，让代码推送继续向前走
Openship 将 CI/CD 作为平台内置能力的一部分。
它支持推送即部署、预览环境、预发布与生产流程，以及回滚。
对于持续变化的项目来说，部署不应该总是一件需要临时准备的工作。代码更新后，部署流程可以继续沿着已经确定的配置自动运行。
当一个仓库分支被跟踪后，每一次推送都能触发流水线重新执行。
对于单体仓库，Openship 会识别本次改动触及的服务，并只重建这些服务。这样一来，仓库中的多个服务不必因为一次局部变更而全部重新构建。
而配置快照则让重新部署与回滚拥有一致的执行基础。
版本变化会继续向前推进，但已经验证过的部署路径也不会轻易丢失。
不限定技术栈，也不回避已有 Docker Compose
应用部署平台的难点之一，在于项目的技术形态各不相同。
有的项目使用 Node。
有的项目使用 Python、Go、Rust、PHP、Ruby、Java 或 .NET。
有的项目已经容器化。
有的项目是单体仓库。
有的项目本身就带着 Docker Compose 配置。
Openship 支持这些不同技术栈，并支持将现有 Docker Compose 文件按原样部署。
它不会只面向某一个框架或某一种开发语言，而是从项目中的配置文件、锁文件与构建信息中识别适合的部署方案。
这种设计让平台不必要求每个项目先变成相同的样子，才能开始部署。
项目可以保留自己的技术选择，而 Openship 负责在部署层面为它找到可运行的路径。
后端能力不必散落在不同平台上
部署一个完整应用，往往不仅仅意味着运行一个 Web 服务。
数据库、缓存、后台任务、WebSocket、存储、域名、证书、邮件、备份与监控，都会逐渐进入产品运行的范围。
Openship 将这些能力放在同一个管理面中。
它支持 Postgres、MySQL、MongoDB、Redis、工作进程、WebSocket 与存储。
它支持域名与 SSL 管理，包括自动签发 Let’s Encrypt 证书、通配符域名、无限域名与自动续期。
它提供 CDN 能力，包括边缘缓存、HTTP/3、Brotli 压缩与即时清理缓存。
它也提供内置 SMTP 邮件服务器，支持 DKIM、SPF 与 DMARC。
这意味着，邮件能力不一定需要依赖 Mailgun 或 SES。
部署后的数据同样需要被照料。Openship 支持定时备份数据库与卷，支持一键恢复，也支持随时导出。
这些能力不是孤立的按钮，而是应用上线之后仍会不断用到的运行要素。
监控，让应用的状态保持可见
部署完成并不意味着工作结束。
构建日志是否正常，容器是否稳定，访问来自哪里，响应状态码如何分布，都会影响后续判断。
Openship 提供实时监控能力，包括实时构建日志、容器指标、访客地理分布，以及不同响应状态码的占比。
README 中描述，这部分监控处理每个请求约需 1.4 µs，并且每个请求不会产生数据库写入。
对运行中的服务而言，监控不是另一套遥远系统里的报表，而是让部署后的应用依然保持可观察的一层视野。
从单台机器，到多个服务器
Openship 可以部署到不同类型的运行环境中。
它支持 Openship Cloud。
它支持各类 VPS。
它支持独立服务器、机房托管服务器与家庭实验室环境。
它也支持将工作负载分布到多台服务器。
无论最终应用运行在哪里，平台提供的是同一套操作界面。
部署目标可以变化，操作体验不必随之变得零散。
这让服务器不再只是不同供应商、不同地址和不同控制面板组成的集合，而是可以被统一纳入同一个部署流程中。
标准 Docker 容器，让迁移保持可能
Openship 使用标准 Docker 容器作为可移植性的基础之一。
应用可以在不同提供商之间迁移，而不必被固定在某一个特定部署环境中。
这让部署平台并不只是一个目的地，也是一种让应用保持流动性的方式。
当运行环境需要改变时，项目并不一定要重写部署逻辑。标准容器提供了更明确的承载形式，帮助应用在不同位置之间继续航行。
MCP 与 REST API，让自动化也有接口可循
除了桌面应用、Web 控制台与 CLI，Openship 还提供 MCP 端点与 REST API，用于自动化场景。
对于 AI 智能体，只有明确选择开放的路由才会作为 MCP 工具暴露。每一次调用都会重新检查权限，凭据与令牌也会保持隐藏。
这让自动化能力能够进入部署管理流程，同时仍然保留权限边界。
应用部署、运行状态与管理动作不再只能依赖人工点击，也可以通过面向自动化的接口进一步连接到其他工作流中。
开源、自托管与 Apache 2.0 许可证
Openship 是开源软件，采用 Apache License 2.0 许可证。
根据该许可证条件，用户可以使用、运行、修改、自托管与分发 Openship，也可以将它用于商业产品与闭源产品。
自托管本身免费，不涉及计费。
Openship 将核心定位放在生产可用的能力上，并保持持续开发。后续计划包括多节点集群、负载均衡界面、私有网络、高级监控与可视化 CI/CD 流水线。
结语
部署从来不只是把程序放到服务器上。
它包含识别项目、构建产物、启动服务、配置路由、签发证书、管理域名、追踪日志、安排备份、处理持续发布，也包含对未来扩展与迁移的准备。
Openship 试图将这些原本分散的环节汇聚成一个自托管部署平台。
它可以从 GitHub 仓库、本地目录或预构建产物开始。
它可以自动识别项目栈与构建方式。
它可以处理构建、运行、路由与 TLS。
它可以通过桌面应用、Web 控制台和 CLI 被不同角色使用。
它可以把数据库、缓存、邮件、CDN、备份、监控与扩缩容放在同一个管理面中。
从一份代码到一个在线服务，真正需要跨越的并不只是网络距离。Openship 想做的，是让部署过程中那些分散的航段连接起来，让应用能够更从容地驶向它应该抵达的地方。