kubenest

Deploy applications across multiple Kubernetes clusters without ever touching a raw manifest.

kubenest is a self-hosted application platform that gives your team the developer experience of a modern PaaS — one-click deploys, real-time status, environment wiring, stack templates — while running entirely on your own infrastructure. You bring the clusters; kubenest manages everything above the Kubernetes API.

Start here

How it works

kubenest spans five cooperating repositories, each with a distinct responsibility. Understanding the boundary between them explains why the system behaves the way it does.

                        ┌─────────────────────────────────┐
                        │         kubenest-ui              │
                        │   Next.js management console    │
                        └──────────────┬──────────────────┘
                                       │  REST + SSE
                        ┌──────────────▼──────────────────┐
                        │       kubenest-backend           │
                        │  FastAPI — multi-tenant control  │
                        │  plane; owns users, orgs,        │
                        │  clusters, projects, apps,       │
                        │  templates, deployments          │
                        └────────┬──────────┬─────────────┘
                                 │          │
                    PostgreSQL   │          │  WebSocket (authenticated)
                                 │    ┌─────▼──────────────────────────┐
                                 │    │         kubenest-hub            │
                                 │    │  Go — real-time message broker; │
                                 │    │  multiplexes operator sessions  │
                                 │    └─────────────┬──────────────────┘
                                 │                  │  WebSocket (per cluster)
                                 │    ┌─────────────▼──────────────────┐
                                 │    │         op3 (operator)          │
                                 │    │  Go controller-runtime;         │
                                 │    │  reconciles StackDeploy CRDs;   │
                                 │    │  drives ArgoCD on the cluster   │
                                 │    └─────────────┬──────────────────┘
                                 │                  │
                                 │    ┌─────────────▼──────────────────┐
                                 │    │          GitOps layer           │
                                 │    │  Operator writes Helm values    │
                                 │    │  → Git → ArgoCD → Kubernetes   │
                                 │    └────────────────────────────────┘
                                 │
                   ┌─────────────▼──────────────────────────────────┐
                   │              kubenest-contracts                  │
                   │  JSON Schema / event definitions — the shared   │
                   │  contract between backend, hub, and operator    │
                   └────────────────────────────────────────────────┘

The design has one key consequence: the backend never holds a kubeconfig or cluster credentials. All cluster operations flow through the hub’s WebSocket layer to the operator, which runs inside the cluster and has local Kubernetes API access. This means a compromised backend cannot issue arbitrary kubectl commands — the operator only acts on signed, schema-validated events.

Key capabilities

Multi-cluster management. Register any number of Kubernetes clusters — self-managed, cloud-provisioned, or both. Each cluster runs its own operator instance; the backend aggregates status across all of them. Per-component clusterID targeting lets a single App span multiple clusters.

App-first deployment. Apps are the unit of deployment, not individual Pods or Deployments. An App can have a web tier, a worker, a PostgreSQL addon, and a Redis addon — all deployed together, with connection strings wired automatically between components via the exportRef mechanism.

GitOps under the hood. The operator never applies Kubernetes manifests directly. Instead, it writes Helm values to a Git repository and ArgoCD reconciles the cluster state from Git. This gives you a complete audit trail, drift detection, and rollback at the Git level — without your team needing to manage ArgoCD themselves.

Stack templates. Capture a running application as a reusable template, or pull from the community registry. Templates expose typed parameter slots so users can deploy complex multi-component stacks by filling in a form — no YAML editing required.

Real-time status. The operator streams status events back through the hub to the backend, which publishes them as Server-Sent Events. The UI and any API client can watch an App’s phase transition from Pending through Deploying to Running without polling.

Pause and resume. Suspending an App snapshots its replica counts and sets all workload replicas to zero — a clean way to stop paying for compute without destroying the deployment. Resume restores the exact replica configuration.

The deployment path in three steps

Next steps

• Installation guide — Helm values, required secrets, post-install verification
• First deployment walkthrough — end-to-end tutorial with real API calls
• Apps and components — the most important concept page; covers deployment modes, export wiring, pause/resume, and rollback
• Stack templates — reusable blueprints for complex multi-component stacks