Wo KI-Agenten deine Anwendungen sicher und zuverlässig betreiben.

PaaSbox ist eine Sammlung von Werkzeugen und Diensten für KI-gestütztes Deployment und den Betrieb von Anwendungen auf Hetzner, auf Servern, die du selbst mietest. Heute ist es eine Sammlung offener Komponenten, deren Veröffentlichung vorbereitet wird, und ein bezahltes Produkt, PaaSbox Clusters: Software as a Service, die kleine, isolierte k3s-Cluster in deinem eigenen Hetzner-Projekt anlegt und pflegt, für Produktion und Nicht-Produktion. Es ist im Labor Ende-zu-Ende gelaufen und noch nicht buchbar.

Sag mir, wenn PaaSbox Clusters buchbar istZur Doku

Die Produktlinie, in dieser Reihenfolge

1. 1Offene KomponentenKostenlos
   Apache-2.0 · die Node-Images veröffentlicht, der Rest in VorbereitungIn Arbeit
2. 2PaaSbox Clusters29 €/Monat
   inkl. MwSt. · SaaS · ein Node · im Labor gelaufen, noch nicht buchbarIn Arbeit
3. 3ownpaas
   Laborumgebung und Control Panel, späterGeplant
4. 4Cloud Viewer
   die App ist fertig; Kopplung mit dem PortalIn Arbeit

Gebaut läuft Ende-zu-Ende in einem Labor. In Arbeit ist begonnen, nicht fertig. Geplant ist entworfen, nicht gebaut.

Was es ist

Was PaaSbox ist

Jede Aussage auf dieser Seite trägt ihren Status. Gebaut läuft Ende-zu-Ende in einem Labor auf einem echten Cluster, nicht veröffentlicht. In Arbeit ist begonnen, aber nicht fertig. Geplant ist entworfen, aber nicht gebaut.

Offene KomponentenIn Arbeit

Die Bausteine für Kubernetes auf Hetzner mit Cluster API und k3s, die Plattform darauf, die PaaS-Ebene (App, ManagedPostgres, ManagedValkey), der Katalog und die Leitplanken. Gebaut und gemessen; Apache-2.0. Die Repositories werden vorbereitet und in Wellen veröffentlicht; die Node-Images sind schon veröffentlicht.

PaaSbox ClustersIn Arbeit

Software as a Service für k3s-Cluster in deinem eigenen Hetzner-Projekt, Control Plane eingeschlossen: das Portal, der Agent auf dem Node, signierte Releases und die Add-ons. Server, Cluster und Verfügbarkeit gehören dir. Geplant sind 29 € inkl. MwSt. pro Cluster und Monat, ein Node. Am 2026-10-10 im Labor Ende-zu-Ende gelaufen; noch nicht buchbar.

pbx-agent auf deinem NodeGebaut

Ein kleines Programm auf dem Server, kein KI-Modell. Er lauscht auf keinem Port, ruft das Portal über ausgehendes HTTPS auf und führt eine feste Liste von Operationen aus, nie beliebige Befehle. Im Labor hat er jede davon auf echten Hetzner-Servern ausgeführt.

Upgrades mit Weg zurückGebaut

Nach einem Snapshot, sofort oder in deinem Wartungsfenster. Im Labor hat ein Upgrade das Image des Nodes in 83 Sekunden an Ort und Stelle ersetzt; der Server startete neu, und die API war 34 Sekunden lang nicht erreichbar. Das Warten auf das Fenster und das vorige Image wieder zu starten, wenn der Node nicht gesund zurückkommt, sind In Arbeit.

Snapshots in deinen BucketGebaut

Snapshots des Cluster-Zustands gehen vom Node direkt in deinen eigenen S3-Bucket, nie über das Portal. Im Labor dauerte eine Wiederherstellung an Ort und Stelle 160 Sekunden, mit unversehrten Daten in den Volumes. Eine Wiederherstellung auf einen neuen Server ist Geplant.

DNS-Namen für deine ClusterGebaut

Ein kostenloser Name unter <team>.paasbox.app für deine Cluster, mit den Einträgen, die Let’s Encrypt braucht, nach einer Anmeldung. Die API ist gebaut; der Dienst öffnet mit der ersten Veröffentlichung der Komponenten.

So funktioniert es

So funktioniert PaaSbox Clusters

Gebaut Im Labor, auf echten Hetzner-Servern, am 2026-10-10. Das Portal legt den Cluster mit deinem API-Token in deinem Hetzner-Projekt an. Der Agent auf dem Node öffnet jede Verbindung zum Portal; das Portal verbindet sich nie mit deinem Server. Snapshots gehen vom Node direkt in deinen Bucket.

Root auf dem Server, der Cluster und seine Verfügbarkeit bleiben bei dir. Es taugt für Produktion und Nicht-Produktion; Produktion heißt hier ein Node, mit drei Dingen, die du akzeptierst: Es gibt kein SLA, ein Upgrade startet den Node neu (34 Sekunden ohne API im Labor), und auf einen kaputten Node antworten eine Wiederherstellung aus einem Snapshot oder ein Neuaufbau. Ist das Portal nicht erreichbar, läuft der Cluster weiter, und die geplanten Snapshots laufen auch. Jedes Teil und sein Status →

Sicherheit

Was das Portal verwahrt

Gebaut Im Labor, so gebaut für PaaSbox Clusters; das Portal ist noch nicht live.

Nur, was es braucht

Dein Hetzner-Token, die k3s-Tokens und die Schlüssel deines Snapshot-Buckets, verschlüsselt. Nie Admin-Kubeconfigs, die privaten Schlüssel des Agenten, Snapshot-Inhalte oder die Daten deiner Workloads.

Kein Befehlskanal

Der Agent führt eine feste Liste von Operationen aus: Snapshot, Wiederherstellung, Upgrade, Kubeconfigs, Schlüsselrotation und Diagnose mit deiner Zustimmung für genau diese Anfrage. Sonst lässt sich ihm nichts schicken.

Kubeconfigs, die nur du lesen kannst

Temporäre Kubeconfigs, gültig für 10 Minuten bis 24 Stunden, auf dem Node erzeugt und für einen Schlüssel verschlüsselt, den dein Browser erzeugt. Das Portal reicht sie weiter und kann sie nicht lesen.

Signierte Releases

Der Agent installiert nur Versionen aus einem Release-Manifest, das mit einem offline verwahrten Schlüssel signiert ist, und kehrt zur vorherigen Version zurück, wenn eine neue das Portal nicht innerhalb von 10 Minuten erreicht. Im Labor wurde ein manipuliertes Release abgelehnt; der Weg zurück hat auf einem echten Server noch nicht ausgelöst.

Im LaborGebaut

Agenten betreiben schon vier Apps

Im Labor hat ein Agent auf einem kleinen Modell (Claude Haiku) vier Open-Source-Apps betrieben, Vaultwarden, Listmonk, Umami und Forgejo, jeweils über den Betriebs-Skill der App. Er handelt über typisierte Aktionen, die ihm als MCP-Tools bereitstehen: Destruktive werden abgelehnt, solange sie nicht erlaubt sind, eine Freigabe wird eingeholt, wo der Katalogeintrag eine verlangt, und jeder Aufruf landet in einem Audit-Log.

• 12 aufgezeichnete Läufe für 0,058 $ an Modellkosten
• Die Laborrunde vom 2026-10-09: Vaultwarden, Listmonk und Umami bestanden jede ihrer Laborzeilen; Forgejo bestand 12 von 13, weil seine Alarm-Zeile die Metriken der Plattform braucht
• Backups mit getestetem Restore und ein Upgrade mit Rollback für jede der vier, mit geprüften Daten

„Im Labor“ heißt: virtuelle Maschinen auf einem Mac mit einem echten Kubernetes-Cluster, keine Produktion. Ein Lese-Proxy, der schwärzt, was Agenten lesen, ist In Arbeit; ein Betriebs-Agent, der nur darf, was eine Person in Rufbereitschaft darf, ist Geplant. Ich baue PaaSbox selbst mit Agenten; ich entscheide, und ich bin der Einzige, der ein laufendes System anfasst.

In Arbeit Für PaaSbox Clusters entstehen gerade eine REST-API und MCP-Tools. Mit ihnen kann ein Agent deine Cluster, ihren Zustand, Snapshots und Operationen lesen, einen Snapshot auslösen, ein Upgrade planen, Add-ons ein- und ausschalten und eine Kubeconfig holen, die für seinen eigenen Schlüssel versiegelt ist. Eine destruktive Operation braucht eine ausdrückliche Bestätigung, und jeder Aufruf wird protokolliert. Was Agenten heute tun →

apiVersion: catalog.paasbox.com/v1alpha1
kind: Suite
metadata: { name: team }
spec:
  apps:
    umami: {}
    listmonk: {}
    forgejo: {}
    vaultwarden: {}
  bindings:
    umami.db: { provider: cnpg-shared }
    forgejo.db: { provider: cnpg-shared }
    forgejo.cache: { provider: valkey }
    vaultwarden.db:
      provider: cnpg-dedicated
      params: { size: 1Gi }

Der Ansatz

Kleine, isolierte Cluster

So arbeite ich mit Agenten im DevOps-Alltag, und dafür ist PaaSbox Clusters gebaut: Die Änderung eines Agenten wird in einem eigenen Cluster getestet, bevor sie etwas erreicht, worauf es ankommt, und jede Stage und jede App bekommt einen kleinen Cluster statt eines Anteils an einem großen.

In isolierten Clustern testen

Einen Cluster für den Test bauen, ausgiebig darin testen, ihn löschen. Ein Test, der etwas kaputt macht, trifft nur diesen Cluster. Im Labor war ein PaaSbox-Cluster in 2 Minuten 46 Sekunden angelegt und in 14 Sekunden gelöscht.

Ein Cluster pro Stage und pro App

Mehrere kleine Cluster mit je einem Node, einer pro Stage und pro App, statt eines großen hochverfügbaren Clusters, den sich Stages und Apps teilen. Ein misslungenes Upgrade oder ein außer Kontrolle geratener Test trifft dann eine Stage einer App.

In sich geschlossene Umgebungen

Kubernetes baut eine App mit ihrer Datenbank, ihren Zertifikaten und ihrer Konfiguration jedes Mal gleich auf. So lässt sich eine Umgebung anlegen, testen und wieder wegwerfen, von dir oder von einem Agenten.

Lokale LaboreGeplant

Derselbe Ansatz auf deinem eigenen Rechner: ownpaas soll in sich geschlossene Kubernetes-Labore auf deinen Computer bringen, damit ein Test laufen kann, bevor ein Hetzner-Server beteiligt ist.

Angebote

Was es kostet

Die offenen Komponenten sind kostenlos. PaaSbox Clusters ist das eine bezahlte Produkt, Software as a Service zu einem geplanten Preis, und noch nicht buchbar.

Offene KomponentenIn Arbeit

Kostenlos

Die Bausteine, der Katalog und die Leitplanken, zum Selbstbetreiben.

• Cluster auf Hetzner mit Cluster API und k3s
• Die Plattform und die PaaS-Ebene
• Das Katalogformat, die Laborzeilen und vier Golden Entries
• Die Gardener-Erweiterungen für Hetzner, für eine Landschaft, die du selbst betreibst
• Apache-2.0; der Pool-Manager BSL-1.1

Die Veröffentlichung wird vorbereitet; die Node-Images sind schon veröffentlicht.

Was offen ist →

PaaSbox ClustersIn Arbeit

29 €pro Cluster und Monat, inkl. MwSt.

Außerhalb der EU: 29 US-$ zzgl. anfallender Steuern

ein Node · geplanter Preis

Noch nicht buchbar

Software as a Service für einen k3s-Cluster auf einem Server in deinem eigenen Hetzner-Projekt, aktuell gehalten vom Portal.

• Für Produktion und Nicht-Produktion, auf einem Node
• Angelegt in deinem Projekt, mit deinem Hetzner-API-Token
• k3s und das Betriebssystem des Nodes in deinem Wartungsfenster aktualisiert, nach einem Snapshot
• Snapshots in deinen eigenen S3-Bucket, und Wiederherstellung
• Temporäre Kubeconfigs und eine kurze Liste kuratierter Add-ons
• Jederzeit abkoppeln; der Cluster läuft weiter

Die Rechnung stellt Paddle als Merchant of Record. Den Server rechnet Hetzner direkt mit dir ab. Cluster mit drei Servern kommen später, mit eigenem Preis.

Sag mir, wenn es buchbar ist

Der Preis von PaaSbox Clusters enthält die Umsatzsteuer, wo sie anfällt; außerhalb der EU sind es 29 US-$ zzgl. anfallender Steuern. Die Rechnung stellt Paddle als Merchant of Record. Einrichtung und Beratung gibt es auf Anfrage. Preise hat die Details.

Ausblick

Was als Nächstes kommt

In Arbeit oder entworfen, nicht veröffentlicht. Termine verspreche ich keine.

Drei Server pro ClusterGeplant

PaaSbox Clusters startet mit einem Server pro Cluster. Cluster mit drei Servern kommen später, mit eigenem Preis.

Cloud Viewer mit deinen ClusternIn Arbeit

Cloud Viewer, meine App für Kosten, Logs, Metriken, Uptime-Checks und Alarme auf Hetzner, ist fertig. Gekoppelt mit dem Portal soll sie den Zustand deiner Cluster zeigen, nur lesend, und per Push alarmieren, wenn ein Snapshot oder ein Upgrade fehlschlägt oder ein Node sich nicht mehr meldet. Beide Seiten sind gebaut; Ende-zu-Ende lief die Kopplung noch nicht.

ownpaasGeplant

ownpaas wird später als Laborumgebung und Control Panel verkauft.

Agenten, die deine Apps betreibenGeplant

Ein Betriebs-Agent, der nur darf, was eine Person in Rufbereitschaft darf: Er liest über einen schwärzenden Proxy, handelt über typisierte Aktionen und wartet auf die Freigabe eines Menschen, wo es zählt. Er betreibt zuerst die Cluster von PaaSbox selbst; ein Managed Service folgt.

Offen und geschlossen

Der Mechanismus ist offen

Wer einen Agenten an seine Systeme lässt, will die Leitplanken lesen und die Nachweise wiederholen können, darum sind sie offen: die Bausteine, das Katalogformat, der Action-Runner, der Lese-Proxy, das Harness und die gemessenen Ergebnisse. Was jeden Monat Arbeit kostet, wird verkauft: PaaSbox Clusters als Software as a Service, und später der kuratierte Katalog in der Breite und der Betrieb selbst. Jede Komponente und ihre Lizenz →

Dein Cluster, in deinem eigenen Hetzner-Projekt.29 € im Monat inkl. MwSt., sobald es buchbar ist.

Sag mir, wenn es buchbar istZur Doku