--- title: "Openship Review: Self-Hosted PaaS vs Coolify and Dokploy" description: "Hands-on look at Openship, the new open-source deploy platform. Install with CLI or Docker Compose, compare it to Coolify and Dokploy, and see when each tool fits." date: 2026-07-20 categories: ["vps"] tags: ["openship","self-hosted","docker"] --- import ListCheck from "@components/widgets/ListCheck.astro"; import Notice from "@components/widgets/Notice.astro"; import Accordion from "@components/widgets/Accordion.astro"; import Tabs from "@components/widgets/Tabs.astro"; import Tab from "@components/widgets/Tab.astro"; import Button from "@components/widgets/Button.astro"; import { Picture } from "astro:assets"; import openshipUi from "../../assets/images/26/07/openshipui.webp"; [Openship](https://openship.io/) showed up in the self-hosted PaaS space with a clear pitch: push code, get containers, keep full ownership. The project is Apache 2.0, lives at [github.com/oblien/openship](https://github.com/oblien/openship), and already sits around 3.6k GitHub stars with a managed cloud option if you do not want to run the control plane yourself. I already run and write about [Coolify](/coolify-install-heroku-alternative/) and [Dokploy](/dokploy-install/). Both solve the "I want Heroku on my VPS" problem. Openship is the new one in that same drawer, with a few ideas that are different enough to notice: builds can stay off the production box, there is a real CLI plus desktop app, hybrid cloud/self-host is part of the product story, and it ships a built-in mail server. This guide covers what Openship is, how to install it (CLI, Docker Compose, desktop, cloud), how it stacks up against Coolify and Dokploy, and when I would pick each one. You will need a Linux VPS (or a laptop for local/desktop use). [Hetzner](https://go.bitdoze.com/hetzner) and similar providers work fine. For more panel options, see [best self-hosted server panels](/best-self-hosted-panels/) and [Coolify vs Dokploy vs Kamal 2](/coolify-vs-dokploy-vs-kamal-2/). ## What is Openship? Openship is an open-source deployment platform with built-in CI/CD. You connect a Git repo (or a local project), it detects the stack, builds an image, ships a container, and wires domains plus SSL. You can run it three ways: 1. **Openship Cloud** — managed control plane and compute, pay for usage 2. **Self-hosted** — full stack on your Linux box or VPS 3. **Hybrid** — mix managed services and your own servers under one workflow Interfaces are broader than most self-hosted panels: - CLI (`openship`) - Web dashboard - Desktop app (Mac, Windows, Linux AppImage) - REST API and MCP for AI agents Official docs still call parts of the product early, but the core path (install, link project, deploy) is documented at [openship.io/docs](https://openship.io/docs). Current release at the time of writing is in the `0.1.x` range. ## How Openship deploys apps The marketing site describes a flow that is worth understanding before you install anything: 1. **Connect** — link a Git repo and pick a target (Openship Cloud or your server over SSH). Their pitch is that nothing heavy has to live on the target box as a permanent agent/dashboard for every node. 2. **Build** — image build can run on your machine or in the cloud, then get tagged as an immutable artifact. Production stays focused on serving traffic. 3. **Ship** — the image goes to the target over SSH and starts as a container on a private network. 4. **Route** — OpenResty + Let's Encrypt for domains and SSL, with zero-downtime swaps and one-click rollbacks. 5. **Operate** — logs, metrics, rollbacks from CLI, web UI, desktop, or MCP. That "build elsewhere, run plain containers on the server" angle is the main contrast with Coolify and Dokploy, where the control plane and often the build job sit on the same VPS that runs your apps. ## Key features | Area | What you get | | :--- | :--- | | CI/CD | Push-to-deploy, preview envs, rollbacks, immutable deploys | | Stacks | Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker, monorepos | | Data | Postgres, MySQL, MongoDB, Redis, object storage, workers | | Networking | Custom domains, wildcards, auto SSL, private networking | | Ops | Live logs, metrics, scheduled jobs, backups | | Mail | Built-in transactional mail with SPF/DKIM/DMARC setup | | Interfaces | CLI, web, desktop, REST, MCP | | License | Apache 2.0 | The mail piece is unusual. Coolify and Dokploy do not try to replace SES/Mailgun for you. Openship does, which is nice for password resets and receipts if you want fewer third-party accounts. I would still treat deliverability as something you verify yourself (reputation, reverse DNS, warm-up), not a free pass. ## System requirements From the [installation docs](https://openship.io/docs/installation): | Component | Minimum | Recommended | | :--- | :--- | :--- | | CPU | 2 cores | 4+ cores | | RAM | 2 GB | 4+ GB | | Disk | 20 GB | 50+ GB SSD | | OS | Ubuntu 22.04+ | Ubuntu 24.04 | For a real multi-app box I would start at 4 GB RAM the same way I do with Dokploy. Docker Compose mode also runs Postgres + Redis + API + dashboard, so do not starve it. ## Install Openship Pick one path. CLI is the fastest for a single server. Docker Compose is better if you want the stack explicit and portable. Desktop is for local work. Cloud skips ops entirely. ### Option 1: CLI (quickest self-host) Works on Linux and macOS. Installs the CLI, then starts Openship as a background service (systemd user unit with linger on Linux, launchd on macOS). ```bash # Install CLI curl -fsSL https://get.openship.io | sh # Or via a JS package manager npm i -g openship # pnpm add -g openship # bun add -g openship ``` Start the platform: ```bash openship up ``` That brings up the API on `:4000` and the dashboard on `:3001`. First run downloads what it needs. Local access needs no login. Useful commands: ```bash openship open # open dashboard openship status # health check openship stop # stop service (no auto-restart on reboot) openship up --foreground # run attached in this terminal openship up --no-ui # API only ``` ### Option 2: Docker Compose Use this when you want Postgres, Redis, API, dashboard, and the web app as normal containers you can inspect and back up like anything else. ```bash git clone https://github.com/oblien/openship.git cd openship cp .env.example .env ``` Edit `.env` before you start. At minimum change secrets: ```bash # Generate secrets node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" ``` Set at least: ```env CLOUD_MODE=false DEPLOY_MODE=docker POSTGRES_USER=openship POSTGRES_PASSWORD=replace-with-strong-password POSTGRES_DB=openship BETTER_AUTH_SECRET=replace-with-32-byte-hex INTERNAL_TOKEN=replace-with-another-32-byte-hex BETTER_AUTH_URL=http://YOUR_SERVER_IP:4000 OPENSHIP_REQUIRE_REDIS=true ``` Then build and start: ```bash docker compose up -d --build ``` Services from the upstream compose file: | Service | Port | Role | | :--- | :--- | :--- | | `postgres` | internal 5432 | Platform DB | | `redis` | internal 6379 | Queue, cache, rate limits | | `api` | 4000 | Control plane | | `dashboard` | 3001 | App UI | | `web` | 3000 | Marketing/docs site | Check health: ```bash curl -s http://127.0.0.1:4000/api/health docker compose ps docker compose logs -f api ``` Open `http://YOUR_SERVER_IP:3001` for the dashboard. Put Caddy/Nginx/Traefik in front with TLS before you expose this on the public internet. The sample `.env` values are for local bring-up. Change `POSTGRES_PASSWORD`, `BETTER_AUTH_SECRET`, and `INTERNAL_TOKEN` on any VPS. The API refuses to boot without a real `INTERNAL_TOKEN` on non-desktop deploys. ### Option 3: Desktop app Handy for local deploys from a folder without standing up a server panel. **Linux AppImage:** ```bash curl -fsSL -o Openship.AppImage \ https://github.com/oblien/openship/releases/latest/download/Openship.AppImage chmod +x Openship.AppImage ./Openship.AppImage ``` If FUSE is missing on Debian/Ubuntu: ```bash sudo apt-get install -y libfuse2 # or: ./Openship.AppImage --appimage-extract-and-run ``` **macOS / Windows:** grab the latest DMG or ZIP from [GitHub releases](https://github.com/oblien/openship/releases/latest), or run `openship install` after the CLI is present. ### Option 4: Openship Cloud If you want zero control-plane maintenance: 1. Sign up at [app.openship.io](https://app.openship.io/) 2. Connect a repo 3. Deploy From a machine with the CLI, you can point at a remote API instead of running local: ```bash openship login --api-url https://api.example.com --token YOUR_PAT ``` ## Deploy your first app After the platform is up: ```bash cd your-project openship init # link directory to a project openship deploy ``` `openship init` writes `.openship/project.json` so later commands know which project to use. Preview deploys: ```bash openship deploy --env preview ``` From there you add custom domains, env vars, and Git auto-deploys in the dashboard or via the [docs for first deployment](https://openship.io/docs/first-deployment). Supported stacks on paper include Next.js, Node, Python, Go, Rust, Docker, Postgres, Redis, Rails, Laravel, Django, Bun, and more. For existing compose apps, Openship claims you can deploy compose files as-is, same general idea as [Dokploy Compose deploys](/dokploy-docker-compose-app/). ## Openship vs Coolify vs Dokploy I care less about feature checklists than about day-to-day friction: RAM tax, how builds behave under load, how painful SSL and rollbacks are, and whether the project will still be around next year. ### Quick comparison | | Openship | Coolify | Dokploy | | :--- | :--- | :--- | :--- | | **Maturity** | New (`0.1.x`, growing fast) | Mature (v4 stable, v5 multi-server in progress) | Mature, very active | | **GitHub stars (approx.)** | ~3.6k | ~50k+ | ~30k+ | | **License** | Apache 2.0 | Apache 2.0 | Mixed (core open, some source-available) | | **UI** | Web + desktop + CLI | Web dashboard | Web dashboard | | **Build location** | Can build on your machine / off prod | Usually on the Coolify server | Usually on the Dokploy server | | **Reverse proxy** | OpenResty | Caddy | Traefik | | **Idle footprint** | Compose stack needs Postgres+Redis+API+UI | ~1.5–2 GB | ~400–500 MB | | **One-click templates** | Smaller / early | 280+ | Dozens | | **Databases** | Postgres, MySQL, Mongo, Redis + tooling | Strong UI + backups | Good enough + S3/R2 backups | | **Mail server** | Built-in | No (bring your own) | No (bring your own) | | **MCP / AI agents** | Yes | Yes (v4.1+) | Limited / evolving | | **Cloud option** | First-party Openship Cloud + hybrid | Coolify Cloud exists | Mostly self-host focused | | **Best fit today** | Experimenters who want CLI/desktop/hybrid | All-in-one hub, lots of services | Lightweight VPS PaaS | ### Where Openship looks strong **Multiple clients for the same backend.** Coolify and Dokploy are dashboard-first. Openship treats CLI and desktop as first-class, which is closer to how a lot of devops people actually work. MCP on top is useful if you already drive infra from agents. **Build off the production box.** On a 2–4 GB VPS, a Nixpacks/Railpack build can OOM the same machine that serves traffic. Openship's "build locally or in the cloud, stream the image" model is the right shape for small boxes. Kamal does something similar with a registry; Openship packages more of the platform around it. **Hybrid and exit story.** Cloud ⇄ self-host without rewriting the app is a real selling point if you are tired of Vercel-style lock-in. Everything ships as normal containers. **Built-in mail.** Niche, but if you hate bolting on yet another transactional email vendor for a side project, it is a differentiator. ### Where Openship is weaker today **Age and ecosystem.** Coolify has years of edge cases filed and fixed. Dokploy has a pile of community compose templates and guides (including several on this site). Openship docs still say they are filling things out. Expect rough edges. **Template library.** If you want one-click Plausible, Outline, n8n, and friends, Coolify still wins. Dokploy is lighter but you can paste compose files easily. Openship is more "bring your app" than "app store for self-hosting." **Operational track record.** Production-ready core is the claim. For a business app with uptime SLAs, I would still put Coolify or Dokploy first until Openship has more public battle scars and longer release history. **Resource story is not "zero overhead."** CLI mode with an embedded DB is lighter than full Compose, but Compose mode is a real multi-service stack. It is not Kamal's "almost nothing on the server" model. See the Kamal section in [Coolify vs Dokploy vs Kamal 2](/coolify-vs-dokploy-vs-kamal-2/) if that is what you want. ### Feature-oriented breakdown - **Coolify** — richest UI, biggest service catalog, heaviest RAM. Best when the panel *is* your ops console for many apps. Full [Coolify v5 review](/coolify-v5-self-hosted-paas-review/). - **Dokploy** — clean UI, low idle RAM, Swarm when you outgrow one node. My default on cheap VPS boxes. [Install guide](/dokploy-install/). - **Openship** — CLI + desktop + web. Feels closer to a productized deploy toolkit than a pure hosting panel. Better if you live in the terminal or want local GUI without SSHing into a panel. - **Coolify / Dokploy** — git webhook → build on server → restart container behind Caddy/Traefik. - **Openship** — connect repo or local dir → build (often off-box) → ship image over SSH → route via OpenResty → rollback from immutable versions. - **Implication** — Openship can spare small VPS boxes from build spikes; Coolify/Dokploy keep the whole loop on one machine you already manage. | Need | Prefer | | :--- | :--- | | 280+ one-click apps | Coolify | | Small VPS, simple SaaS deploys | Dokploy | | CLI + desktop + MCP | Openship | | Scheduled DB backups to R2 | Dokploy ([guide](/dokploy-backups-cloudflare-r2/)) or Coolify | | Built-in transactional mail | Openship | | Multi-server today | Dokploy Swarm; Coolify multi-server maturing in v5 | | Managed cloud fallback | Openship Cloud or Coolify Cloud | ## When to pick which tool You want to try a modern Apache-licensed PaaS with CLI and desktop, you like the idea of building off the prod server, or you want a path between managed cloud and your own VPS without two different products. Good for side projects, labs, and teams already comfortable living with a young `0.1.x` tool. You want one dashboard for many services, huge template coverage, and a large community. You have at least 4 GB RAM (honestly 8 GB if you stack apps). See [Coolify install](/coolify-install-heroku-alternative/). You want a lightweight Heroku-like panel on a 2 GB VPS, native Compose support, and optional Swarm. That is still my default recommendation for most readers. Start with [Dokploy install](/dokploy-install/). You want almost zero control-plane overhead and are fine with YAML + CLI only. Covered in the [three-way comparison](/coolify-vs-dokploy-vs-kamal-2/). ## Practical tips if you self-host Openship 1. **Put TLS in front early.** Dashboard on `:3001` and API on `:4000` should not sit naked on `0.0.0.0` for long. 2. **Back up Postgres volumes** if you use Compose. Treat `postgres_data` like any other state volume. 3. **Pin a release** when you clone for Compose (`git checkout v0.1.x`) so a random `git pull` does not surprise you mid-week. 4. **Keep firewall rules tight.** Only 80/443 public if you reverse-proxy; lock SSH to keys. 5. **Test rollback** on a throwaway app before you trust it with something you care about. 6. **Read the security notes** in the repo (`SECURITY.md`) and rotate `INTERNAL_TOKEN` / auth secrets if they ever leak into logs or chat. ## FAQ The maintainers describe a production-ready core that is still moving quickly. For non-critical apps and internal tools, sure. For revenue-critical production with a small ops team, I would pilot it first and keep Coolify or Dokploy as the safe default until the release line and docs settle further. Not yet for most people. It overlaps, but the product shape is different (CLI/desktop/hybrid/mail). Think of it as another option in the self-hosted PaaS shelf, not an automatic upgrade path. That is part of the design pitch: plain containers and standard images. You should still export env vars, volumes, and DNS yourself. There is no magic "export my whole company" button that removes ops work. CLI if you want the vendor-supported service install and embedded DB path. Compose if you want visible containers, standard Postgres/Redis, and the same mental model as the rest of your Docker hosts. ## Useful links - Site: [openship.io](https://openship.io/) - Docs: [openship.io/docs](https://openship.io/docs) - GitHub: [github.com/oblien/openship](https://github.com/oblien/openship) - npm: [npmjs.com/package/openship](https://www.npmjs.com/package/openship) - Related on bitdoze: [Dokploy install](/dokploy-install/), [Coolify install](/coolify-install-heroku-alternative/), [Coolify v5 review](/coolify-v5-self-hosted-paas-review/), [Coolify vs Dokploy vs Kamal](/coolify-vs-dokploy-vs-kamal-2/), [best self-hosted panels](/best-self-hosted-panels/) ## Bottom line Openship is a credible new entry in the self-hosted PaaS space. The interesting bits are the multi-surface UX (CLI, desktop, web, MCP), off-box builds, hybrid cloud story, and Apache 2.0 license. The weak bits are the obvious ones for a young project: smaller community, thinner template ecosystem, and less proven long-term ops history than Coolify or Dokploy. If you already like Dokploy on a small VPS, you do not need to migrate. If you enjoy trying new deploy tools and want something that feels closer to a modern product than a pure panel, install it with the CLI or Compose stack above and ship a throwaway app first.