DEV Community

Cover image for One Open Source Project a Day (No. 183): Openship — Vercel-Level Deploy Experience on Your Own Server
WonderLab
WonderLab

Posted on

One Open Source Project a Day (No. 183): Openship — Vercel-Level Deploy Experience on Your Own Server

#opensource #openship #selfhosted #cicd

Introduction

"Deploy anything. Own everything."

This is the 183rd article in the "One Open Source Project a Day" series. Today's project is Openship.

Vercel's developer experience is genuinely excellent — push code, and a few minutes later your app is live with SSL, routing, and previews handled automatically. But it has one fundamental problem: your application runs on someone else's servers, pricing is entirely up to the vendor, a traffic spike can blow up your bill, and if you want to leave you have to migrate everything out.

The alternative is running Docker yourself — full control, but SSL, CI/CD, domain routing, databases — everything needs manual setup. High floor.

Openship sits between the two: Vercel-level operating experience, but the application runs on your own server. Push code, it builds a Docker image locally, transfers it over SSH, and OpenResty takes over routing and TLS. Your server, your data, your bill.

12.3k Stars, Apache 2.0, completely free to self-host.

What You Will Learn

  • Openship's three deployment modes (desktop app / self-hosted server / Openship Cloud)
  • The "build locally, deploy remotely" architecture and why it matters
  • How Openship positions itself against Vercel/Netlify and Coolify/Dokploy
  • The built-in services bundle: databases, mail server, object storage, backups
  • Why "containers keep running after you delete a project" is a significant design decision

Prerequisites

  • Basic understanding of Docker
  • Some experience deploying a web application
  • Optional: familiarity with SSH and reverse proxies

Project Background

What It Is

Openship is an open-source, self-hosted PaaS (Platform as a Service). It replicates the operational experience of commercial PaaS platforms (Vercel, Railway, Render) on your own infrastructure.

The core promise is no vendor lock-in: Openship is built on open standards — Docker, OCI images, S3 protocol, SMTP, ACME (the Let's Encrypt certificate automation protocol). If you ever want to walk away from Openship, your containers, databases, and images are all in standard formats and can be migrated anywhere.

One particularly notable design: when you delete an Openship project, the containers on your server keep running. This is the opposite of most PaaS platforms, where deleting a project makes your deployment disappear.

Author / Team

Project Stats

  • ⭐ GitHub Stars: 12,300+
  • 🍴 Forks: 1,100+
  • 📄 License: Apache 2.0 (free including commercial use)
  • 🌐 Website: openship.io

What It Does

The Problem It Solves 

Option A: Commercial PaaS (Vercel / Netlify / Railway)
  ✅ Push-to-deploy, excellent experience
  ✅ SSL / routing / CI fully automated
  ❌ App runs on vendor servers — no data sovereignty
  ❌ Traffic spikes = bill spikes
  ❌ Migrating away means moving everything

Option B: Roll your own Docker + Nginx + CI stack
  ✅ Full control, data stays with you
  ❌ SSL certs, reverse proxy, CI/CD, databases — all manual
  ❌ Everything needs individual maintenance

Option C: Openship
  ✅ Push-to-deploy (same experience as Vercel)
  ✅ SSL / routing / databases / email all built in
  ✅ App runs on your server
  ✅ Built on open standards — walk away anytime
  ✅ Self-hosting is completely free
Enter fullscreen mode Exit fullscreen mode

Three Ways to Run It

Mode 1: Desktop App (solo developers)

Download the macOS / Windows / Linux desktop client. The control plane runs locally. It manages remote servers over SSH — no agent installation on the server, no control console exposed to the public internet.

Best for: personal projects, side projects, not wanting to maintain extra infrastructure.

Mode 2: Self-Hosted Server (teams)

curl -fsSL https://get.openship.io | sh
openship   # interactive wizard walks through setup
Enter fullscreen mode Exit fullscreen mode

Run the control plane on a server. Team members collaborate through the web dashboard.

Mode 3: Openship Cloud (zero maintenance)

Managed service starting at $10/month. You don't maintain the control plane, but the deployment target can still be your own servers (hybrid mode).

The Deployment Flow 

1. Connect your repository (GitHub / GitLab / Bitbucket)

2. Push code
   ↓
3. Openship detects your stack (Node / Python / Go / …)
   ↓
4. Builds a Docker image on the local machine (not the production server)
   ↓
5. Transfers the image to the target server over SSH
   ↓
6. Container starts on the server
   ↓
7. OpenResty takes over routing + Let's Encrypt provisions SSL automatically
   ↓
App is live ✓
Enter fullscreen mode Exit fullscreen mode

The key design point: building happens on the machine running the Openship console, not on the production server. Production server resources aren't consumed by the build process, and a build failure doesn't affect anything running live.

Supported Stacks

Language / Runtime Databases Other Services
Node.js PostgreSQL Object storage (S3-compatible)
Python MySQL Built-in mail server (SMTP)
Go MongoDB Scheduled backups
Rust Redis Let's Encrypt SSL
PHP Custom domains
Ruby Private networking
Java DDoS protection
.NET

The Built-In Services Bundle

This is where Openship pulls ahead of many comparable tools — no third-party service integrations required:

Built-in mail server: Full SMTP service with DKIM/SPF/DMARC support. No Mailgun or SendGrid subscription needed.

Built-in databases: Postgres, MySQL, MongoDB, Redis — one-click creation with automatic backups.

Scheduled backups: Automatic backups on a schedule, with one-click restore.

SSL certificates: Let's Encrypt automatic provisioning and renewal, with wildcard domain support.

Interfaces

Interface Best For
Desktop app (Mac/Windows) Solo developers, local control
Web dashboard Team collaboration, browser access
CLI Scripting, DevOps pipelines
REST API Programmatic integration
MCP endpoint AI agent calls (Claude Code, etc.)

A Deeper Look

The Value of "Build Locally, Ship Remotely"

Most self-hosted deployment platforms (Coolify, Dokploy, Caprover, etc.) build on the target server: pull code to the server, run the build process on the server.

Openship inverts this: builds run on the machine hosting the Openship console, and the resulting Docker image is transferred via SSH to the target server.

Coolify / Dokploy model:
  Code → target server (pull + build + run)
  ↑ Build process competes with live services for CPU/RAM
  ↑ Build failure can destabilize the server running production

Openship model:
  Code → console machine (build) → SSH transfer → target server (run only)
  ↑ Build and runtime are physically separated
  ↑ Target server resources are 100% for live traffic
  ↑ Build failures don't touch production
Enter fullscreen mode Exit fullscreen mode

On a resource-constrained VPS (say, a 2-core 4GB Hetzner box), this architectural difference is significant — the same hardware delivers more stable live service performance with Openship's model.

The OpenResty Routing Layer

Openship uses OpenResty (Nginx + Lua extensions) as its edge proxy, handling three things:

  1. HTTP routing: mapping domains to the correct containers
  2. TLS termination: Let's Encrypt certificate provisioning, renewal, and HTTPS handling
  3. Zero-downtime cutover: traffic only shifts from old to new container once the new one is healthy

There's a notable design detail about the sequencing of TLS and routing: routing and TLS take over after the application container is already running. This means if DNS resolution or certificate provisioning encounters an issue, it surfaces in the console as "action required" rather than failing the entire deployment and rolling back — which makes root-cause debugging far easier.

Competitive Positioning

Where Openship sits on the landscape:

Commercial PaaS (Vercel / Railway / Render)
  ↑ Easiest experience, most expensive, no data sovereignty

Self-hosted PaaS (Coolify / Dokploy / Caprover)
  ↑ Self-controlled, free, but fewer built-ins, no desktop client

Openship
  ↑ Among self-hosted PaaS options: richest built-in services
     (mail server, backups, object storage)
  ↑ The only self-hosted PaaS with a desktop client
  ↑ The only self-hosted PaaS with an MCP endpoint
  ↑ Local-build architecture

Raw Docker + Nginx + CI DIY
  ↑ Most flexible, highest floor
Enter fullscreen mode Exit fullscreen mode
Dimension Vercel Coolify Dokploy Openship
Data sovereignty ❌ ✅ ✅ ✅
Push-to-deploy ✅ ✅ ✅ ✅
Built-in mail server ❌ ❌ ❌ ✅
Desktop client ❌ ❌ ❌ ✅
MCP endpoint ❌ ❌ ❌ ✅
Local-build architecture ❌ ❌ ❌ ✅
Containers survive project deletion ❌ ❌ ❌ ✅
Free to self-host — ✅ ✅ ✅
Stars — 40k+ 15k+ 12.3k

Why "Containers Survive Project Deletion" Matters

This design decision is a direct expression of Openship's core philosophy: the platform is a tool, not a chain.

On Vercel, your deployment lifecycle is bound to the Vercel platform — delete a project, the deployment is gone, with no separation between them.

Openship's logic: your containers run on your server. Openship manages them; it doesn't own them. Delete the project configuration in Openship, and the containers on your server keep running. You can operate them with standard Docker commands, or re-import them into Openship management later.

This makes migrating or switching platforms nearly risk-free — the worst-case scenario is "back to manual management," not "service disappears."

Project Links and Resources

Official Resources

Related Resources

  • Coolify — 40k Stars, the most feature-complete self-hosted PaaS alternative
  • Dokploy — 15k Stars, lightweight self-hosted deployment platform
  • OpenResty — The Nginx + Lua platform powering Openship's routing layer

Summary

Key Takeaways

  1. Local-build architecture: builds happen on the control console machine; the production server only runs containers — resources are separated
  2. Built-in services bundle: databases, mail server, object storage, backups — no third-party service subscriptions required
  3. Desktop client: solo developers can manage remote deployments over SSH without deploying an additional server
  4. Delete = detach, not delete = destroy: the platform manages your containers; it doesn't own them
  5. MCP endpoint: AI agents can call Openship directly to trigger deployment operations

Who This Is For

  • Developers tired of Vercel bills: want the same experience but with the app running on their own VPS
  • Home server / VPS tinkerers: want a full PaaS experience instead of pure manual Docker ops
  • Data-sovereignty-conscious teams: not willing to put build artifacts and databases on a third-party platform
  • AI application developers: need to let an Agent automatically trigger deployment pipelines via MCP

One-Line Verdict

Openship unpacks a classic contradiction: you want Vercel's experience, but not Vercel's bill or vendor lock-in — it separates the two.

Check out PrimeSkills — a curated marketplace of AI agents and skills that have been validated in real-world, enterprise-grade workflows. No fluff, just what actually works.

Find more useful knowledge and interesting products on my Homepage

Top comments (0)