A cloud-native platform for deploying and operating open-source applications through automated Kubernetes infrastructure.
Deploying a self-hosted application well requires provisioning compute, generating manifests, wiring ingress and TLS, and reconciling that state continuously — work most small teams repeat by hand for every tenant, every time.
Manual provisioning does not scale past a handful of tenants, and doing it synchronously inside an HTTP request creates fragile, non-resumable deployments with no clear audit trail of what state the cluster is actually supposed to be in.
Sole engineer and founder — architecture, backend implementation, infrastructure automation, and operations were designed and built independently.
The API accepts a request and persists desired state to MongoDB. A queued job hands the work to a provisioning worker, which generates Kubernetes manifests and pushes them to a Git repository. FluxCD reconciles the cluster continuously against that repository — the source of truth is Git, not any single running process.
Socket.IO streams job and reconciliation status back to the client in real time.
Provisioning involves multiple slow, failure-prone steps. Running them inside an HTTP request ties deployment reliability to a single request lifetime — a queue lets work be retried, inspected, and resumed independently of any client connection.
Git gives desired state a version history, a diff, and a rollback path for free. FluxCD reconciling against Git means the cluster is always being pulled back toward a known-good, auditable state rather than drifting from imperative commands.
BullMQ provides retries, backoff, and job status out of the box on top of Redis, which was already in the stack for caching — avoiding a heavier message broker for a workload that is bursty rather than constant.
Provisioning can take seconds to minutes. Clients need live status — queued, working, reconciling, healthy — without polling an endpoint repeatedly; a persistent socket connection made that status feel immediate.
Reconciliation loops are more resilient than imperative deploy scripts — when Git is the source of truth, a failed or interrupted deployment self-heals on the next reconcile instead of requiring manual recovery.
The hardest part of building OpenHost wasn't Kubernetes — it was designing state that could be safely inspected, retried, and reasoned about by someone other than the process that created it.