All work01 / Deployment infrastructure

Openship

From source to a running system.

Openship is an open-source deployment platform built at Oblien. It brings application builds, runtimes, domains, and operational feedback together, with support for self-hosted infrastructure.

Context
Previous work at Oblien
Engineering scope
Deployment & domain infrastructure
Built with
TypeScript · Next.js · Hono · Docker · PostgreSQL
Authentic Openship deployment configuration showing framework selection, build settings, runtime, and domain controls.
Openship's public product screenshot. Image: Oblien / Openship, Apache-2.0.

01Context

Deployment is more than a build.

A successful build still needs a runtime, routing, a domain, and a certificate. Openship connects those steps across Docker, remote servers, and other supported deployment environments.

One concrete edge case appears when an application is ready before its custom domain points to the server. That timing becomes an infrastructure concern rather than something a user should have to solve by redeploying.

02Approach

Separate readiness from verification.

The runtime is prepared while a custom domain awaits DNS verification. Certificate issuance stays gated on verification, while a background task continues checking the domain.

Once verification succeeds, the platform can finish the HTTPS lifecycle for the existing deployment.

03Architecture

A control plane, with explicit boundaries.

The project combines a Next.js dashboard and TypeScript/Hono API with runtime adapters. Docker and SSH deployment paths sit behind the orchestration layer; PostgreSQL/Drizzle and embedded PGlite serve the supported storage modes.

OpenResty handles ingress routing. Let's Encrypt certificate provisioning is coordinated with domain state, so application readiness and certificate readiness can progress independently.

04Implementation

Close the whole domain lifecycle.

The domain lifecycle coordinates verification, persisted certificate state, issuance locks, and retries. These details let a delayed DNS change progress through the same deployment flow.

Prepare early
Set up the certificate tooling when the runtime is created, including pending custom domains.
Verify in the background
Continue DNS checks and trigger provisioning when the domain becomes ready.
Coordinate issuance
Persist certificate state and use a shared locking path around issuance work.

05Tradeoffs

External state needs patient handling.

DNS propagation is outside the application's control. Treating it as a separate state avoids coupling every domain change to a fresh deployment, but requires careful background jobs, retries, and consistent routing behavior.

06Outcome

A recoverable path to HTTPS.

The published implementation supports deferred custom-domain verification and certificate completion without requiring a new deployment. Its regression coverage addresses pending domains, routing behavior, and automatic SSL completion.

The linked contribution provides a concrete view of the engineering work, from the state transitions to the checks around them.

Sources & further reading

Previous professional work at Oblien, developed within the Openship product team.

Next case study / 02Rwaq LMS

A good place to begin

What are you
building next?

A new product, a difficult system,
or a considered next step.

Start a project