Openship

Openship is an open-source deployment platform that replicates the push-to-deploy experience of managed PaaS providers like Heroku or Vercel on infrastructure you control. Point it at a GitHub repo, a local folder, or a prebuilt artifact and it runs one pipeline end to end: it detects the stack from package.json, framework config, lockfiles, and any docker-compose.yml or openship.json; builds a Docker image or bare release; runs it as a loopback-only container or supervised host process; and routes it through an OpenResty edge that issues Let’s Encrypt certificates without ever failing the deploy on a DNS or cert hiccup. A GitHub webhook re-runs the pipeline on every push, rebuilding only the services a monorepo push actually touched.

The project is explicit about separating how you run Openship itself from where your apps run. Solo developers can run a desktop app that drives remote servers over SSH with no public surface at all; teams that want CI/CD, multiple users, or to host apps on the same box run openship up, which auto-selects a Docker Compose stack (Postgres, Redis, API, dashboard, and a containerized edge) on Linux or a lightweight bare-mode process everywhere else. The same backend is exposed through a web dashboard, a scriptable CLI, an MCP endpoint for AI agents, and a REST API, so automation and human operators share one source of truth for deployments, domains, and permissions.

Beyond builds and routing, Openship bundles the rest of an application platform: managed Postgres/MySQL/MongoDB/Redis, automatic domains with wildcard TLS, an edge CDN with HTTP/3 and Brotli, scheduled backups with one-click restore, real-time build/container monitoring, and a self-hosted mail server (an iRedMail + Zero Email pairing) so teams can drop Mailgun or SES entirely. Every build is frozen into a snapshot, so redeploys and rollbacks re-run exactly what previously shipped rather than re-resolving configuration on the fly.

Openship supports Node, Python, Go, Rust, PHP, Ruby, Java, .NET, and existing Docker Compose files, and can target a VPS, a dedicated or colo server, multiple servers, or Openship Cloud for teams that don’t want to run anything themselves. Self-hosting is Apache-2.0 licensed and free, with no license key gating the deployment, routing, backup, or mail-server functionality.

What You Get

• A full build-to-route pipeline (detect → build → run → route + secure) that needs zero config files for common stacks, with an openship.json override for anything unusual
• Push-to-deploy CI/CD via GitHub webhooks that only rebuilds the services a monorepo push actually touched, plus preview environments and rollbacks via frozen build snapshots
• Automatic domains and wildcard Let’s Encrypt TLS from an OpenResty edge, with routing/TLS failures surfaced as “action required” instead of taking the app or the deploy down
• Three drivable interfaces on one backend — Electron desktop app, web dashboard, and scriptable CLI — plus an MCP endpoint for AI agents and a REST API for automation
• Managed databases (Postgres, MySQL, MongoDB, Redis), scheduled backups with one-click restore, real-time build/container monitoring, and CDN edge caching
• A built-in self-hosted mail server (iRedMail engine + Zero Email server/client) with DKIM/SPF/DMARC, so teams can run transactional and inbox email without a third-party ESP

Common Use Cases

• Solo developers moving off Heroku/Vercel billing onto a VPS while keeping push-to-deploy from GitHub
• Teams standing up an internal, always-on PaaS so every engineer can deploy previews and staging environments without touching raw infrastructure
• Agencies hosting many client projects on one dedicated box using automatic per-project domains and TLS
• Organizations deploying an existing Docker Compose stack as-is and gaining CI/CD, TLS, and monitoring without rewriting configs
• Wiring an MCP-compatible AI agent to trigger deploys and check status through permission-scoped tool routes, with credential routes never exposed as tools

Under The Hood

Architecture Openship is a Turborepo monorepo that separates the deployment engine from its interfaces: packages/core holds framework-agnostic domain logic (stack detection per language, app templates, cloud-capability gating), packages/adapters holds the mechanics of actually deploying (Dockerfile compilation, the OpenResty/Lua edge, bare and cloud runtime pipelines, image transfer over SSH), and packages/db wraps Drizzle behind a single Database type so callers never know whether the underlying driver is full Postgres or embedded PGlite. The Hono API in apps/api is organized into one module per domain (deployments, domains, backups, mail, jobs, tunneling, mcp, billing) and every mutating route must pass through a secureRouter wrapper; a boot-time route scanner in route-scanner.ts walks the registered route table and refuses to start the process if any route bypasses that wrapper or declares an inconsistent permission tag, turning an authorization review into a deploy-time gate rather than a runtime hope. The desktop app, web dashboard, and CLI are three separate consumers of the same API/adapters layer, so a change to the core deploy pipeline changes behavior everywhere at once.

Tech Stack The whole monorepo is TypeScript on Bun (with Node 22+ supported), orchestrated by Turborepo. The API (@repo/api) runs on Hono with @hono/node-server, Better Auth for authentication, BullMQ/ioredis for background jobs, TypeBox for request validation, Stripe for cloud billing, and Drizzle ORM over Postgres (or PGlite for the embedded bare-mode install). The dashboard is Next.js 16 on React 19 with Radix UI primitives and xterm.js for live terminal streaming; the desktop app wraps the same UI in Electron. The CLI uses Commander and Clack prompts, and drives Docker via Dockerode plus SSH2 for remote hosts. The edge is a purpose-built OpenResty (nginx + Lua) Docker image that terminates TLS via Certbot’s standalone HTTP-01 flow on a loopback alt-port, avoiding a webroot or a port-80 conflict with the app it’s fronting.

Code Quality The repository ships 201 test files run with Vitest, and CI (.github/workflows/ci.yml) runs a strict typecheck across both the API and the dashboard on every PR and push to main. Errors are modeled as a typed AppError hierarchy (NotFoundError, UnauthorizedError, ForbiddenError, ValidationError) rather than ad hoc throws, and security-sensitive paths carry their own regression tests referencing CWE identifiers directly in test comments (e.g. the zero-auth-guard tests locking in that a network-reachable install can never silently bootstrap an unauthenticated admin). Naming and module boundaries are consistent throughout (module-per-domain, adapters vs. core vs. db split), and a dedicated SECURITY.md/SECURITY_GUIDE.md pair documents the project’s threat model.

What Makes It Unique Most self-hosted deployment platforms pick one deployment shape and stick to it; Openship instead auto-selects between a full Compose stack (when Docker is present on Linux) and a single embedded-database bare process (everywhere else), while exposing the identical desktop/web/CLI/MCP/REST surface over either. The boot-time route-permission scanner is an unusually strong compile-adjacent safety net for a self-hosted admin panel. The routing/TLS step is deliberately decoupled from deploy success — a DNS or certificate failure is reported as “action required” rather than rolling back or blocking the app — which is a considered UX choice for a platform whose users are often managing their own DNS for the first time. Bundling a full self-hosted mail server (iRedMail + a Zero Email fork) alongside the deploy pipeline is also uncommon among comparable self-hosted PaaS tools.

Self-Hosting

Licensing Model Openship is Apache-2.0 licensed. All deployment, routing/TLS, database, backup, monitoring, and mail-server functionality documented in the README is available in self-hosted installs with no license key or feature gate.

Self-Hosting Restrictions

• None found. No requiresLicense/isPro/isEnterprise gates were found in the deployment, routing, or backup code paths.
• The one isPro flag found in the repo lives in an unrelated bundled sub-app’s client fixtures (the self-hosted email client) and does not gate any Openship deployment feature.

Enterprise Features There is no separate paid self-hosted tier. “Enterprise”-style capabilities (scaling, multi-node, backups, CDN, mail server) are part of the same open-source build.

Cloud vs Self-Hosted Openship Cloud is a separate, optional managed hosting target (auto-scaling, zero setup, managed sandboxes) with its own billing — it is a place to deploy TO, not a license tier gating the self-hosted software. Certain cloud-only capabilities (e.g. cloud-deploy-target, managed-project-domain, github-cloud-app) are explicitly modeled as “needs an Openship Cloud connection,” not “needs a self-hosted license.”

License Key Required No. The README states self-hosting is free with no billing required; nothing in the CLI, API, or edge requires a license key to install or run the core platform.