Openship: Local-First Control, OpenResty Routing, and Native MCP for Self-Hosted Deployments

Deployments Under Your Command: Local Control, OpenResty Edge Routing, and Agent Tooling

With the release of version 0.7.1 in September 2026, delivering bounded Docker build cache growth, safe termination for stalled builds, and resilient SSH channel recovery, Openship addresses a core tension in modern developer operations. While commercial platforms extract heavy margins on compute and bandwidth, traditional self-hosted platforms often force operators to expose an always-on administrative web dashboard on the public internet. Openship circumvents that trade-off by combining a local-first desktop application, an OpenResty reverse proxy running zero-database telemetry, and native Model Context Protocol tools for autonomous developer workflows under an Apache 2.0 license.

What It Is

Openship is an open-source application deployment platform and build orchestrator. It connects to code repositories, detects runtime environments, builds container images or system processes, manages domain routing, and provisions SSL certificates on target hardware.

Architecturally, the project is structured as a TypeScript monorepo powered by Bun and Turborepo. Its core services comprise:

An API server built on Hono that exposes REST and Model Context Protocol endpoints.
A web dashboard built on Next.js 16 and React 19 utilizing Radix UI primitives and Better Auth.
A cross-platform desktop application packaged with Electron for macOS, Windows, and Linux.
An edge reverse proxy based on OpenResty that handles HTTP/3, TLS termination, Brotli compression, and in-memory traffic metrics.
A database layer managed with Drizzle ORM targeting PostgreSQL.

Unlike platforms that mandate a singular deployment paradigm, Openship functions either as a lightweight local control plane that directs servers over SSH or as an always-on team server running directly on Linux infrastructure.

Why You Have Not Heard Of It

The self-hosted deployment category has historically been dominated by Dokku, Coolify, and Dokploy. Dokku focused on single-node Git hooks without a default graphical interface, while Coolify and Dokploy built web dashboards that run directly on the managed host.

Openship emerged from maintainer Oblien with a different design philosophy. Instead of requiring developers to maintain a public-facing control plane on every server, it prioritizes a desktop-first workflow for individual builders. The project reached more than 12,000 GitHub stars and released version 0.7.1 in early September 2026 without marketing campaigns or venture capital backing. Discovery has also been clouded by name collisions with unrelated e-commerce shipping tools on open-source registries, leaving its adoption to spread primarily through word-of-mouth among systems engineers and independent developers.

How It Works

Openship splits the responsibilities of build orchestration, ingress routing, and system management across dedicated layers:

Dual Control Plane Modes: For solo engineers, the Electron desktop application acts as the control plane. It runs locally on your workstation, storing configurations locally and issuing commands to remote servers over authenticated SSH channels. The remote server requires no public-facing management port, eliminating administrative exposure. For engineering teams, running the server mode installs an always-on background service with role-based access control, invitation flows, and webhooks.
Build and Stack Detection: When pointing Openship at a Git repository or local directory, its analyzer inspects files such as package.json, lockfiles, framework configurations, and openship.json. It determines dependencies, runtime commands, and exposed network ports without requiring handwritten Dockerfiles. Each resolved deployment snapshot is frozen, ensuring that rollbacks reproduce identical artifacts.
OpenResty Edge with Microsecond Telemetry: Ingress traffic enters through OpenResty. Let’s Encrypt certificates are negotiated automatically using HTTP-01 challenges. For analytics, Openship implements a Lua logging handler inside the log_by_lua phase. This handler updates atomic in-memory counters in shared memory zones after the response has been flushed to the visitor. The monitoring system adds approximately 1.4 microseconds of overhead per request, requires zero disk input/output, and writes zero database rows during live traffic, flushing aggregated metrics to PostgreSQL every 30 minutes.
Native Model Context Protocol (MCP) Interface: In addition to standard REST routes, Openship exposes a stateless Streamable-HTTP JSON-RPC 2.0 endpoint at POST /api/mcp. AI coding assistants such as Claude Code and Codex connect directly using standards-compliant OAuth 2.1 authentication (for example, claude mcp add --transport http openship https://<host>/api/mcp) or scoped static tokens. Rather than granting unconstrained root access, Openship provides an interactive browser approval flow where operators restrict agent capabilities to specific projects, servers, or repositories with read-only or operator permissions. Every tool call re-runs the full authentication and permission stack, disallowing token leakage while allowing agents to trigger builds, inspect logs, and manage deployments safely.

Running It

Setting up Openship depends on whether you prefer local control or team collaboration.

Solo Developers: Desktop Application

Solo developers can download the compiled desktop binary for macOS, Windows, or Linux AppImage directly from the project repository:

# On Linux, download the AppImage and make it executable
chmod +x Openship.AppImage
./Openship.AppImage

Once opened, connect your remote Linux server by specifying its IP address, SSH user, and private key. The desktop app executes all container provisioning over the SSH tunnel, leaving no open administrative dashboard on the target server.

Teams: Self-Hosted Server

To run Openship as an always-on service on a Linux virtual private server, run the automated installation script:

curl -fsSL https://get.openship.io | sh
openship

The interactive wizard configures the initial administrator account, binds your custom domain, provisions the PostgreSQL database, and registers systemd background services.

For non-interactive or headless environments, deploy using direct CLI flags:

openship up --public-url https://deploy.example.com

Developers can also run the full containerized stack using the official Docker Compose configuration on Linux:

git clone https://github.com/oblien/openship.git
cd openship
cp .env.example .env
docker compose --env-file .env -f docker/docker-compose.yml up -d

This stack pulls published container images directly from the GitHub Container Registry (ghcr.io/oblien/*). The edge OpenResty container runs with network_mode: host to bind ports 80 and 443 directly, while the API container mounts /var/run/docker.sock to orchestrate application containers on the host.

What It Replaces

Vercel, Render, and Heroku: Eliminates proprietary seat charges, serverless timeout limits, and excessive bandwidth fees by deploying workloads directly onto dedicated or cloud compute instances.
Coolify and Dokploy: Offers an alternative for developers who prefer running the control plane on their own workstations via an Electron desktop app rather than exposing a web dashboard on the public internet. Furthermore, Openship includes native MCP integration out of the box for agentic AI tooling.
Dokku and Hand-Crafted SSH Scripts: Replaces brittle Bash deployment hooks and terminal-only configurations with an integrated GUI, real-time container log streaming, and automated SSL termination.

Limitations

Technical integrity requires identifying current trade-offs:

Pre-1.0 Software Lifecycle: Reaching version 0.7.1 indicates rapid development and hardening, but breaking configuration updates may occur prior to a 1.0 release. Operators should review release notes before updating critical clusters.
Push-to-Deploy Requires an Always-On Endpoint: When driving infrastructure solely from the Electron desktop client, the control plane runs only while the application is open on your workstation. Automated push-to-deploy pipelines driven by GitHub webhooks require an always-on server installation (openship up) or Openship Cloud to receive webhook events.
Mail Server Architecture in Progress: While Openship advertises integrated SMTP services, the current architecture reflects an ongoing migration toward pairing the iRedMail core (Postfix, Dovecot, Amavis) with the Zero webmail interface. Production deployments requiring mission-critical corporate email should continue using established external mail relays until the integrated stack stabilizes.
Privileged Docker Socket Access: In server mode, the API container requires access to the host Docker socket (/var/run/docker.sock) to spin up client applications. As with other container management platforms, anyone with administrative access to the API effectively holds root-level host control.
Single-Node Focus: Although multi-node clustering is on the active project roadmap, the stable release primarily orchestrates workloads on single hosts or distinct target nodes managed individually.

Who It Is For

Independent engineers and consultants who manage client applications across cost-effective cloud providers (Hetzner, OVH, DigitalOcean) and want to control infrastructure from their desktop without exposing administrative endpoints.
Development teams seeking a self-hosted PaaS with clean GitHub App integration, automated staging environments, and zero licensing restrictions.
Engineers adopting autonomous AI coding agents who need standard Model Context Protocol endpoints to automate deployment pipelines safely.

Conclusion

Openship brings fresh architectural thinking to the self-hosted deployment ecosystem. By uniting an Electron desktop client, OpenResty edge routing with near-zero overhead metrics, and native agentic MCP tooling under a pure Apache 2.0 license, it delivers an adaptable platform for developers who value sovereignty over their infrastructure.