Try it before you spend anything

Every paasbox garden command takes a --stub flag. With it, the CLI runs its whole sequence — the same stages, in the same order, reading the same values.yaml — against an in-memory fake of the Hetzner API, SSH and Kubernetes instead of the real ones. No server is created, no token is checked against a real account, nothing is billed. It is how the tool’s own CI rehearses a bring-up on every push, and it is the cheapest way to see what paasbox garden up actually does before you point it at a Hetzner project.

Not released yet (as of 2026-09-08)

The tool is built and drilled in the lab, but the first public release has not been cut: there is nothing to install today. This page describes what --stub does and shows a real transcript from a development build. See Your own Gardener for what the release will look like.

What it proves, and what it does not

A green --stub run means your values.yaml parses, the stages run in the right order, and the CLI reaches the same decision points a real bring-up would — including refusing a config that a real bring-up would refuse, such as dns.mode: sslip today.

It does not create a server, does not check that your Hetzner token is valid, and does not measure how long a real bring-up takes. Read a stub run as “my values file is sound and the sequence is correct,” not as “my landscape will come up.” For that, drop --stub and read Your own Gardener.

Walk through it

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

This is the real output, paths shortened to fit:

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

Half a second, measured — that is the entire check → up → flux → garden → images → status sequence a real bring-up runs over about 40 minutes, answered by the fake instead of Hetzner. The detail behind that one ok line is written to my-garden/out/all.log; open it and you see every stage the real run also goes through, trimmed here to the shape of it:

### 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 …                      # every pinned image and chart, one line each
  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)

Two load balancers, from the first status line the stub prints — the same two istio ingress gateways a real solo landscape bills for, at the same place in the sequence a real run would show them.

Tear it down the same way:

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)

That line is the fake’s own bookkeeping, not a guess: it tracked what up created and confirms teardown asked for all of it back. A real teardown makes the same claim about your Hetzner project, and it is worth checking the first time you run one for real.

What else takes --stub

garden status, garden restore, garden upgrade, garden images and garden teardown all accept it, for the same reason up does: reading the sequence without touching anything. gateway create, gateway status, gateway roll and gateway delete (the shared NAT and ingress box) take it too. garden shoot create does not — a shoot needs a real garden to apply to, so rehearsing one is what a --stub landscape’s status stage already shows you: the shape of a shoot manifest, not a running one.

Next

Drop --stub, export a real $HCLOUD_TOKEN, and read Your own Gardener for the sizes, the DNS decision and what forty minutes of waiting actually installs.