One controlled runtime
Target a single Linux VPS for the first release. Keep the operational model understandable before introducing distributed orchestration.
Private product · engineering showcase
Own your deploys.
Own your deploys.
Own your infrastructure.
Openship is a Vercel-like deployment experience designed for developers who want the convenience of modern application delivery while keeping the runtime on a Linux VPS they control.
CLI-firstLinux VPSDocker ComposeCaddy + Let's EncryptRollback-awarePrivate implementation
openship deploy
$ openship init ✓ project configuration ready $ openship deploy → QUEUED → BUILDING Nixpacks → BUILT → DEPLOYING Docker Compose → HEALTH_CHECKING ✓ ACTIVE logs: SSE stream connected tls: Caddy / Let's Encrypt rollback: previous known-good ready
The problem
Modern deployment UX without giving up infrastructure ownership.
Vercel and Heroku-style workflows are excellent developer experiences, but many solo developers and small teams already own a Linux VPS. Openship is designed around that constraint: make deployment simple while keeping the application, runtime and infrastructure under the operator's control.
Developer-first workflow
Use a small CLI and a declarative openship.json contract so deployment becomes a repeatable engineering workflow rather than a dashboard ritual.
Production-minded state
Model deployment as explicit states with retries, health checks, deployment locks, logs and rollback state instead of treating deployment as a single opaque command.
Product capabilities
Everything needed for the first useful deployment loop.
The current product direction focuses on a narrow, reliable core. Advanced collaboration and managed operations can sit above that core as the product matures.
CLI-first deployment
Initialize, configure, deploy, inspect logs and manage deployment state without making the dashboard the primary interface.
Nixpacks + Dockerfile
Nixpacks is the preferred build path, with a Dockerfile fallback for applications that need explicit runtime control.
HTTPS by default
Caddy handles reverse proxying and Let's Encrypt certificate automation for application domains.
Rollback
Keep the previous known-good deployment available so a failed health check can return the service to a working state.
Live logs
Stream deployment progress over SSE and make the same evidence visible in the dashboard and operational tooling.
Background jobs
BullMQ and Redis separate build/deploy work from the control plane and make retries and queue state explicit.
Private registry
Use a local/private registry model so built images remain under the operator's infrastructure boundary.
Health-aware state machine
QUEUED → BUILDING → BUILT → DEPLOYING → HEALTH_CHECKING → ACTIVE, with rollback on failure.
Secrets & backups
Keep secrets handling and scheduled backup retention as first-class operational concerns rather than afterthoughts.
Architecture
A deliberately simple control plane over a single-server runtime.
The engineering handoff specifies Fastify, Next.js 14, BullMQ, Redis, Prisma with SQLite initially, Docker Compose, Caddy and a set of independently testable processors.
Control plane
Next.js DashboardProject, deployment and logs UI
↓
Fastify APIAuth, projects, deployments, state
↓
BullMQ + RedisQueued build and deployment work
↓
Workers / processorsBuild · deploy · proxy · mail · backup
JWT + API keysPrismaSQLite v1SSEStructured logs
Runtime plane
Git sourceApplication repository
↓
NixpacksPreferred build path
↓
Private registryLocal image storage
↓
Docker ComposeApplication deployment
↓
CaddyRouting + Let's Encrypt
Linux VPSRollbackHealth checksCleanupDaily backups
Security boundary: build workers require careful isolation because container builds can require Docker daemon privileges. The implementation should document and constrain this trust boundary rather than casually exposing the host Docker socket to application workloads.
Deployment lifecycle
Evidence-driven deployment instead of “it probably shipped.”
Every state is designed to be observable, testable and recoverable. This is also how the engineering workflow validates the product: execute, validate, capture evidence, then continue.
01 · Queue
Accept the deployment request, establish an idempotent job and acquire the deployment lock.
02 · Build
Resolve the build strategy, produce the application image and push it to the private registry.
03 · Deploy
Materialize the deployment through Docker Compose while preserving the previous known-good state.
04 · Verify
Run health checks and expose live progress through structured logs and SSE.
05 · Recover
If verification fails, roll back to the previous known-good deployment and record the resulting state.
Product direction
Open core where trust matters. Paid operations where convenience matters.
The intended commercial direction is to keep the deployment engine approachable for developers while creating room for managed collaboration, observability and infrastructure operations.
Self-hosted core
CLI, deployment engine, build processors, Docker Compose runtime, Caddy, basic dashboard and single-server workflow.
Operational layer
Multi-server management, RBAC, advanced logs, monitoring, managed backups, richer deployment history and team workflows.
Governed infrastructure
Organization controls, SSO, audit capabilities, policy enforcement, support and larger infrastructure management workflows.
Portfolio showcase
Openship is currently a private product implementation.
This page intentionally exposes the product story and non-sensitive architecture while keeping the implementation private. Public repository links and one-click deployment can be added when the release boundary is ready.