Bevor du etwas ausgibst

Jeder paasbox garden-Befehl versteht ein --stub-Flag. Damit läuft die CLI ihre gesamte Abfolge — dieselben Stufen, in derselben Reihenfolge, gegen dieselbe values.yaml — gegen eine Attrappe der Hetzner-API, von SSH und von Kubernetes im Speicher, statt gegen die echten. Kein Server entsteht, kein Token wird gegen ein echtes Konto geprüft, nichts wird abgerechnet. So probt die eigene CI des Werkzeugs einen Aufbau bei jedem Push, und so siehst du am billigsten, was paasbox garden up tatsächlich tut, bevor du es auf ein Hetzner-Projekt loslässt.

Noch nicht veröffentlicht (Stand: 2026-09-08)

Das Werkzeug ist gebaut und im Labor geübt, aber das erste öffentliche Release ist noch nicht geschnitten: Es gibt heute nichts zu installieren. Diese Seite beschreibt, was --stub tut, und zeigt ein echtes Protokoll aus einem Entwicklungsstand. Was das Release dann zeigt, steht unter Dein eigener Gardener.

Was es beweist, und was nicht

Ein grüner --stub-Lauf heißt: deine values.yaml lässt sich lesen, die Stufen laufen in der richtigen Reihenfolge, und die CLI erreicht dieselben Entscheidungspunkte wie ein echter Aufbau — einschließlich der Ablehnung einer Konfiguration, die ein echter Aufbau heute auch ablehnt, etwa dns.mode: sslip.

Es erstellt keinen Server, prüft nicht, ob dein Hetzner-Token gültig ist, und misst nicht, wie lange ein echter Aufbau dauert. Lies einen Stub-Lauf als „meine Werte-Datei ist in Ordnung und die Abfolge stimmt”, nicht als „meine Landschaft wird hochkommen”. Dafür lässt du --stub weg und liest Dein eigener Gardener.

Einmal durchgespielt

paasbox garden init my-garden
paasbox garden up my-garden --stub

Das ist die echte Ausgabe, Pfade gekürzt:

landscape my-garden: my-garden/values.yaml → my-garden/.paasbox/environments/my-garden/cluster.yaml
  all          ok      0.5s  my-garden/out/all.log

### garden my-garden is up
  kubeconfig my-garden/out/my-garden.virtual-garden.kubeconfig
  dashboard  token: paasbox garden dashboard-token my-garden
  next       kubectl apply -f my-garden/examples/first-shoot.yaml

Eine halbe Sekunde, gemessen — das ist die gesamte Abfolge check → up → flux → garden → images → status, die ein echter Aufbau über etwa 40 Minuten durchläuft, hier von der Attrappe statt von Hetzner beantwortet. Was hinter dieser einen ok-Zeile steckt, steht in my-garden/out/all.log; öffne sie, und du siehst jede Stufe, die auch der echte Lauf durchläuft, hier auf die Form gekürzt:

### check — preflight  (0s)
  ✓ S3 bucket garden-lab-backups reachable at https://nbg1.your-objectstorage.com
  ✓ project reachable; 0 server(s), all ours
  ✓ DNS zone example.com owned (dns.mode zone, the Hetzner API)
  ✓ image …, ✓ chart …                      # jedes gepinnte Image und Chart, eine Zeile je Eintrag
  etcd storage class local-path, 1 server(s) [cpx62] in nbg1, network my-garden

### network  (0s)
  network my-garden created (10.60.0.0/16)
### firewall  (0s)
  firewall my-garden created (admin: 203.0.113.7/32)
### servers — 1× [cpx62] (debian-13) in nbg1  (0s)
  my-garden-1 created

### k3s v1.36.4+k3s1 — 1 server(s), embedded etcd  (0s)
  my-garden-1: cluster-init done
### kubeconfig  (0s)
  → …/my-garden.kubeconfig (server 198.51.100.1)

### DNS in zone example.com  (0s)
  A api.my-garden.example.com → 203.0.113.42
  A *.ingress.my-garden.example.com → 203.0.113.42

### garden garden5 + seed soil5 are up — export KUBECONFIG=… for shoots  (0s)

### stub: `status` over the finished landscape  (0s)
  servers: my-garden-1 198.51.100.1/10.60.1.2
  hcloud LoadBalancers: 2 ['virtual-garden-istio-ingress', 'istio-ingress']
  hcloud volumes: 0 (0 GB billed)

Zwei Load Balancer, schon in der ersten Status-Zeile der Attrappe — dieselben zwei Istio-Ingress-Gateways, für die eine echte solo-Landschaft bezahlt, an derselben Stelle der Abfolge, an der ein echter Lauf sie auch zeigen würde.

Reiß es genauso wieder ab:

paasbox garden teardown my-garden --stub --yes

### teardown — my-garden  (0s)
  leftovers: server=0  volume=0  load-balancer=0  network=0  firewall=0
### teardown clean — zero of everything  (0s)

Diese Zeile ist die eigene Buchführung der Attrappe, keine Vermutung: Sie hat mitgezählt, was up erstellt hat, und bestätigt, dass teardown alles davon zurückgefordert hat. Ein echtes Teardown macht dieselbe Aussage über dein Hetzner-Projekt, und es lohnt sich, das beim ersten echten Lauf nachzuprüfen.

Was sonst noch --stub versteht

garden status, garden restore, garden upgrade, garden images und garden teardown verstehen es alle, aus demselben Grund wie up: die Abfolge lesen, ohne etwas anzufassen. gateway create, gateway status, gateway roll und gateway delete (der geteilte NAT- und Ingress-Kasten) auch. garden shoot create nicht — ein Shoot braucht einen echten Garden, gegen den er sich anwenden lässt. Was eine Attrappen-Landschaft dazu zeigt, ist bereits in ihrer status-Stufe zu sehen: die Form eines Shoot-Manifests, kein laufender Shoot.

Weiter

Lass --stub weg, exportiere ein echtes $HCLOUD_TOKEN, und lies Dein eigener Gardener für die Größen, die DNS-Entscheidung und was vierzig Minuten Warten tatsächlich installieren.