Openship Multi-Target Architecture: Unifying Cloud, Self-Hosted, and Desktop Deployments

Openship's multi-target architecture unifies cloud, self-hosted, and desktop deployments under a single TypeScript control-plane that executes a five-stage pipeline—detect, build, run, route+secure, and push-to-deploy—regardless of your hosting target.

Openship is an open-source, self-hostable platform that bundles CI/CD, edge routing, and infrastructure automation into a monorepo structure. Its multi-target architecture enables the same control-plane to deploy applications from your local desktop, a private server, or the managed Openship Cloud without changing your workflow.

The Five-Stage Deployment Pipeline

Openship implements a pipeline-driven model that remains consistent across all deployment targets. The control-plane, written in TypeScript and packaged with Drizzle ORM and SQLite, orchestrates five distinct stages according to the repository source code:

Detect

In the detect stage, Openship reads package.json, framework configurations, lockfiles, or an openship.json manifest to infer the build stack, package manager, start command, and exposed port. This automated detection eliminates manual configuration for standard frameworks.

Build

The build stage compiles the application into either a Docker image (Compose mode) or a bare binary (bare mode). The resolved configuration is frozen into a snapshot for repeatable deployments, ensuring immutable infrastructure across cloud and self-hosted environments.

Run

During the run stage, Openship executes the artifact as either an isolated container bound to loopback or a supervised host process. This flexibility allows the same binary to run on a developer's desktop or in production without modification.

Route and Secure

An OpenResty edge instance defined in packages/adapters/src/infra/openresty-lua.ts automatically provisions reverse-proxy vhosts and obtains Let's Encrypt certificates via HTTP-01 challenge. The Lua scripts handle TLS termination and routing only after the application is healthy, surfacing DNS or certificate issues as "action required" states without breaking active deployments.

Push-to-Deploy

The pipeline completes with automatic redeployment via GitHub webhooks. When code is pushed to a tracked branch, Openship rebuilds only changed services and re-executes the pipeline, enabling true CI/CD on self-hosted servers and cloud instances alike.

Three Deployment Targets

The control-plane adapts to three distinct shapes based on your operational requirements:

Desktop Application

For solo operators, Openship runs as a native desktop application with no public surface area. The control-plane lives on your laptop and drives remote servers over SSH. This configuration uses the Electron-based desktop client configured in apps/desktop/tsconfig.json, providing real-time logs and one-click actions for private workflows.

Self-Hosted Server

For teams requiring always-on CI/CD, Openship runs as a background service on Linux via Docker Compose or bare mode. This shape exposes public URLs for the dashboard and webhook receiver, enabling push-to-deploy from GitHub. Installation instructions in docs/installation.md cover both Docker Compose and bare-metal setups.

Openship Cloud

The zero-ops option provides a fully managed, auto-scaling instance hosted by the Openship team. This cloud target runs the same five-stage pipeline as self-hosted instances but requires no infrastructure management or manual updates.

Unified Interfaces

Regardless of deployment target, Openship exposes multiple interfaces that connect to the same backend:

Desktop GUI

The native desktop application provides real-time logs and one-click deployment actions. It connects to the same control-plane used by the web interface but operates entirely locally without exposing public endpoints.

Web Dashboard

Served from apps/web/next.config.mjs, the web dashboard offers identical functionality to the desktop client but runs in a browser. This interface is ideal for team collaboration on self-hosted or cloud instances.

CLI and Programmatic APIs

The apps/cli/package.json defines scriptable commands for CI pipelines and automation tasks. Additionally, MCP (Machine-Control-Protocol) endpoints and a REST API expose functionality for programmatic integration, with permission checks enforced on every call according to the source in README.md.

Extending the Architecture

Because Openship is structured as a monorepo, every component can be swapped or extended:

• Docker Compose: The raw stack in docker/docker-compose.yml pulls ready-made images from ghcr.io/oblien/*, including Postgres, Redis, and the OpenResty edge.
• Database Schema: Drizzle ORM configurations in packages/db/drizzle.config.ts manage migrations and schema definitions for the embedded control-plane database.
• Edge Routing: Custom Lua scripts in packages/adapters/src/infra/openresty-lua.ts power the reverse-proxy and TLS automation logic, allowing custom routing rules.

Getting Started with Openship

Install the CLI and deploy your first application:

# Install the CLI globally

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

# Initialize a project configuration

openship init

# Deploy (auto-detects stack, builds image, starts container)

openship deploy

# View live logs

openship logs $(openship deployment list -q) -f

For a self-hosted server with public access:

openship up --public-url https://ops.example.com --managed-edge

To run the raw Docker Compose stack without the CLI:

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

Summary

• Openship's multi-target architecture unifies desktop, self-hosted, and cloud deployments through a single TypeScript control-plane.
• The five-stage pipeline (detect → build → run → route+secure → push-to-deploy) remains consistent regardless of hosting target.
• Three deployment shapes (desktop, self-hosted server, cloud) adapt to solo operators, teams, or zero-ops requirements.
• Multiple interfaces (desktop GUI, web dashboard, CLI, REST API) provide flexibility without configuration drift.
• Source files including docker/docker-compose.yml, packages/adapters/src/infra/openresty-lua.ts, and apps/cli/package.json demonstrate the extensible monorepo structure.

Frequently Asked Questions

What infrastructure services does Openship include?

Openship bundles Postgres, Redis, mail delivery, backups, CDN capabilities, and an OpenResty edge for TLS termination and routing. These services are defined in docker/docker-compose.yml and can be deployed as a complete stack or integrated with existing infrastructure.

Can I use Openship without installing the desktop application?

Yes. The self-hosted server and Openship Cloud targets provide web dashboards accessible via browser, while the CLI (apps/cli/package.json) enables scriptable deployments from any terminal. The desktop application is optional and intended for solo developers managing private workflows.

How does Openship handle TLS certificates on self-hosted servers?

Openship uses an OpenResty edge instance (packages/adapters/src/infra/openresty-lua.ts) to automatically provision Let's Encrypt certificates via HTTP-01 challenge. Routing and TLS termination occur only after the application passes health checks, preventing deployment failures from certificate issues.

Is the database schema customizable in self-hosted deployments?

Yes. Openship uses Drizzle ORM with SQLite for the control-plane database. Schema definitions live in packages/db/drizzle.config.ts and can be extended or modified when building from source, though the default configuration requires no manual database setup.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}