Glossary
The words these docs use, with the page that explains each. Where one concept could go by several words, the docs use one: the table says which, and the entries below follow it.
The word to use
Section titled “The word to use”| Concept | Use | Not |
|---|---|---|
| The paid product | PaaSbox Clusters | ”the managed service”, “managed k3s” |
| One k3s cluster on one server | a cluster (single node) | “an instance”, “a box” |
| The machine at Hetzner | the server; in Kubernetes terms, the node | — |
| The program on the server | pbx-agent, always with its name | ”the agent” alone |
| An AI model with tools | an agent (a coding agent, your agent) | “a bot”, “AI” alone |
| PaaSbox’s web application | the portal | ”the console”, “the dashboard” |
| An etcd snapshot of the cluster’s state | a snapshot | ”a backup” for the object; Backups is the portal’s tab |
| A cluster for one stage of one app | a stage (staging, production) | “an environment” when a cluster is meant |
| A cluster made for one test and deleted after | a throwaway cluster | ”an ephemeral cluster” |
| The key an agent uses for the REST API and MCP | an API key, with scopes (k3s:read, k3s:write, k3s:access, k3s:destructive) | “a token”: tokens are Hetzner’s and k3s’s |
| A set of k3s, OS image and add-ons, signed | a release (2026.10.1), on a channel (stable, early) | “a version” |
| When upgrades and restarts may run | the maintenance window | ”the maintenance slot” |
| The platform add-on | the PaaSbox Platform (add-on paasbox-platform); an app on it is a SaaSApplication | ”the PaaS layer”, which is an open component |
Add-on
Section titled “Add-on”A component the portal installs into a PaaSbox Clusters cluster from a short, curated list that is part of each release: the Hetzner cloud controller and local storage always, Traefik for ingress, and optionally Hetzner volumes, cert-manager, external-dns, Flux and the PaaSbox Platform. pbx-agent applies an add-on as a k3s HelmChart; switching one off never deletes data. Built in a lab, all but external-dns, which is In progress. See Choose add-ons and the add-on catalogue.
To run a PaaSbox Clusters cluster on a server already in your Hetzner project instead of a new one. The server keeps its ID, its IP addresses and what Hetzner bills for it; its disk is erased and rebuilt with the node image. Built in a lab. See Use a server you already have.
In these docs, an AI agent: a language model with tools that does work on a running system, such as a coding agent that creates a throwaway cluster through the MCP tools. Not to be confused with pbx-agent, which is a program. See Guardrails for agents.
API key
Section titled “API key”The key an agent, a script or CI uses for the portal’s REST API and MCP tools. A team admin makes it for one team, with the scopes it needs and an expiry, sees it once, and can revoke it. It acts as the person who made it and never beyond that person’s rights in the team. In progress See Give an agent access.
Approval
Section titled “Approval”A person’s yes before an agent’s action runs. Destructive actions wait for one; an entry can also mark a routine for approval. In the lab a simulated approver answers, and every answer is recorded. See Agents operating your apps.
Audit log
Section titled “Audit log”For PaaSbox Clusters: the record of every MCP call, and every REST call that changes something or hands out a kubeconfig, refused calls included: who, through which API key, what, with which arguments (secrets taken out), and how it ended. Team admins read it in the portal. In progress In the catalog’s actions server, the record of every call an agent makes, with its stated reason. In the DNS service, the record of every write to your names. See Guardrails for agents.
Built, In progress, Planned
Section titled “Built, In progress, Planned”The three statuses every claim on this site carries when it does not run today. Built ran end to end on real servers in a lab, even if it is not released. In progress the code exists, but it has not run end to end on a real cluster. Planned designed, not built. A status is never raised for effect. See What PaaSbox does and Status of each part.
Catalog
Section titled “Catalog”The catalog of connected apps: one entry per app, saying what the app needs (a database, a cache, a login), how each need is met, what may be done to the app as typed actions, how it is backed up, and the lab rows that prove it. The format and its tools are an open component; the curated catalog at breadth is to be a subscription. See The open components.
Channel
Section titled “Channel”The track a PaaSbox Clusters cluster follows from release to release: stable (the default) or early. A release reaches early after a lab run and three days on my own clusters, and stable seven days later. You choose it per cluster. In progress See Releases and channels.
Cloud Viewer
Section titled “Cloud Viewer”My app for costs, logs, metrics, uptime checks and alerts on Hetzner, at cloudviewer.app. It is finished and works on its own. In progress Paired with the portal, it shows your clusters’ state, read-only, and pushes their alerts. See Connect Cloud Viewer.
Cluster
Section titled “Cluster”In these docs, one k3s cluster on one server in your own Hetzner project, created and kept current by the portal: a single node, control plane included. A cluster per stage and per app, rather than one large cluster they share, is the approach the docs teach. See Choose your setup.
Detach
Section titled “Detach”To end PaaSbox’s management of a cluster without touching the cluster: the portal revokes pbx-agent and stops billing, the cluster keeps running, and its API name stays for 30 days. In progress See Detach or delete a cluster.
DNS token
Section titled “DNS token”A team’s credential for the DNS API, starting with pbdns_: shown once, scoped to DNS, limited to the team’s own names, revocable. A team holds up to five. See DNS names for your clusters.
Entry agent
Section titled “Entry agent”Small models that draft a catalog entry for an app, with the evidence for each field, for a person to review. Built Measured in a lab. Planned Run as an onboarding service in the portal; its pipeline stays closed.
Flux’s source and kustomize controllers as an add-on of PaaSbox Clusters: the cluster pulls manifests from Git repositories and applies them. The PaaSbox Platform requires it. Built in a lab; in release 2026.10.2, which is not published yet. See the add-on catalogue.
Garden Linux
Section titled “Garden Linux”The Linux distribution of PaaSbox Clusters’ node image, built for Hetzner by one of the open components. Its images boot from a single image file, which lets a node update in place and boot the previous version again. See The open components.
Gardener
Section titled “Gardener”An open-source system for running many Kubernetes clusters from one control point. Its extensions for Hetzner are among the open components, and a course teaches it. PaaSbox does not offer Gardener clusters. See Gardener on Hetzner.
Golden entry
Section titled “Golden entry”One of the four catalog entries published complete as the worked example: Forgejo, Vaultwarden, Listmonk and Umami, each with its operate skill and evals. Built In a lab. See Agents operating your apps.
Harness
Section titled “Harness”The tool that has an agent operate a live app through its operate skill and evals, records the approvals it asks for, and grades the run. It is the lab row “skill”. Built In a lab.
The part of the portal that pbx-agent talks to: it enrolls each server’s pbx-agent, answers its sync about every 30 seconds with the desired state, and hands out at most one operation at a time. It never opens a connection to your server. Built in a lab, not live. See How it works.
In a lab
Section titled “In a lab”A throwaway Hetzner project for a paid run, or virtual machines on a Mac running a real Kubernetes cluster. A lab result is evidence, not a production result. See Operated in the open.
A small Kubernetes distribution that runs as a single binary. PaaSbox Clusters and the open building blocks for Cluster API both run it. See k3s.io.
Kubeconfig
Section titled “Kubeconfig”The file kubectl reads to reach a cluster. The portal’s kubeconfigs are temporary, 10 minutes to 24 hours, with the role admin or view: pbx-agent makes each on the node as a ServiceAccount in the namespace pbx-access and seals it to a key only the asker holds. Built in a lab, from the browser; In progress for an agent through the API. See Get a kubeconfig.
Lab row
Section titled “Lab row”One check that installs, breaks or operates an app in a particular way and passes or fails: install, binding, network rules, configuration, actions, alert, restore drill, upgrade, skill, and a second install. A catalog entry is proven by its lab rows. See Operated in the open.
Leader
Section titled “Leader”On a PaaSbox Clusters cluster with several servers, the one pbx-agent that does cluster-wide work, chosen through a Kubernetes lease. On a single node its pbx-agent is the leader. See pbx-agent.
Maintenance window
Section titled “Maintenance window”The hours, in your time zone, in which upgrades and restarts of k3s may run on a cluster; the default is Saturday and Sunday, 02:00 to 05:00, Europe/Berlin. An upgrade queued for the window waits for it, and you can also start one at once. Every upgrade reboots the node. In progress Holding scheduled upgrades and restarts to the window has not run on a real cluster yet. See Upgrade a cluster.
The Model Context Protocol, the way a coding agent calls tools. The portal’s MCP tools give an agent the same requests as the REST API, each needing one scope of its API key. In progress See MCP tools.
Merchant of record
Section titled “Merchant of record”The company that sells a product to you in its own name, issues the invoice and handles VAT and sales tax. For PaaSbox Clusters that is Paddle. In progress The billing through Paddle is being built. See Costs and billing.
Node image
Section titled “Node image”The operating system a PaaSbox Clusters server boots: Garden Linux with k3s inside, uploaded once to your project. An upgrade writes the new image beside the running one and boots it; pbx-agent itself is downloaded separately. Built The image, and in a lab the upgrade through pbx-agent; the automatic return to the previous image In progress. See Upgrade a cluster.
Open components
Section titled “Open components”The parts of PaaSbox you can run, read and change yourself, free: the building blocks for clusters on Hetzner, the platform and the PaaS layer, the catalog and the guardrails. Apache-2.0, the pool manager BSL-1.1. In progress Being prepared for publication, in waves; the node images are published. See The open components.
Operate skill
Section titled “Operate skill”The instructions a catalog entry gives an agent for operating its app: which action answers which question, and what to check before and after. Each golden entry has one, with evals. See Agents operating your apps.
Operations agent
Section titled “Operations agent”Planned An agent that operates apps on a schedule and on alerts, reading through the read proxy and acting only through typed actions, which may do only what a person on call may do. It runs PaaSbox’s own clusters first. See Agents operating your apps.
ownpaas
Section titled “ownpaas”Planned A lab environment and control panel, to be sold later, built on the same open components. Not released, no date.
PaaS layer
Section titled “PaaS layer”App, ManagedPostgres, ManagedValkey and ManagedTracing: thin Kubernetes objects that turn an image into a URL with TLS and add a database, a cache or LLM tracing. An open component, documented under Open components; not part of PaaSbox Clusters, and not the PaaSbox Platform. See The PaaS layer.
PaaSbox Clusters
Section titled “PaaSbox Clusters”In progress The one paid product, sold as software as a service: k3s clusters in your own Hetzner project, control plane included, created and kept current by the portal through pbx-agent. One node per cluster, for production and non-production. Sold through Paddle as the merchant of record. Not bookable yet. See How it works.
PaaSbox Platform
Section titled “PaaSbox Platform”The add-on paasbox-platform: it turns a cluster into a platform for SaaS applications. You, or your agent, write a SaaSApplication and get Postgres with backups, Redis, TLS certificates, release hooks and schedules; the applications stay yours. It requires Flux and replaces the cert-manager add-on. Built in a lab; in release 2026.10.2, which is not published yet. See the add-on catalogue.
pbx-agent
Section titled “pbx-agent”The program on each PaaSbox Clusters server, run by systemd: it listens on no port, calls the hub over outbound HTTPS, applies the desired state and runs a fixed list of operations, never arbitrary commands. A program, not an AI model; the docs always name it, never “the agent” alone. Built in a lab. See pbx-agent.
Pool manager
Section titled “Pool manager”The fleet controller that keeps a fleet’s pooled servers on Hetzner, cloud and dedicated, so that servers are claimed and released rather than created and deleted. Source-available under BSL-1.1. See The open components.
Portal
Section titled “Portal”PaaSbox’s web application behind paasbox.com: teams, the DNS service, and for PaaSbox Clusters the pages, the hub, the provisioner and the REST API and MCP tools. Closed. In progress Not live for PaaSbox Clusters yet.
Provisioner
Section titled “Provisioner”The part of the portal that calls the Hetzner API with your token to create, replace and delete what belongs to a cluster: the server, the private network, the firewall, the IP address and the DNS name. It is the only part that uses your Hetzner token. Built in a lab, not live. See How it works.
Read proxy
Section titled “Read proxy”In progress paasbox-kube-read: gives an agent kubectl for reading only, refuses Secrets, and redacts secret values in every answer and log line. Built on a branch and tested on a throwaway cluster. See Agents operating your apps.
Release
Section titled “Release”One tested combination of node image, k3s, pbx-agent and add-on versions, with a manifest signed by a key kept offline, named by date and number (2026.10.0, 2026.10.1, 2026.10.2). A cluster moves only from one release to another, along tested paths. Built in a lab, all three, signed with a lab key. None is published. See Releases and channels.
Restore
Section titled “Restore”Bringing a cluster’s state back from a snapshot. In place, on the same server, it resets the state and keeps the data in the volumes; onto a new server it is planned. In the catalog, a restore drill restores an app’s backup into a scratch copy and reads a marker back. Built in a lab, in place; onto a new server Planned. See Take and restore snapshots.
SaaSApplication
Section titled “SaaSApplication”The Kubernetes object you, or your agent, write on a cluster with the PaaSbox Platform: one application with its image, its components (web, workers, a singleton), its database and cache, its release hooks and its hostname. kubectl get saasapp lists them. Built in a lab. See Deploy your first app.
What an API key may do: k3s:read (see clusters, health, snapshots, operations, upgrades, add-ons), k3s:write (take snapshots, schedule upgrades, switch and configure add-ons), k3s:access (ask for and revoke kubeconfigs sealed to the agent’s own key), k3s:destructive (create, delete, detach and restore clusters, each only with the cluster’s name typed as confirmation). Every call needs exactly one. In progress See Give an agent access.
Server and node
Section titled “Server and node”The server is the machine at Hetzner, in your project, billed to you by Hetzner. In Kubernetes terms it is the node. A PaaSbox Clusters cluster has one.
Snapshot
Section titled “Snapshot”A copy of a cluster’s state, its etcd database, taken by k3s on a schedule or on demand and sent from the node straight to your own S3 bucket, never through the portal. It does not include the data in your volumes. The docs call the object a snapshot; Backups is the portal’s tab for them. Built in a lab. See Take and restore snapshots.
Software as a service (SaaS)
Section titled “Software as a service (SaaS)”Software you use, run by its maker, without running it yourself. PaaSbox Clusters is sold this way: the portal, pbx-agent on your node, signed releases and the add-ons create your clusters and keep them current, while the server, the cluster and its uptime stay yours. It is not a managed service: nobody watches your workloads for you. See How it works.
One step of an app’s way to its users, such as staging or production. PaaSbox gives each stage of each app a cluster of its own, named after the app and the stage, such as upcheck-staging and upcheck-prod. See Run staging and production as separate clusters.
A set of catalog apps installed together, with how each app’s needs are met: which database, which cache, shared or dedicated. Rendered from one file. See The open components.
Throwaway cluster
Section titled “Throwaway cluster”A cluster made for one test and deleted after it, such as one per pull request, in which an agent’s change runs before it reaches a stage. It is billed like any cluster, from first ready until it is deleted; Costs and billing says how a part month is charged, and why a throwaway cluster that is the team’s only one costs the month. See Quick start and Why isolated clusters for agents.
Typed action
Section titled “Typed action”An operation a catalog entry declares for its app, with a name, typed parameters and whether it is destructive, served to an agent as an MCP tool. It is the only way an agent changes an app. See Agents operating your apps.
Typed confirmation
Section titled “Typed confirmation”The cluster’s name, typed out, before a restore, a detach or a delete in the portal, and before a create, a delete, a detach or a restore through the API. See Guardrails for agents.
One of the three steps in which the open components are published: the building blocks first, then the catalog and the CLIs, then the agent-operations pieces. See The open components.