Primary question: Does your team need a single self-hosted tool that handles build, deploy, TLS, CDN, mail, and backups — and can you commit to staying on the latest release for security patches?
RepoDaily adoption score
RepoDaily rates this as 91/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
6 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
4 workflow step(s), 5 next-action step(s), and 6 command/install signal(s) were detected.
Trending momentum is +1,719 stars, with maintenance/release/issue signals counted when present.
Risk is marked medium, with 6 security note(s) and 3 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 4 type-specific section(s) support differentiation.
License source or license wording is present.
3 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
Openship is an open-source, self-hostable deployment platform written in TypeScript. It detects your stack, builds it, configures databases, domains, SSL, and mail, then ships standard Docker containers — all without config files, pipelines, or YAML. The README pitches a blunt promise: "zero config files, zero pipelines, zero YAML." You point it at a repo and it figures out Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker, and monorepo layouts.
The project exposes three interfaces: a desktop app, a web dashboard, and a CLI (`openship deploy`). It works with either Openship Cloud, the managed offering, or any Linux server you own. The same binary serves a solo dev shipping a side project and a team running production workloads — the difference is whether `CLOUD_MODE=true` is set, which gates cloud-only modules like billing.
On July 21, 2026, Openship sits at trending rank 2 with 1,719 period stars. Its topic tags — agents, ai, deployments, self-hosted — signal where the maintainers are pointing: a deployment substrate that is self-hosted first and increasingly agent-aware. The 0.2.0 changelog shows concrete hardening work across the deploy flow, the app catalog, routing, servers, and the build toolchain, which is the kind of breadth you expect from a project trying to be the control plane, not just a runner.
Why it is trending now
- 1,719 stars in the period and trending rank 2 on 2026-07-21, driven by the 0.2.0 release that redesigned the deploy step, expanded the one-click catalog to 15 apps, and fixed a cross-cutting `pnpm: not found` build error.
- Self-hosted deployment platforms with built-in CI/CD, TLS, and mail are a crowded category, but Openship's pitch of zero YAML and standard Docker containers hits a real pain point for developers tired of gluing Coolify, Dokku, Nginx, and a separate mail relay together.
- The one-click app catalog now includes production-ready templates for Convex, n8n, Ghost, Directus, NocoDB, Metabase, Grafana, Gitea, code-server, Uptime Kuma, Vaultwarden, FreshRSS, Stirling PDF, IT-Tools, and Excalidraw — a broad surface that attracts both self-hosters and AI-tooling operators.
- Apache-2.0 licensing and a Bun + TypeScript monorepo (Hono API on port 4000, Next.js dashboard on port 3001) lower the barrier for contributors who want to read and extend the code.
Problem it solves
- Configuring a deployment pipeline usually means writing Dockerfiles, compose files, CI YAML, Nginx configs, a mail relay, and a cron-based backup script — then maintaining all of it across staging and prod.
- Managed platforms like Vercel and Render remove that friction but lock you into their runtime, pricing, and data residency. Self-hosted alternatives like Coolify exist, but Openship differentiates by bundling a full SMTP mail server with DKIM/SPF/DMARC and a CDN with HTTP/3 and Brotli.
- Keeping TLS certificates, domains, and SSL renewals working across single-app and service-based projects is fiddly; Openship routes both through one verify → DNS-records → SSL pipe and gates certbot on verification to avoid wasted Let's Encrypt attempts.
How it works
- Install Openship globally with `npm i -g openship` (or `curl -fsSL https://get.openship.io | sh`), then run `openship up` to install it as a background service that starts on boot and auto-restarts.
- Run `openship open` to open the dashboard, or `openship init` inside a project directory to link that directory as a project. Openship detects the stack and generates the build.
- Run `openship deploy` to build a standard Docker container and ship it to your linked Linux server or to Openship Cloud. Preview environments, staging/prod flows, and rollbacks are available from the same dashboard.
- For Docker-first operators, clone the repo, copy `.env.example` to `.env`, and run `docker compose up -d`. Compose starts PostgreSQL, Redis, the API, the dashboard, and the web app, with the web app exposed at `http://localhost:3000`.
Product demo and interface preview
Architecture Read: Hono API, Next.js Dashboard, Drizzle ORM, and a Workspace-Driven Monorepo
Openship is a Bun-managed TypeScript monorepo. The `apps/` directory holds the runtime surfaces: `apps/api/` is a Hono API engine on port 4000, `apps/dashboard/` is a Next.js deployment dashboard on port 3001, `apps/desktop/` is the Electron desktop app and local service launcher, `apps/cli/` is the `openship deploy` tool, `apps/email/` is the email engine with a Zero server/client orchestrator, and `apps/web/` is the Next.js marketing site on port 3009 in development.
The `packages/` directory holds shared infrastructure: `packages/adapters/` for Docker, bare, and cloud runtimes; `packages/core/` for shared types, constants, utilities, and errors; `packages/db/` for the Drizzle ORM schema, client, and repositories; `packages/db-email/` for email-server Drizzle schemas; `packages/onboarding/` for shared onboarding flows; and `packages/ui/` for shared React components styled with Tailwind.
Each API module lives in `apps/api/src/modules/<name>/` and follows a four-file pattern: `<name>.routes.ts` for Hono route definitions, `<name>.controller.ts` for request handlers, `<name>.service.ts` for business logic, and `<name>.schema.ts` for TypeBox validation schemas. Shared modules — auth, projects, deployments, domains, webhooks, health — are always mounted. The `billing` module is cloud-only and only mounts when `CLOUD_MODE=true`.
Command Surface: The CLI and Bun Scripts You Will Actually Type
- `npm i -g openship` — global install; alternatively `curl -fsSL https://get.openship.io | sh`.
- `openship up` — installs Openship as a background service (starts on boot, auto-restarts); `openship up --foreground` for a one-off attached run.
- `openship open` — opens the dashboard; `openship stop` — stops the service; `openship install` — grabs the desktop app.
- `openship init` — links the current directory to a project; `openship deploy` — builds and ships the container.
- `bun db:generate` / `bun db:push` / `bun db:migrate` — generate Drizzle migration files, push schema to a dev database, or run pending production migrations; `bun run --cwd packages/db db:studio` opens Drizzle Studio.
- `bun dev:local` — starts the API and dashboard for local development; `bun dev:api`, `bun dev:dashboard`, `bun dev:web`, `bun dev:desktop`, `bun dev:email`, and `bun dev` run specific workspace dev tasks.
Try-It Path: 30 Minutes From `openship up` to a Live Domain
Fastest path: run `npm i -g openship`, then `openship up`. The installer registers Openship as a background service. Run `openship open` to reach the dashboard at the local port, then `cd your-project && openship init && openship deploy` to ship a first container.
Docker-first path: `git clone https://github.com/oblien/openship.git && cd openship`, `cp .env.example .env`, `docker compose up -d`. Compose boots PostgreSQL, Redis, the API, the dashboard, and the web app. The web app is exposed at `http://localhost:3000`.
Developer path: clone, `bun install --frozen-lockfile`, copy `apps/api/.env.example` to `apps/api/.env` and `apps/dashboard/.env.example` to `apps/dashboard/.env`, then `bun dev:local`. The dashboard runs at `http://localhost:3001` and the API at `http://localhost:4000`. Prerequisites are Bun 1.3.10 (pinned in `.bun-version` and `package.json`) and Node.js 22 or newer (see `.nvmrc`).
Maintenance Risk: Pre-1.0, Latest-Release-Only Support, and a Broad Surface Area
Openship is at 0.2.0 — a large feature and hardening release, but pre-1.0. The security policy states that only the latest release is supported; older releases are explicitly unsupported and operators are told to keep instances current. Pre-release and beta versions receive support at lower priority.
The project bundles a lot of surface area: CI/CD, a CDN edge layer on OpenResty, TLS via certbot, a mail server with DKIM/SPF/DMARC, backups, and a 15-app catalog. Each surface is an attack vector and a maintenance burden. The security scope explicitly lists managed Openship Cloud, the self-hosted control plane (API, dashboard, CLI), the desktop app, GitHub integration and webhooks, the build/deploy pipeline, backups and recovery, domains and TLS, the OpenResty edge, and mail.
Mitigations are real: the maintainers offer GitHub Private Vulnerability Reporting and a safe-harbor clause, commit to acknowledgement within 5 business days and triage within 10, and the in-app updater surfaces critical advisories from `release-advisories.json`. But the policy is a promise, not a track record — evaluate accordingly.
Who should pay attention?
Good fit if
- Solo developers and small teams who want push-to-deploy on their own Linux server without writing Dockerfiles or YAML.
- Operators who need a self-hosted mail relay with DKIM/SPF/DMARC and do not want to pay Mailgun or SES.
- Teams evaluating a Coolify or Dokku alternative that bundles TLS, CDN, backups, and a one-click app catalog.
Skip for now if
- Organizations that require Long-Term Support for older releases — Openship only patches the latest release.
- Teams that already run a mature Kubernetes stack with Argo CD and a service mesh; Openship's value is consolidated simplicity, not orchestration depth.
- Anyone who needs a stable 1.0 API contract before building internal tooling on top of the control plane.
Risks and cautions
Apache-2.0, actively shipping, and architecturally clean — but pre-1.0, latest-release-only on security, and bundling a wide surface (mail, edge, TLS, backups) that each carry their own exposure.
- Only the latest release receives security fixes; older releases are marked unsupported.
- 0.2.0 is pre-1.0, so APIs, module structure, and the app catalog may still shift.
- The bundled SMTP server, OpenResty edge, and certbot integration expand the security perimeter beyond a typical deployment tool.
- Cloud-only modules (billing) are gated behind `CLOUD_MODE=true`, which is clean, but means self-hosters must verify that cloud config never leaks into their instance.
- Apache-2.0 license — grants copyright and patent licenses for use, reproduction, and distribution.
- Private vulnerability reporting via GitHub Security Advisories or email to security@oblien.com; public disclosure is discouraged until a fix is coordinated.
- Safe-harbor clause authorizes good-faith research against your own account, self-hosted instance, or test account.
- Response targets: acknowledgement within 5 business days, triage within 10, coordinated disclosure typically within 90 days.
- Scope covers Openship Cloud, the self-hosted control plane, the desktop app, GitHub integration and webhooks, the build/deploy pipeline, backups and recovery, domains and TLS, the OpenResty edge layer, and mail.
- 0.2.0 routing changes gate certbot on verification to avoid wasted Let's Encrypt attempts and share one canonical hostname normalizer across storage, routing, and domain-service — a concrete hardening of the domain pipeline.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Coolify | You want a mature, widely adopted self-hosted platform with a larger community and similar push-to-deploy ergonomics. | Free self-hosted (open source); paid Cloud plans for managed control plane. |
Dokku | You want a minimal, Heroku-like experience on a single server with a long track record and a smaller surface area. | Free self-hosted (open source). |
CapRover | You want a one-click app catalog and cluster mode without Openship's mail server or CDN layer. | Free self-hosted (open source); paid Pro for additional features. |
Vercel / Render | You prefer a fully managed platform and do not need to self-host mail, databases, or backups on your own hardware. | Tiered SaaS pricing with free tiers; usage-based scaling. |
What this trend reveals
AI agent deployment substrate
The topics list includes `agents` and `ai`, and the one-click catalog already ships n8n, Convex, and code-server. Operators building internal AI tooling can use Openship as the deployment layer for agent runtimes, vector stores, and workflow engines on hardware they control.
Spin up Openship on a GPU-equipped Linux server, deploy the n8n and Convex templates from the 0.2.0 catalog, and measure deploy time and rollback latency against your current manual Docker workflow.
Self-hosted mail consolidation
Openship bundles an SMTP server with DKIM/SPF/DMARC and positions it as a Mailgun/SES replacement. Teams paying for transactional mail can evaluate whether consolidating deploy + mail on one self-hosted plane reduces cost and vendor count.
Deploy a low-volume transactional workload through the built-in mail server, verify DKIM/SPF/DMARC alignment with a tool like mail-tester.com, and compare deliverability and cost against your current relay over 30 days.
Contributor entry point
The monorepo uses Bun 1.3.10, Node.js 22+, TypeScript strict mode, Conventional Commits, and a clean four-file API module pattern (`routes.ts`, `controller.ts`, `service.ts`, `schema.ts`). This is a readable codebase for contributors who want to add a runtime adapter or a catalog app.
Clone the repo, run `bun install --frozen-lockfile` and `bun dev:local`, then add a new one-click app template following the existing catalog structure and submit a `feat:` branch per CONTRIBUTING.md.
RepoDaily verdict
Openship is an ambitious, well-architected self-hosted deployment platform that consolidates CI/CD, TLS, CDN, mail, and backups into one TypeScript control plane. The 0.2.0 release shows real hardening momentum and a credible one-click catalog. The main caveat is pre-1.0 maturity and a latest-release-only security posture — evaluate it for side projects, internal tooling, and AI-agent hosting now, but keep production workloads on the latest release and budget time to track advisories.