Openship: A Self-Hosted Deployment Platform That Puts Apps and Control Plane on the Same Box
Self-hosted deployment platform. This is the flavor that hosts your deployed apps on the same box, with automatic domains + Let's Encrypt TLS.
At a glance
- What is it?
- Openship is an open-source deployment platform with built-in CI/CD. Its Compose mode hosts your apps on the same server as the control plane, with automatic domains and Let's Encrypt TLS. This review covers the architecture, setup, and trade-offs.
- Who is it for?
- Adopt Openship if you are a solo developer or a small team wanting a self-hosted deployment platform with built-in CI/CD and automatic TLS, especially if you prefer to host apps on the same box as the control plane. Avoid it if you need a managed, zero-ops solution or if your deployment target is a server without Docker and you require same-box hosting.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Openship Solves and Who It Is For
Openship addresses the problem of deploying applications from a repository to a server without juggling multiple tools for building, shipping, routing, and TLS termination. The README describes it as an open-source, self-hostable deployment platform with built-in CI/CD: you point it at a repo, and it builds, ships, routes, and TLS-terminates your app. The intended audience is broad but clearly segmented. Solo developers who do not want to run an always-on server can use the desktop app, which runs the control plane locally only while the app is open. Teams that need push-to-deploy, team access, or hosting apps on their own box are directed to the self-hosted server mode. This distinction matters because it sets expectations: Openship is not a one-size-fits-all PaaS; it adapts to whether you want a lightweight local client or a full always-on control plane.
The Two Modes: Compose and Bare
The core architectural decision in Openship is how the control plane runs. The README presents a table that maps user types to modes: solo users use the desktop app, teams use the self-hosted server, and those who want zero setup use Openship Cloud. The self-hosted server has two sub-modes. On Linux with Docker, `openship up` defaults to Compose mode, which brings up a full stack: Postgres, Redis, API, dashboard, and a containerized OpenResty edge on ports 80 and 443. This mode hosts deployed apps on the same box, with automatic domains and Let's Encrypt TLS. Everywhere else, including macOS, Windows, or Linux without Docker, it runs in bare mode: a single lightweight process with an embedded database. Bare mode deploys apps out to a server over SSH or to the Cloud, similar to the desktop app but always on and requiring login. This split is practical but introduces a constraint: if you want same-box hosting, you must have Docker on a Linux server.
How Deployment Works: From Repo to Running App
The deployment flow is straightforward from the user's perspective. After installing the CLI, you run `openship init` in your project directory to link it to a project, then `openship deploy`. The README does not detail the internal steps between these commands, but the described architecture implies a pipeline: the control plane receives the repository, builds it (presumably in a container or via a build process), ships the resulting artifact, configures routing through the OpenResty edge, and provisions a Let's Encrypt TLS certificate for the automatic domain. The edge component on ports 80 and 443 is central to this: it handles incoming traffic and terminates TLS, which is why automatic domains and certificates work without manual reverse proxy setup. The README's claim that it 'builds, ships, routes, and TLS-terminates' is consistent with this design, but the exact build isolation and artifact transfer mechanisms are not specified in the provided material.
Getting Started: Commands and Config Keys
The README provides concrete commands for installation and setup. For the self-hosted server, the install command is `curl -fsSL https://get.openship.io | sh`, or `npm i -g openship` if you have Node 22 or later. Then you run `openship` to launch an interactive wizard that creates the first admin, wires your domain, and installs Openship as a boot service. For CI or headless boxes, you can skip the wizard and run `openship up` directly. This command installs and starts Openship as a background service that boots and auto-restarts. You can add `--public-url https://openship.example.com` to serve the dashboard on your domain, with edge and TLS handled by Openship. The `--compose` and `--bare` flags force a specific mode. Other useful commands include `openship open` to open the dashboard, `openship stop` to stop it, `openship update` to upgrade, and `openship up --foreground` to run attached. Shell completion is also available via `openship completion <shell>`.
A Genuine Limitation: The Docker Dependency for Same-Box Hosting
The most significant limitation is that the same-box hosting flavor, which is the headline feature, only works in Compose mode, which requires Linux with Docker. If you are on macOS or Windows, or on a Linux box without Docker, `openship up` will fall back to bare mode, and your apps will not be hosted on that box; they will be deployed out to another server or the Cloud. This means that the promise of 'hosts your deployed apps on the same box' is conditional on your infrastructure meeting a specific prerequisite. The README does not discuss what happens if Docker is present but misconfigured, or how to handle resource contention between the control plane stack (Postgres, Redis, OpenResty) and the deployed apps. For a solo developer with a single VPS, this could be a dealbreaker if you do not want to run Docker. The README does not mention any non-Docker option for same-box hosting, so you should verify your environment before committing.
Maintenance and Upgrade Costs
The README gives some clues about maintenance. The self-hosted server installs as a boot service, which means it is designed to run continuously and auto-restart, reducing the need for manual intervention. Upgrades are handled via `openship update`, which presumably pulls the latest version and restarts the service. For the desktop app, updates are not described, but since it is a desktop application, it likely follows the standard update mechanism of the platform. The CLI also supports a dev build path via `openship-dev`, which is installed separately and can be updated with `openship-dev update`. This is useful for testing unreleased builds without affecting the production instance. The README does not detail the upgrade process for the underlying components in Compose mode, such as how Postgres or Redis are updated, nor does it mention any migration steps for the embedded database in bare mode. You should consult the documentation for version-specific upgrade notes.
Licence and Alternative Approaches
Openship is licensed under Apache-2.0, which is a permissive open-source license that allows use, modification, and distribution, including in commercial products, as long as you preserve the license notice. This is a positive for teams that want to customize the platform. As for alternatives, the README implicitly positions Openship against managed PaaS offerings like Heroku or Vercel, but the key difference is the self-hosted nature and the same-box hosting option. A more direct alternative is something like CapRover, which also provides a self-hosted PaaS with automatic HTTPS and app deployment on a single server. The difference in approach is that CapRover typically runs as a single Docker container on your server, managing apps via a web UI and using Docker under the hood, whereas Openship offers a split between a control plane and deployment targets, with the option to run the control plane as a desktop app. This makes Openship more flexible for those who want to manage multiple servers or use a local control plane, but it adds complexity compared to a single-box solution like CapRover.
Who Should Adopt It and What to Verify First
Openship is a good fit for developers who want a self-hosted deployment platform with built-in CI/CD and automatic TLS, and who are comfortable running a control plane on a server or locally. The desktop app is particularly appealing for solo developers who want to avoid maintaining an always-on server. Teams that need push-to-deploy and team access will benefit from the self-hosted server mode. However, if you are looking for a zero-maintenance, fully managed solution, Openship Cloud is the intended path, but that is not self-hosted. If you need same-box hosting, you must verify that your server runs Linux with Docker. Before adopting, check the documentation for details on scaling beyond a single box, how the OpenResty edge handles multiple apps, and what happens during upgrades. The README does not cover these scenarios, so you should test a small deployment first to see if the automatic domain and TLS provisioning work as expected in your environment.
Editorial conclusion
Adopt Openship if you are a solo developer or a small team wanting a self-hosted deployment platform with built-in CI/CD and automatic TLS, especially if you prefer to host apps on the same box as the control plane. Avoid it if you need a managed, zero-ops solution or if your deployment target is a server without Docker and you require same-box hosting. Before adopting, verify the Compose mode's Docker dependency, the requirement for a public always-on endpoint for push-to-deploy, and the login requirement for self-hosted instances. Check the documentation for details on scaling and multi-node setups, as the README does not cover those scenarios.
Community notes