Openship is an open source deployment platform (Apache 2.0) that does the same thing as Vercel or Coolify on a server you control: it builds your app, deploys it, assigns it a domain, and issues an HTTPS certificate.
On September 27, 2026, the project released v0.8.0, its biggest release so far. Apps and databases can now scale across multiple of your own servers, and the MCP server grew so that a programming agent like Claude Code can operate your deployments within the limits you define. As of September 28, 2026, the repository has 13,300 stars and 1,200 forks on GitHub, about three months after its first release candidate.
What is Openship?
Openship is a self-hosted PaaS: a control plane that takes a source and runs it all the way through to production. That source can be a GitHub repo, a local folder, or an already-compiled artifact. The pipeline has five steps:
- Detects. It reads your
package.json, framework configuration, lockfiles, and anydocker-compose.yml. From that it infers the stack, package manager, build and startup commands, and port. You don’t need any config file; anopenship.jsonoverrides what it infers when you want control. - Builds. It generates a Docker image or a bare release. The resolved configuration is frozen in a snapshot, so redeploys and rollbacks run exactly what was deployed.
- Runs. The app runs as a container published only on loopback, never on a public port, or as a supervised host process.
- Routes and secures. An OpenResty edge rewrites the reverse proxy route to your domain and issues a Let’s Encrypt certificate. This happens after the app is already up. That’s why a DNS or certificate issue shows up as “action required” rather than breaking the deployment.
- Push-to-deploy. A GitHub webhook re-runs the pipeline on each push to the branch you’re tracking. In a monorepo, it rebuilds only the services that push touched.
Around that pipeline, Openship manages several things that are normally separate services:
- Databases: Postgres, MySQL, MongoDB, and Redis.
- Domains: Automatic Let’s Encrypt, including wildcards.
- CDN.
- Email: an integrated SMTP server with DKIM, SPF, and DMARC.
- Backups: scheduled, with one-click restore.
- Monitoring: live logs, container metrics, and visitor geography.
The project claims that its monitoring adds about 1.4 µs per request and zero database writes per request. That’s a figure from the project itself.
It supports Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker, and monorepos. You can also deploy your Docker Compose files as they are.
What does Openship 0.8 bring?
v0.8.0 adds clusters. You connect servers, even from different providers, through a private network you already have or a WireGuard network that Openship configures for you. Then Openship installs k3s underneath and joins those servers into a cluster. On that cluster you can:
- Run an app or worker with between 1 and 100 replicas. Changing the number of replicas reuses the active image without rebuilding. Kubernetes replaces failed instances and sends traffic to the healthy ones.
- Run PostgreSQL standalone or in a cluster, with replicas, primary recovery, and separate read/write and read-only endpoints.
- Run Redis standalone or as a cluster with shards.
- Mount shared volumes that instances on different servers can read and write.
The release also adds an SDK for Node.js (the openship package, Node 22 or higher) and releaseCommands. These are commands, for example database migrations, that run after the build and before activating the new version. If one fails, the new version doesn’t activate.
The release notes are explicit about what it still doesn’t include:
- Autoscaling based on CPU or traffic.
- Scaling of Compose apps.
- Automatic server provisioning.
- Adding servers to a running cluster.
Replicas are defined manually.
Is Openship free?
Yes, self-hosting is free and the README indicates there’s no billing. The code is Apache 2.0, so you can use it, modify it, and redistribute it, even inside commercial and closed-source products. The paid option is Openship Cloud, a managed service with sandboxes and autoscaling for those who don’t want to operate anything.
Openship, Coolify, or Dokploy?
All three solve the same problem: a self-hosted PaaS on your own VPS. If you’re already using one of the others, trying Openship doesn’t force you to start from scratch. Its migration assistant can adopt Docker stacks already running under Coolify, Dokploy, or Dokku. It brings environment variables and routes, and since v0.8.0 it also handles domain migration, reusing existing certificates.
What Openship brings to the table:
- Five ways to manage the same backend: desktop app, web dashboard, CLI, REST API, and an MCP endpoint for AI agents.
- A control plane that doesn’t have to always be on: in desktop mode, Openship runs on your machine only while the app is open and operates your servers over SSH.
- Your own email: an integrated SMTP server, without depending on Mailgun or SES.
- Clusters since v0.8.0: replicas, plus Postgres and Redis in cluster mode, on your own servers.
None of this is necessarily exclusive. Compare it to the version of Coolify or Dokploy you already have in production before migrating.
And versus Vercel?
The main difference is who operates the infrastructure. Vercel is a managed platform. Openship runs on your VPS, on bare metal, or in a homelab; the documentation mentions Hetzner, DigitalOcean, Linode, and OVH. Your apps are standard Docker containers, so you can move them between providers.
If you’re coming from Vercel, the documentation describes openship.json as the equivalent of vercel.json or railway.toml. Additionally, the routing rules from an existing vercel.json (clean URLs, redirects, and headers) are preserved when deploying.
Does Openship work on Windows or macOS?
Partially. The desktop app works on macOS (Apple Silicon and Intel), Windows, and Linux, but it’s only a control plane. It operates remote servers via SSH or Openship Cloud, and doesn’t host public apps on your laptop. In v0.6.5 the project marked local desktop deployment as “coming soon”, and the v0.8.0 release notes don’t mention it.
For a self-hosted server, it depends on the operating system:
- Linux with Docker uses “Compose mode”: the full stack, which hosts your apps on the same machine.
- macOS, Windows, or Linux without Docker use “bare mode”: a lightweight, always-on control plane that deploys to other servers or to Openship Cloud.
How do I install Openship?
First, decide where the control plane runs. After that, everything else works the same way.
Individual use: the desktop app
Download the build for your platform from the latest release on GitHub: .dmg for macOS, .zip for Windows, .AppImage for Linux. Open it, connect a server via SSH or Openship Cloud, and deploy. It doesn’t require login or expose anything publicly, because the control plane only runs while the app is open.
On Linux:
chmod +x Openship.AppImage && ./Openship.AppImage
Teams or always-on server: self-hosted
You need an always-on server for push-to-deploy, to give a team access, or to host apps on the same machine. Install the CLI, which includes the API and dashboard, and run the interactive wizard:
curl -fsSL https://get.openship.io | sh # or: npm i -g openship (requires Node 22+)
openship # guided setup, then the control plane
The wizard creates the first admin, connects your domain, and installs Openship as a startup service. On headless or CI machines, skip the wizard:
openship up
openship up --public-url https://openship.example.com
A self-hosted instance always requires login.
Deploy a project
cd your-project
openship init
openship deploy
How do I connect Openship to Claude Code via MCP?
Openship exposes an MCP endpoint at /api/mcp on your instance, with the same path on self-hosted and Openship Cloud. It works with Claude Code, Codex, Cursor, VS Code, Claude Desktop, Windsurf, and Zed. It’s a stateless Streamable HTTP endpoint that only accepts POST. If you want to understand what a stateless MCP server entails, we explain it in MCP goes stateless.
In Claude Code, connecting it is a single command:
claude mcp add --transport http openship https://<your-host>/api/mcp
A browser window opens where you choose what the agent can do. The options are read-only or full control, across all resources or only specific projects, servers, and repositories. From there, the agent can list projects, launch deployments, read logs, and add domains, always within that scope.
What’s interesting is the security model. Every tool call goes through the same authorization and per-resource permission checks as a normal API request, so MCP isn’t a looser back door. Token, auth, and MCP management routes can never become tools, so an agent can’t issue itself new credentials. Plus, each tool carries indicators marking it as read-only or destructive, so the client warns you before running a destructive call.
If you’re interested in the security side of giving an agent tools, we cover it in MCP Gateway: the next big security category for agents.
What should I check before using it in production?
- Release pace. As of September 28, 2026, the project has had 14 releases in about three months. That indicates active development, and also means details in this note may change soon.
- Update to 0.8.0. The release runs database migrations. Before updating, back up your database and keep your instance’s encryption key (
BETTER_AUTH_SECRET). - Manual installation with Docker Compose. It mounts the host’s Docker socket inside the API container, giving it host-level privileges. Use it only on a trusted host; the CLI and desktop app are the recommended paths.
- Security history. The project has a private advisories process with a safe harbor policy, and several releases have included fixes for externally reported issues. Keep your instance updated.