Storage in a Space
Storage is the one part of a Space worth deciding before you deploy something stateful, because the honest answer is a menu rather than a single default.
The short version: your nodes’ own disks are yours and cost nothing extra. Everything else is a trade between convenience, durability and price.
The menu
1. Local disks — free, and yours
Your nodes have disks. A pod can use them, and nothing about that involves kubehz or costs anything beyond the machine you already pay for.
Good for: caches, scratch space, build artifacts, anything you can lose without minding, and single-node databases where you have accepted the trade.
Understand the trade: a local volume is tied to the machine it lives on. If that node dies, the data is on a dead machine, and a pod that needs it cannot start elsewhere. There is no replication unless your application does it. Kubernetes will not fix this for you, and neither will we.
Back it up yourself. Nobody else is backing up your node’s disk.
2. Attached block volumes — durable, still yours
If your machines are Hetzner Cloud VMs, you can attach a Hetzner Cloud Volume to a node, mount it, and use it exactly like a local disk that happens to survive the machine. You buy and manage the volume; kubehz is not in the loop and does not bill for it.
Good for: databases and anything where losing the node must not lose the data.
Understand the trade: the volume attaches to one node at a time. Moving it to another node is a manual step today: attach, mount, let the pod reschedule. That is fine for a database you would move deliberately anyway; it is not a transparent failover.
Automating this properly needs a storage driver that can act on your cloud account on your behalf, which is a larger piece of work than it looks. It is on the roadmap; the manual recipe works now.
3. Object storage: the one that travels
S3-compatible object storage does not care which node your pod is on, which makes it the natural fit for a model where nodes come and go. Today you bring your own bucket (Hetzner Object Storage or any S3 endpoint); a kubehz-issued bucket with credentials scoped to your Space is planned, not shipped.
Good for: uploads, backups, artifacts, static assets: anything your application can address over HTTP.
Understand the trade: it is object storage, not a filesystem. Your application has to speak S3.
Planned
kubehz-provided object-storage packages and their prices are not final. Nothing here is a price commitment; until they ship, use a bucket of your own.
4. Network block storage — later
Replicated block storage served from the platform’s own nodes, with a per-tenant volume and credentials that can only reach your data. Same-region latency, so it is fine for moderate IO.
This is planned, not shipped. When it lands it will be the closest thing to “just works” for stateful workloads in a Space.
Choosing
| You are running | Start with |
|---|---|
| A stateless service | Nothing: you do not need storage |
| Caches, scratch, build state | Local disk |
| A database you would move by hand anyway | Attached block volume |
| Uploads, backups, artifacts | Object storage |
| Something that must survive any single node, transparently | Wait for network block storage, or use a cluster of your own |
What we do not do
We do not back up your data. Not local disks, not attached volumes. We run the control plane (the Kubernetes objects that describe your workloads), and that is what we protect. The bytes inside your PersistentVolumes are yours, on your machines, under your backup policy.
If that is uncomfortable for what you are building, that is a real signal: consider a hosted cluster, where the storage story is ours to run, or keep the stateful part somewhere managed and run the stateless part here.
Doc status
| Aspect | Detail |
|---|---|
| State | Live: local disks and attached volumes as described; kubehz-provided object storage and network block storage planned, not shipped |
| Last reviewed | 5 September 2026 |