Operated in the open
PaaSbox is a one-person company, and the person is me. That is a fact worth knowing before you put production on it, so rather than hide it, I operate in the open: the setup, the numbers and the rules are public, and the numbers are measured by someone else.
The setup
Section titled “The setup”- I decide, take the pages, and am the only one who touches the live landscape. Business hours are Mon–Fri, 09:00–18:00 CET; the support boundary says what is free and what is billable.
- My agents do the build and validation work: they update the Hetzner stack and the platform when upstream moves, run the drills, run security checks, implement selected improvements, and do the first pass of root-cause analysis on incidents. Their output is a pull request or a ticket, never a change to a live system. I chose Gardener partly for this: every change is a thing that can be drilled before it reaches you.
- Automation handles the failures that are understood: an unhealthy node is replaced, a NAT gateway is reset or replaced within six minutes, a lost etcd is restored from its backups, a lost control plane is rebuilt from object storage. Each of these is a drill before it is a feature.
- A dead-man’s switch outside my infrastructure pages me when the platform’s own monitoring goes silent.
The numbers
Section titled “The numbers”Availability is measured by an external monitor, not by me. It probes, from three regions:
- a canary production cluster in the reference shape, owned by PaaSbox, exactly as a customer’s;
- the console and the API;
- a daily cluster creation from token to
kubectl get nodes.
The results are on the status page, with incidents and their write-ups. Customer clusters are not on a public page; every customer gets the same monitor definition to run against their own API endpoint, and that probe is what the availability commitment in the terms is measured by.
Once a month, I publish a report on the blog with:
- availability per cluster, aggregated, against the commitment;
- incidents, their cause, and time to recover;
- what healed itself and what needed me;
- platform cost against revenue;
- what the agents shipped, drilled and investigated, against what I did.
The first report appears one month after launch. Until three months of history exist, this page links to the reports rather than summarising them; a summary with too little history is marketing, and I would rather you read the incidents.
What I publish, and what I do not
Section titled “What I publish, and what I do not”Operations in full, economics as ratios and milestones. This is a charter, not a mood: it stays the same from month to month, and if it ever widens I will say so in the report.
Published, every month
- availability of the canary and of the fleet in aggregate; every incident with its cause and time to recover; what healed itself and what needed me;
- what the agents shipped, drilled and investigated, against what I did, and the hours I spent;
- cost coverage as a milestone: whether revenue covers the platform’s cost, and since when — never the euro amounts, never the cost breakdown;
- how many customers, as a band: “under ten”, “ten to twenty-five”, exact only above twenty-five;
- every incident write-up, anonymised; every drill record; every roadmap and pricing change, with the reasoning.
Not published
- exact revenue and margins, cluster counts (a cluster count times the list price is the revenue), and what the platform’s own servers cost;
- anything about a single customer; customer names, unless they ask for it;
- security details that would help an attacker: addresses, internal names, a vulnerability before its fix has shipped;
- dates as promises. I say what shipped, not what will.
Why the line sits here: the people reading this page are deciding whether the service exists in a year, and a monthly revenue figure at ten clusters tells them less than the drills, the incidents and the hours do. And with fewer than twenty customers, anything per customer is identifying.
The agent charter
Section titled “The agent charter”What my agents may do, and what only I do:
| Agents do | Only I do |
|---|---|
| open pull requests against the platform and the Hetzner stack | merge to the live branch, which deploys |
| run the drill catalogue on a throwaway landscape and record the results | approve a change for customers |
| check dependencies, images and configuration for known vulnerabilities | touch the live landscape |
| draft the root-cause analysis of an incident from the logs and metrics | decide the remedy and apply it |
| propose anything that costs money or deletes data, as a ticket | execute it |
| build internal tooling, dashboards and the lab harness | operate them in production |
Ambient agents, ones that watch and act without a request, are added one scope at a time as each scope earns it, and I announce each addition in the monthly report with what it may do.
The drills
Section titled “The drills”Every change to the platform runs against a throwaway landscape before it reaches a customer. The catalogue, as of 2026-09-06: etcd loss and restore from object storage, loss of the whole platform and its rebuild, a hung or powered-off NAT gateway, node replacement and in-place rebuild of adopted servers through a Kubernetes upgrade, hibernation and wake, tenant isolation, private egress with a dedicated server behind the gateway, and the exit kit. I publish the records with the monthly numbers, with what was measured and what was fixed.
What I promise not to claim
Section titled “What I promise not to claim”- No uptime percentage that I have not measured for at least three months.
- No “free trial” — there is a €5 signup credit with a card on file.
- No “zero data loss” — the recovery point is up to five minutes on a test cluster and zero only for a single platform-node loss on a production cluster.
- No certification I do not hold. The platform runs in ISO 27001-certified Hetzner data centres; PaaSbox itself is not certified.
- No feature described as available before it is.