Die PaaS-Ebene

paasbox legt eine PaaS-Ebene auf einen Kubernetes-Cluster: ein Container-Image deployen und eine URL mit TLS bekommen, eine Datenbank oder einen Cache mit einer Ressource hinzufügen, und eine Preview-Umgebung pro Branch bekommen. Es ist eine Gardener-Extension, paasbox-paas, die die Operatoren installiert, die ein Cluster dafür braucht — Knative Serving fürs Serving, CloudNativePG für PostgreSQL — und zwei eigene Dinge hinzufügt: einen kleinen Controller und drei schlanke Kubernetes-Objekte, App, ManagedPostgres und ManagedValkey. kubectl ist die API; pb, ein kleines CLI, existiert nur für die paar Dinge, für die kubectl schlecht geeignet ist.

Es läuft auf einem Shoot aus deiner eigenen Gardener-Landschaft, oder auf einem Cluster, den ich für dich betreibe — die Objekte und das CLI sind in beiden Fällen dieselben.

In Entwicklung, nicht gestartet (Stand: 2026-09-16)

Diese Seite beschreibt die PaaS-Ebene so, wie sie funktionieren soll. Die Teile App, ManagedPostgres und ManagedValkey laufen heute Ende-zu-Ende auf einem lokalen Testcluster: Eine App bekommt eine URL, eine Datenbank bekommt Backups und ein Credentials-Secret, eine Preview kommt hoch und wieder runter, und ein von Hand geändertes Objekt wird zurückgesetzt. Nichts davon lief bisher in einer produktiven Gardener-Landschaft, und es gibt kein öffentliches Repository oder Release zum Installieren. Spätere Abschnitte dieser Seite beschreiben Arbeit, die im Code noch gar nicht begonnen hat. Sag Bescheid, wenn du erfahren willst, sobald etwas ausgeliefert wird.

Was du bekommst

Objekt	Was es rendert	Status
App	ein Knative Service (Typ web, Standard) mit einer URL, oder ein Deployment mit fester Replica-Zahl (Typ worker, kein Port, keine URL)	Eine App deployen
ManagedPostgres	ein CloudNativePG-Cluster mit Pflicht-Backups und einem Credentials-Secret	Datenbanken
ManagedValkey	ein Redis-kompatibler Cache oder Queue-Broker, kein Operator: der Controller rendert ihn selbst	Redis-kompatible Caches
eine Preview pro Branch	eine Kopie einer App und ihrer Abhängigkeiten, benannt nach dem Branch	Preview-Umgebungen

Alle drei tragen dieselben drei Status-Conditions — Reconciled (der aktuelle Spec wurde gerendert), Ready (das Gerenderte funktioniert), Degraded (es funktioniert, aber ein Versprechen ist gebrochen, etwa ein Backup, das nicht lief) — plus eine phase, daraus abgeleitet: Pending, Provisioning, Ready, Degraded, Suspended, Deleting oder Failed. pb status listet alle drei Objektarten in einer Tabelle.

Beide Wege: verwaltet, oder das Objekt selbst schreiben

Du bleibst Cluster-Admin. Einen Knative-Service oder einen CNPG-Cluster direkt zu schreiben, ohne App oder ManagedPostgres davor, funktioniert genauso wie auf jedem Kubernetes-Cluster, der diese Operatoren betreibt — weil es derselbe Operator ist, einmal pro Cluster installiert und geteilt. pb status listet auch deine eigenen Objekte, markiert als unmanaged: kein Plan, kein Preis, und paasbox liest oder schreibt sie nie. So verlässt du die verwaltete Form für eine Arbeitslast, ohne den Cluster zu verlassen: das schlanke Objekt löschen, das darunterliegende behalten, darunter ändert sich nichts.

Was als Nächstes kommt

Der Rest ist Design, kein Code, Stand 2026-09-16:

• Builds aus Quellcode. App.spec.image ist heute der einzige Weg — deine CI baut und pusht es. Ein Buildpacks- oder Dockerfile-Build-Schritt, der einen Source-Checkout in ein Image verwandelt, als Job auf dem Cluster ausgeführt, ist geplant, damit das Pushen eines Images optional wird.
• Eigene Domains. Jede App bekommt schon heute eine Standard-URL unter der Domain des Clusters. Eine eigene Domain auf eine App zeigen zu lassen, ist geplant.
• Workspaces. Eine browserbasierte Entwicklungsumgebung pro App — ein Editor (VS Code) und SSH, auf demselben Dateisystem, aus dem die App deployt — ist für Leute geplant, die Code ohne lokalen Checkout bearbeiten und ausführen wollen.
• Das Portal und die mobile App. Eine Web-Konsole und eine mobile Ansicht davon, was Aufmerksamkeit braucht und was ein Cluster kostet, die dieselben hier beschriebenen Objekte lesen, sind geplant; kubectl und pb verschwinden nicht, wenn sie kommen.
• Eine lokale Edition. Dieselbe PaaS-Ebene auf deinem eigenen Mac, Linux- oder Windows-Rechner, ohne Hetzner, für Entwicklung und Arbeit offline, ist geplant.

Wie es weitergeht

• Eine App deployen: Image, Skalierung auf null, Env, Abhängigkeiten, Worker, Release-Schritte, die URL und ihre Conditions.
• Datenbanken: Pläne, Versionen, Backups, Wiederherstellung in eine neue Instanz.
• Redis-kompatible Caches: ManagedValkey für einen Cache oder einen Queue-Broker.
• Preview-Umgebungen: eine pro Branch, mit eigener Datenbank und eigenem Cache.
• Beispiel: eine Django-SaaS: Web, Worker, Migrationen, Postgres und Redis zusammen.
• Das pb-CLI: jeder Befehl, was er tut, und was darunter ein einfaches kubectl apply ist.