Roadmap

Kuben 2.0 is Kuben rewritten in Go. It keeps what 1.2 does, with the same REST API, custom resources, configuration keys and command line, so 2.0 is about the engine, not new features. This page says what ships today, how 2.0 becomes the stable release, and what is not built yet.

What ships today

Both 1.2 and the 2.0 pre-releases do all of this:

• Deploy any container image, or build it from a GitHub repository in isolated BuildKit Jobs (Dockerfile or Railpack), with health checks, autoscaling, scheduled jobs, persistent volumes and write-only secrets sealed with a keyring.
• Deliver through the cluster agent, a small process in the cluster that applies what Kuben sends it over mutual TLS.
• Isolate every environment in its own namespace with quotas and a NetworkPolicy.
• Expose apps on custom domains with automatic certificates through Gateway API and cert-manager, with domain claims, and with DNS records and wildcard certificates through Cloudflare (DNS-01).
• Release safely: numbered releases, rollback, emergency rollback, promotion with a diff preview, approvals for production, change freezes, paused delivery, a vulnerability scan gate, and automatic image updates.
• Preview every pull request in its own environment.
• Operate: live logs, the Doctor with its evidence graph, CPU and memory usage, incidents with signed webhooks and alert silences, public status pages, owners with runbooks, a backup before every upgrade, kuben doctor and kuben support-bundle.
• Teams: four roles, roles per project or environment, scoped API tokens, single sign-on with OpenID Connect, CI trust for GitHub Actions (no stored secret), and an append-only audit log.
• Install with one command on a server (k3s included) or with Helm; several replicas run side by side on PostgreSQL.

2.0 adds a redesigned console: a home dashboard, the app page in tabs, and pages for settings, domains, incidents and webhooks, with the controls for owners, freezes, silences, paused delivery and emergency rollback.

Coming in 2.1 unreleased

In development, not in a release yet. 2.1 only adds to 2.0: one database migration, new API operations and CLI commands, nothing existing changes.

• Git providers. Connect GitHub (by token), GitLab (gitlab.com or self-hosted), Gitea or Forgejo to an organization with an access token, checked before it is saved and sealed with the keyring; browse repositories and branches, connect an app to a repository and branch from the console, and deploy on push through a webhook per connection. See Git providers.
• Organization registries. One registry login for every environment, with presets for Docker Hub, GHCR, GitLab, Quay and Harbor, a live test, rotation, and pull secrets bound automatically; an environment’s own login still wins. See Container registries.
• Commit statuses (kuben/build) on GitHub, GitLab and Gitea/Forgejo commits for builds through a connection, and GitLab projects in subgroups.
• Build logs and stages. The log of every build, live while it runs and kept afterwards, a stage timeline, Build now, live updates on the Builds tab, and kuben builds. See Builds.

The 2.0 release train

2.0 becomes stable in four steps. Each one is a tag on GitHub, and nothing moves to the next step while a serious bug is open.

Stage	What it is for	What it promises
2.0.0-alpha.N	Trying 2.0 early	A test cluster with a fresh database, or a copy of a 1.2 database. No upgrade guarantee.
2.0.0-beta.N	Staging and volunteers	Feature-complete. Upgrading a 1.2.x installation in place, and going back, is tested.
2.0.0-rc.N	Rehearsing the switch	Bug fixes only. Seven days in a row without a serious bug; each fix starts a new rc.
2.0.0	Everyone	The last rc’s commit, tagged again, not rebuilt.

Until 2.0.0 is out:

• The default install stays on 1.2.x. Pre-releases never become GitHub’s latest release, the image’s latest tag or Helm’s default chart version, so install.sh and helm install without a version keep installing 1.2.x.
• You try 2.0 by naming it: --version v2.0.0-alpha.N for the installer, --version 2.0.0-alpha.N for Helm.
• 2.0.0 adds no database migration, so going back from 2.0.0 to 1.2.x is swapping the image.
• 1.2 is to get security fixes for six months after 2.0.0.

Not built yet

These are real gaps in the code today. The order in which they close depends on what users need most; see below.

Next for Git and builds next

• Sign in to Git providers with OAuth (GitHub, GitLab, Gitea) to create a connection without copying a token.
• Previews for GitLab merge requests and Gitea/Forgejo pull requests. Previews are GitHub App only today.
• Build caches shared between builds of an app, and build secrets.

Other big gaps planned

• Managed databases: PostgreSQL, MySQL and Redis as one-click services with backups, instead of a template and a volume.
• Metrics and alerts per app beyond CPU and memory: request rates, latency and error rates, with alert rules.
• Terminals and scale to zero, below.

In the console

Some things work through the API but have no page yet: environment approval policies, vulnerability exceptions, and roles for one project or environment. Deployments waiting for approval are approved or rejected on the app’s Deployments tab. (Setting an app’s Git source and reading build logs get pages in 2.1.)

Scale to zero planned

Idle apps stop and the first request wakes them, through the activator role. The role and the idle field of the App resource are reserved; the activator itself is not built, and selecting the role only logs a warning.

Also missing

• High availability with the cluster agent. Several replicas work, but with the agent, one replica is best for now.
• Terminals into a running pod.
• Two-factor sign-in or passkeys of Kuben’s own. Today, use single sign-on with your provider’s MFA.
• More DNS providers. DNS-01 and DNS records are Cloudflare only.
• Separate service accounts for the API and the controller roles, with narrower RBAC each.
• ListenerSet support to go beyond 60 hostnames per Gateway.
• Signed anchoring of the audit log.
• A formal threat model to accompany the security model.

Non-goals

• Replacing Kubernetes’ own tooling. Everything Kuben creates stays visible with kubectl, and an app can be exported and detached to be managed without Kuben.
• Multi-cluster management in the near term. One Kuben installation manages one cluster.
• A hostile-tenant sandbox. Environments isolate teams from each other’s mistakes, not adversaries.

Influence the order

Vote with a thumbs-up on the issues labelled roadmap, or open a feature request with the problem you are trying to solve.