Security & trust

You hand PaaSbox a read/write token to a Hetzner project and let it run Kubernetes control planes for you. That deserves a plain-language accounting of how the platform is built to be trusted — what we hold, what we can see, and what is structurally impossible. No badges on this page, just mechanics.

Your Hetzner token

• The token enters the platform once, is validated by listing your project, and is stored encrypted at rest. It is never displayed again — not in the console, not in the API, not to support.
• It is scoped to one Hetzner project (we recommend a dedicated one) and is used exclusively to manage cluster resources there — servers, networks, load balancers, volumes. It grants no access to your other projects or your Hetzner account itself.
• You can rotate it in the portal, or revoke it at Hetzner, at any time. Revocation is your hard off-switch: without the token, the platform cannot touch your project.

One write path

Every change to your infrastructure flows through the portal and its API — a single, gated write path where billing checks and safety invariants apply before anything happens. There is no side channel: no agent in your project with its own privileges, no SSH access we retain, no inbound connection into your project at all (nodes connect outbound-only to their control plane).

Customers get no access to the platform’s control infrastructure — the credential you receive is a cluster-admin kubeconfig for your cluster, valid at most 8 hours, minted on demand, never stored on our side, and audited on issuance in your team’s activity log. It reaches your cluster’s API server and nothing else.

The never-delete invariant

The platform’s flagship promise — adopted servers are never deleted — is not a policy we follow but a property of the system: the component that manages adopted servers has no delete path for them, and Hetzner delete protection is enabled on each adopted server as an independent second guard at the infrastructure level. Every operation the platform performs on an adopted server is from the price-safe list — rebuild, never delete, never rescale. The adoption docs walk through it.

What we can see — and what we don’t look at

Honest boundaries:

• We operate and monitor your control plane — API server health, etcd, provisioning state. That’s part of the service.
• We do not read your application’s logs or data by default. Your workloads run on your nodes in your project; workload observability is yours to install (you have admin access), not a platform feature that phones home. If a support case ever benefits from looking at something of yours, that happens with you, at your initiative.
• Billing sees metering, not content: awake hours per cluster, not what the cluster does.

Where data lives

The platform and the control planes it operates run in Hetzner data centers in the European Union, and your worker nodes live in your own Hetzner project. Customer data is stored within the EU — a factual statement about where the machines are, which is also what the contract terms commit to. Payment data is handled by Stripe; card numbers never touch our systems.

Backups

Continuous backups of your cluster’s etcd state are part of the service — the specifics, and the honest line between what we back up and what remains yours, are on backups & availability.

Reporting a vulnerability

If you believe you’ve found a security issue, email support@paasbox.com with “security” in the subject — please don’t open a public issue. You’ll get a human reply, and we’ll keep you informed through the fix. The machine-readable version of this policy lives at /.well-known/security.txt.

We’re a small company; there is no bug-bounty program (as of 2026-07-09) — but reports are taken seriously, acted on quickly, and credited if you’d like.