Skip to content
GitHub

What is Kuben?

Kuben is a platform as a service that runs on your own Kubernetes cluster. You give it a container image or a GitHub repository; it gives your team an isolated environment with a public HTTPS address, zero-downtime rollouts, autoscaling, live logs, release history with rollback, and an audit log of who changed what.

It ships as one binary (or one Helm release), plus a small cluster agent that the installers set up for you. Kuben keeps its state in PostgreSQL: the Helm chart runs its own by default, kuben setup installs it on a server, and you can point Kuben at an external one instead. From there Kuben writes every project, environment and app to the cluster as ordinary Kubernetes objects, labelled and visible to kubectl.

  • Small teams on a single cluster (k3s on one server, a managed cluster in the cloud) who want Heroku-style deploys without running a second platform next to Kubernetes.
  • Platform engineers who want a thin, auditable layer over Kubernetes rather than an opinionated replacement for it. Kuben never hides the cluster: every object it creates is visible and labelled.
  • Operators who care about the boring parts: a documented security model, a threat-aware release process and honest limits.
Area Included
Deploy Any container image, or a build from a GitHub repository, with health checks, autoscaling, environment variables and write-only secrets
Isolation One namespace per environment, with resource quotas and a NetworkPolicy; preview environments per pull request
Networking Custom domains with claims, automatic certificates and HTTP → HTTPS redirects through Gateway API and cert-manager, DNS records and wildcard certificates through Cloudflare
Releases Numbered releases with rollback and emergency rollback, promotion with a diff preview, approvals for production, change freezes, paused delivery, a vulnerability scan gate, automatic image updates
Day 2 Live logs, restarts, persistent volumes, cron jobs, CPU and memory usage, the Doctor, incidents with signed webhooks, public status pages
Templates One-click PostgreSQL, Redis, MariaDB, n8n, Uptime Kuma, Vaultwarden, Gitea and more, with generated credentials
Teams Four roles, per-project roles, invitations, scoped API tokens, single sign-on (OpenID Connect), CI trust for GitHub Actions, an append-only audit log
Operations Backups, upgrades, several replicas with leader election, Prometheus metrics, kuben doctor, support bundles

Scale to zero, terminals and what else is not built yet are on the roadmap.

One process, several roles

kuben serve runs the REST API, the web console and the controllers in one process. You can run several replicas: every replica serves the API, and the holder of a Kubernetes Lease runs the controllers. A small cluster agent applies what they decide.

PostgreSQL holds the desired state

Projects, environments, apps, releases, sealed secrets, users and the audit log live in PostgreSQL. Kuben writes them to the cluster as kuben.dev resources and standard objects, and puts back what someone changed by hand.

Gateway API for the edge

Kuben creates an HTTPRoute per app and manages the listeners of a dedicated Gateway. cert-manager issues a certificate for every listener. TLS terminates at your Gateway controller (Traefik, Envoy Gateway or Cilium).

Generated, drift-checked contracts

The OpenAPI spec and the CRD manifests are frozen contracts: the server is generated from the spec, the TypeScript client too, and CI fails if a commit lets them drift or breaks the API. The REST API reference on this site is rendered from that spec.