Openship Setup: Self-Host a Vercel-Style Deploy Platform

Openship is an open source, self-hostable deployment platform that turns any Linux box into something close to your own private Vercel, and today it is one of the fastest climbing repositories on GitHub with roughly 1,600 stars added in a single day on its way past 5,100. Two commands get you a working install: npm i -g openship then openship up. From there you point it at a project, run openship deploy, and it detects the stack, builds a container and serves it on a domain with SSL, without you writing a single pipeline file.

• Openship is Apache 2.0 licensed, so you can run, modify and ship it commercially with no source-available catch.
• Install is two commands via npm, or a Docker Compose stack if you would rather keep everything in containers.
• It bundles the parts most self-hosted PaaS tools make you find yourself: Postgres, Redis, domains, SSL, CDN, a real SMTP mail server and scheduled backups.
• Three front ends ship in the box: a desktop app, a web dashboard and a CLI, plus a REST API and an MCP endpoint for AI agents.

What is Openship and why is it trending?

Openship is built by Oblien and lives at github.com/oblien/openship. The repository is young, created on March 5, 2026, and it has spent the last four months shipping fast: 11 tagged releases in the 0.1 line, the most recent being v0.1.11 on July 18, with the standalone CLI already published to npm at 0.2.1 on July 20. The stack is TypeScript across a monorepo of six apps: api, dashboard, web, cli, desktop and email.

RelatedVibe-Trading Setup: Self-Host an AI Trading Agent Free

The reason it is spiking is not novelty, it is scope. The self-hosted deployment space is crowded, but most tools stop at "build your container and reverse proxy it." Openship's feature table goes considerably further: push-to-deploy with preview environments and rollbacks, Postgres, MySQL, MongoDB and Redis as managed services, automatic Let's Encrypt certificates including wildcards, an edge cache with HTTP/3 and Brotli, scheduled backups of both databases and volumes, and a built-in SMTP server with DKIM, SPF and DMARC so you are not wiring up Mailgun or SES for a side project. That last one is unusual. Running your own mail server is the piece almost every indie deployment tool refuses to touch.

The portability claim is the other hook. Everything Openship builds is a standard Docker container, so the exit path is ordinary docker run rather than a proprietary format. You can run it on Openship Cloud, on a Hetzner or DigitalOcean VPS, on bare metal in a colo, or on a mini PC in your closet, and the interface is identical.

How do you install Openship on Linux or macOS?

The fast path is the npm global install. This is the exact quick start from the project README:

# install the CLI (or: curl -fsSL https://get.openship.io | sh)
$ npm i -g openship
# installs Openship as a background service: starts on boot, auto-restarts
$ openship up

openship up is the important one. It does not just start a process, it registers Openship as a system service so the platform comes back after a reboot and restarts itself if it falls over. That is the behaviour you want on a server you are not babysitting. If you would rather run it attached in your terminal to watch what it does first, there is a foreground mode, and the service stops cleanly:

# one-off attached run instead of a background service
$ openship up --foreground
# open the dashboard in your browser
$ openship open
# stop the background service
$ openship stop

The CLI stores its state under ~/.openship, including a persisted auth secret so your dashboard sessions survive restarts. Node 22 is the version the repo pins in its .nvmrc, which is a reasonable floor to match on your server.

How do you deploy your first project?

Once the service is up, deploying is two commands run from inside the project directory. There is no config file to author and nothing to commit:

$ cd your-project
# link this directory to an Openship project
$ openship init
$ openship deploy

Stack detection covers Node, Python, Go, Rust, PHP, Ruby, Java, .NET, plain Docker and monorepos, and existing docker-compose.yml files can be deployed as-is rather than being rewritten. The CLI is broader than those four commands suggest: the source tree carries dedicated subcommands for logs, status, domain, backup, server, service, mail, token, deployment, update and doctor. Run openship doctor first when something looks wrong: it checks that your config file exists, that the active context holds a token, that the API answers on /api/health, and it exits non-zero so you can gate a script on it.

How do you run it with Docker Compose instead?

If you would rather not install anything globally, clone the repo and bring up the compose stack:

$ git clone https://github.com/oblien/openship.git && cd openship
$ cp .env.example .env
$ docker compose up -d

The stack is deliberately small and readable. Postgres 16 and Redis 7 run on Alpine images and are not published to the host at all, they stay on the internal network. The API listens on 4000, the dashboard on 3001 and the marketing web app on 3000, and you put your own reverse proxy in front of those. The API runs its Postgres migrations automatically on boot, so there is no separate migrate step.

One setting in .env.example is worth reading before you start: CLOUD_MODE. The same file drives both the self-hosted build and the commercial SaaS, and CLOUD_MODE=false is the self-hosted default with billing and multi-tenancy switched off. Leave it alone unless you know why you are changing it. The other one to notice is OPENSHIP_REQUIRE_REDIS=true, which forces the Redis-backed job runner and rate limiter instead of silently falling back to in-memory versions. Keep it true on anything you actually depend on, because the in-memory fallback is a single-box development convenience and it will quietly do the wrong thing across multiple replicas.

What about the desktop app?

Openship ships native installers alongside the server, which is rare for this category. The v0.1.11 release carries a Windows zip at roughly 213 MB, Intel and Apple Silicon macOS disk images at about 219 MB and 203 MB, and a Linux AppImage near 196 MB, each with a SHA-256 sidecar file next to it so you can verify the download before running it. Server tarballs are much smaller, around 33 MB for the Linux amd64 build. You can also install the desktop client from the CLI with openship install. The desktop app, the web dashboard and the CLI are three views of the same platform, so a solo developer can live in the GUI while CI uses the CLI.

How does it compare to Coolify, Dokploy and Vercel?

The honest read on that table is that Openship wins on breadth and loses on age. Coolify and Dokploy have years of people running production on them and finding the sharp edges. Openship has four months.

RelatedStrix Setup: Run an AI Penetration Tester on Your Code

What are the gotchas before you rely on it?

Three, and none of them are dealbreakers if you go in with eyes open.

The version number means what it says. The README calls the core production-ready and actively developed, but the tags read v0.1.11 and the project is four months old. Eleven releases in that window is healthy velocity, and it is also a lot of churn to sit under a production deployment. Pin a version, read CHANGELOG.md before updating, and be aware there is a release-advisories.json in the repo that flags releases as critical to the in-app updater.

The docs are openly unfinished. The README carries a note saying the documentation at openship.io/docs is still being filled out and asking for contributions. In practice that means the source tree and the compose file are your real reference right now, which is fine if you read TypeScript and less fine if you wanted a manual.

The mail server is a commitment, not a checkbox. A built-in SMTP server with DKIM, SPF and DMARC is genuinely useful, but deliverability is decided by your IP reputation, your reverse DNS and whether your VPS provider even allows port 25 outbound. Many do not. Test with a throwaway domain before you route real transactional mail through it.

Also worth noting: the two version numbers currently disagree. The npm CLI is at 0.2.1 from July 20 while the newest tagged GitHub release with desktop installers is v0.1.11 from July 18. Take the CLI from npm and the desktop app from Releases, and do not assume they are the same number.

1. Mar 5, 2026Repository created first public commit on GitHub
2. Jul 18, 2026v0.1.11 tagged desktop installers for macOS, Windows and Linux
3. Jul 20, 2026CLI 0.2.1 on npm published via npm OIDC trusted publishing, no token
4. Jul 21, 2026Past 5,100 stars roughly 1,600 added in a day on GitHub trending
5. NextMulti-node clusters plus load-balancing UI, private networking, visual CI/CD

Our take

Openship is the most interesting thing in the self-hosted deployment category right now, and it is not because of the CI/CD. It is the bundling. Every solo developer who has self-hosted an app knows the real work is not the deploy, it is the fourteen adjacent decisions: which Postgres, which backup script, which cert renewal cron, which transactional email provider, which CDN. Openship's bet is that those should be one install and one dashboard, and on the evidence of the compose file, that bet is implemented rather than promised.

The counterweight is age. This is a four-month-old project asking to run your database, your certificates and your mail. For a side project or an internal tool, install it today, the two-command setup is genuinely two commands. For anything with a revenue number attached, run it in parallel with what you already have for a couple of release cycles and see how the update path behaves. The star curve says a lot of people are about to find out at once, which is usually good for a project's bug count and bad for its early adopters.

Original analysis by GenZTech. Setup steps verified against the official Openship repository.