The PaaS layer

paasbox adds a PaaS layer on top of a Kubernetes cluster: deploy a container image and get a URL with TLS, add a database or a cache with one resource, and get a preview environment per branch. It is a Gardener extension, paasbox-paas, that installs the operators a cluster needs for this — Knative Serving for serving, CloudNativePG for PostgreSQL — and adds two things of its own: a small controller and three thin Kubernetes objects, App, ManagedPostgres and ManagedValkey. kubectl is the API; pb, a small CLI, exists only for the handful of things kubectl is bad at.

It runs on a shoot from your own Gardener landscape, or on a cluster run for you — the objects and the CLI are the same either way.

In development, not launched (as of 2026-09-16)

This page describes the PaaS layer as it is meant to work. The App, ManagedPostgres and ManagedValkey pieces run end to end on a local test cluster today: an App gets a URL, a database gets backups and a credentials Secret, a preview comes up and down, and a hand-edited object gets reverted. None of it has run in a production Gardener landscape yet, and there is no public repository or release to install. Later sections of this page describe work that has not started in code at all yet. Say so if you want to be told when something ships.

What you get

Object	What it renders	Status
App	a Knative Service (type web, the default) with a URL, or a Deployment with a fixed replica count (type worker, no port, no URL)	Deploy an app
ManagedPostgres	a CloudNativePG cluster with mandatory backups and a credentials Secret	Databases
ManagedValkey	a Redis-compatible cache or queue broker, no operator: the controller renders it itself	Redis-compatible caches
a preview per branch	a copy of an App and its dependencies, named after the branch	Preview environments

All three carry the same three status conditions — Reconciled (the current spec was rendered), Ready (the rendered thing works), Degraded (it works, but a promise is broken, such as a backup that has not run) — plus a phase derived from them: Pending, Provisioning, Ready, Degraded, Suspended, Deleting or Failed. pb status lists all three kinds in one table.

Both ways: managed, or write the object yourself

You stay cluster-admin. Writing a Knative Service or a CNPG Cluster directly, without an App or a ManagedPostgres in front of it, works exactly as it would on any Kubernetes cluster that runs those operators — because it is the same operator, installed once per cluster and shared. pb status lists your own objects too, tagged unmanaged: no plan, no price, and paasbox never reads or writes them. This is also how you leave the managed shape for one workload without leaving the cluster: delete the thin object, keep the upstream one, nothing changes underneath it.

What’s coming

The rest of this is design, not code, as of 2026-09-16:

• Builds from source. App.spec.image is the only way in today — your CI builds and pushes it. A buildpacks or Dockerfile build step that turns a source checkout into an image, run as a Job on the cluster, is planned so pushing an image becomes optional.
• Custom domains. Every App already gets a default URL under the cluster’s own domain. Pointing your own domain at an App is planned.
• Workspaces. A browser-based development environment per app — an editor (VS Code) and SSH, backed by the same filesystem the app deploys from — is planned for people who want to edit and run code without a local checkout.
• The portal and the mobile app. A web console and a mobile view of what needs attention and what a cluster costs, reading the same objects described on this page, are planned; kubectl and pb are not going away when they land.
• A local edition. The same PaaS layer on your own Mac, Linux or Windows machine, without Hetzner, for development and offline work, is planned.

Where to go next

• Deploy an app: image, scale to zero, env, dependencies, workers, release steps, the URL and its conditions.
• Databases: plans, versions, backups, restoring into a new instance.
• Redis-compatible caches: ManagedValkey for a cache or a queue broker.
• Preview environments: one per branch, with its own database and cache.
• Example: a Django SaaS: web, worker, migrations, Postgres and Redis together.
• The pb CLI: every command, what it does, and what is a plain kubectl apply underneath.