# Openship: a self-hosted deployment platform that puts your apps on the same box > Openship is an Apache-2.0 deployment platform with a desktop app, a CLI, and a Compose stack that runs an OpenResty edge on :80/:443. The interesting part is the split between hosting apps locally and shipping them out over SSH. **oblien/openship** — Self-hosted deployment platform. This is the flavor that hosts your deployed apps on the same box, with automatic domains + Let's Encrypt TLS. - Repository: https://github.com/oblien/openship - Website: https://openship.io - Stars: 12,484 · Forks: 1,148 - Language: TypeScript - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/oblien-openship ## The gap Openship fills: deploy without renting a platform Most deployment tools assume one of two things. Either you pay a managed platform and hand over the runtime, or you wire up a reverse proxy, a certificate renewer, a build runner and a process supervisor yourself. Openship targets the space between those: point it at a repository and it builds, ships, routes and terminates TLS for the app. The README describes it as an "Open-source, self-hostable deployment platform with built-in CI/CD" and says you drive it from a desktop app, a web dashboard or a CLI. That three-interface split is the actual product decision, not a marketing line. A solo developer gets a desktop binary with no login and no public surface. A team gets an always-on server with an admin account, push-to-deploy and shared access. The same repository serves both, which is unusual: most tools in this category pick a lane. The cost of that flexibility shows up later, in the mode matrix. ## Compose mode versus bare mode: the decision that shapes everything The README is explicit that one choice comes first, and it is how you run Openship itself. On Linux with Docker, openship up defaults to Compose mode. That brings up Postgres, Redis, the API, the dashboard and a containerized OpenResty edge bound to :80 and :443, all from published images. This is the flavor the README singles out as hosting your deployed apps on the same box, with automatic domains and Let's Encrypt TLS. Everywhere else, meaning macOS, Windows, or Linux without Docker, you get bare mode: a single process with an embedded database that deploys apps out to a server over SSH or to Openship Cloud. The distinction matters more than the install instructions suggest. If your host is a Mac mini, you are not running apps on it. You are running a control plane that pushes to something else. The docker-compose.yml in the repository root is a third thing entirely, and the file says so in a comment: it builds the api, dashboard and web from source, runs postgres and redis, and deliberately has no Docker socket and no edge, because it is the SaaS control plane. Self-hosting with the edge lives in docker/docker-compose.yml. Three stacks, one repository, and the README only walks you through two of them. ## Installing Openship and deploying a first project The CLI bundles the API and the dashboard. The README gives a one-line installer, with an npm fallback that needs Node 22 or newer: ```bash curl -fsSL https://get.openship.io | sh # install (or: npm i -g openship — needs Node 22+) openship # guided setup, then control panel ``` The install script brings its own Node when the system one is older than 22, according to the README. Running openship bare starts an interactive wizard that creates the first admin, wires your domain and installs Openship as a boot service. For a headless or CI box, the README says to skip the wizard: ```bash openship up # install + start as a background service (boots + auto-restarts) openship up --public-url https://openship.example.com # + serve the dashboard on your domain (edge + TLS handled) ``` That second form is the one that matters for self-hosting, because it is what puts the dashboard behind your own domain with the edge handling TLS. Once the instance is up, deploying is two commands from inside the project directory: ```bash cd your-project openship init # link this directory to a project openship deploy ``` openship init links the directory to a project and openship deploy builds and ships it. The README also lists openship open to open the dashboard, openship stop to stop the instance, openship update to upgrade, and openship up --foreground to run attached. If you want to preview an unreleased build, the dev installer writes a separate openship-dev command with its own home at ~/.openship-dev and its own boot service, so the production install and its data are left alone. The README calls that an unverified dev build and says it needs Bun and git. ## Where Openship gets awkward The mode split is the first real limitation. A solo developer on macOS who wants the desktop app is told plainly that the app does not host public apps on the laptop. The control plane runs locally only while the app is open, and it drives servers over SSH. That is a sensible design, but it means the "host apps on your own box" story is Linux-with-Docker only. The second limitation is rollback. The README documents openship deploy, openship update and openship stop, and nothing about reverting a bad release. The README does not document rollback. For a platform that advertises built-in CI/CD, that is a gap worth weighing before you put it in front of production traffic. Third, the interactive wizard and the boot service write state to the machine. openship up installs Openship as a background service that boots and auto-restarts, so the upgrade path is a command rather than a redeploy, and the blast radius of a bad upgrade is the whole instance. The repository carries a release-advisories.json file and a SECURITY_GUIDE.md, which suggests the maintainers think about this, but the README itself does not describe a downgrade procedure. ## Openship compared with Coolify Coolify is the obvious comparison, and the difference is architectural rather than cosmetic. Coolify is a web-first control plane: you install it on a server, open a browser and manage everything there. Openship ships a desktop application as a first-class interface, and the README positions it as the recommended path for solo developers specifically because the control plane runs locally and leaves nothing exposed. That is a genuinely different threat model. It also means Openship has a mode Coolify does not: a local control plane driving remote servers over SSH, with no always-on public endpoint until you decide you need one. The trade is that Openship asks you to understand its mode matrix before you start, while Coolify asks you to accept a browser dashboard as the entry point. If you want push-to-deploy from a Git provider on a server you own, both do it, and the choice comes down to whether you want a native app on your laptop. ## Licence, maintenance and upgrade cost Openship is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not carry the network-copyleft clause some deployment tools use, so running a modified Openship as a service does not by itself trigger a source-disclosure obligation. That is a summary of the licence text, not legal advice; if you are embedding it in a product, read LICENSE and SECURITY_GUIDE.md yourself. On maintenance, the last push was on 2026-08-25, and the release history shows v0.6.6 on 2026-08-17, v0.6.7 on 2026-08-20 and v0.6.8 on 2026-08-25, so the cadence through August was roughly weekly. Note that package.json reports version 0.7.2 while the newest listed release is v0.6.8, which means the repository has moved past the last tagged release. Upgrade cost is one command, openship update, but it replaces the running instance rather than doing a blue-green swap, and the README does not describe a rollback if the new version misbehaves. Plan for a snapshot of the Postgres volume before you run it. ## What the desktop and CLI split means for teams The README's table is the clearest statement of intent in the whole document. Solo, one machine, no ops: desktop app, apps run on a server over SSH or on Openship Cloud. Team, or you want push-to-deploy or to host apps on your own box: self-hosted server via openship up, apps run on that box in Compose mode. Not interested in running anything: Openship Cloud, managed sandboxes. A self-hosted instance always requires login, which is the admin you create during setup. The practical consequence is that push-to-deploy and team access are the two features that force you onto an always-on server. If neither matters, the desktop app is strictly less surface area. If either matters, you are running a boot service with a public endpoint, and the security posture shifts from "nothing exposed" to "everything you deploy is reachable on :443." That is not a flaw, but it is the point at which you should have an opinion about the box you are using. ## Conclusion Adopt Openship if you want a single-command control plane that builds and TLS-terminates your apps on hardware you own, and you are comfortable with the Compose mode being the only flavor that actually hosts them locally. Skip it if you need a documented rollback path or a macOS or Windows box as the host, because bare mode deploys out over SSH rather than running apps in place. Before committing, run openship up --foreground on the target machine and confirm the OpenResty edge binds :80 and :443 and that your chosen domain resolves there. ## FAQ ### What is Openship used for? It is a self-hostable deployment platform with built-in CI/CD. You point it at a repository and it builds, ships, routes and terminates TLS for the app, driven from a desktop app, a web dashboard or a CLI. ### How does Openship work in simple terms? You install it as a control plane, then run openship init and openship deploy inside a project directory. On Linux with Docker it runs in Compose mode and hosts your apps on the same box behind an OpenResty edge on :80 and :443; elsewhere it runs in bare mode and deploys out to a server over SSH or to Openship Cloud. ### How does Openship compare with Coolify? Coolify is managed through a browser dashboard on a server, while Openship ships a desktop application as a first-class interface and can run its control plane locally, leaving nothing exposed publicly. Openship also has a bare mode that deploys to remote servers over SSH without hosting apps locally. ## Sources - [Official documentation](https://openship.io) - [Official README](https://github.com/oblien/openship#readme) - [Project repository](https://github.com/oblien/openship) - [Release notes](https://github.com/oblien/openship/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oblien-openship