Spaces

A Space is a slice of a Kubernetes cluster that kubehz runs and secures, with namespaces that are yours and nodes that are yours. You bring the machines; we operate the control plane.

Bring a €4 VM, get a managed Kubernetes namespace.

Which path is this?

kubehz has three shapes. Self-hosted: your cluster on your account, kubehz watching. Hosted: we run the control plane, workers on your Hetzner account. Spaces: we run one control plane shared by many customers, and you register your own machines into it. Spaces are the cheapest of the three, because the expensive part (the control plane) is shared.

What you get

• One or more namespaces on a control plane we run, patch and back up.
• Your own nodes. You buy them, you own them, you pay whoever sells them: Hetzner, another provider, or the machine under your desk. kubehz never provisions them and never bills for them.
• kubectl access to your namespaces, through your kubehz login.
• One stable API endpoint for the lifetime of your Space: https://<your-space>.k8s.kubehz.cloud. It uses a publicly trusted certificate (no CA download) and it stays the same through every migration the platform performs. Set it once in your kubeconfig and CI, then forget it.
• The platform baseline already running: CNI, ingress, certificates, DNS.

What you do not get, on purpose

No access to the shared control plane. There is no admin kubeconfig for the plane a Space starts on. It is shared with other customers, so handing out cluster-admin would hand out their data too. This is the trade that makes the price work. When you outgrow it, add your own control plane: a dedicated one on your own nodes, cluster-admin included.

Concretely, that means:

• No kubectl get nodes -A across the cluster, no cluster-scoped objects of your own (no CRDs, no ClusterRoles, no admission webhooks).
• No custom CNI, and no changing the cluster’s networking.
• You see your namespaces and your nodes. Other customers’ workloads are invisible to you, and yours to them.

If you need any of that, you need a cluster of your own: take the hosted or self-hosted path instead. Moving up is a supported migration, not a rebuild.

How isolation works

Four boundaries, each independently enforced:

1. Your pods run only on your nodes. Every namespace carries a node selector for your tenant, and your nodes carry a matching label plus a taint that keeps everyone else off. A pod of yours cannot land on another customer’s machine, and theirs cannot land on yours.
2. Your network is closed by default. Each namespace starts with a default-deny policy. Traffic between your own namespaces, DNS, and the internet are opened for you; another customer’s namespaces are not reachable, in either direction, on any protocol.
3. Your credentials only work on your things. Access is scoped to your namespaces. A request for someone else’s Space answers not found (not forbidden), so the list of who else is on the cluster is not something you can probe for.
4. The platform’s own storage and control traffic are unreachable from any customer node.

Nodes are yours, and that cuts both ways

kubehz schedules onto your machines. It does not provision them, log into them, patch them, or watch their disks. If a node dies at 3am, your workloads reschedule onto your other nodes — if you have other nodes.

That is the honest version of the deal, and it is worth planning around:

• Run at least two nodes for anything you care about staying up.
• You own the OS: kernel updates, disk space, the machine’s own firewall. We publish a recommended firewall: it is a service to you, not a control over you; you have root and can change it.
• Deregistering a node in the dashboard does not stop the machine. It withdraws the node’s credentials and removes it from the cluster. Shutting the box down (and stopping its bill) is yours to do.

Limits

A Space is three numbers, and you set all three yourself with a slider on the Space’s page in the dashboard. There are no plans and no sizes:

Number	Range	What it sets
Nodes	1 to 5	how many machines you may register
Namespaces	1 to 3	how many namespaces the Space holds
Object size cap	64 to 512 KiB, with a payment method on the account	the largest Secret or ConfigMap your namespaces accept

The object size cap starts at 256 KiB. It keeps one tenant from filling the shared control plane’s datastore with a handful of large objects, and it is the one number with no price: with a payment method on the account you move it anywhere in the range, and without one it stays at the default, whatever your account mode. Helm is the exception: a Helm release Secret keeps Kubernetes’ own 1 MiB limit, whatever the cap says.

What it costs. An account gets one Space for nothing, and every Space includes 2 nodes, its first namespace and the 256 KiB cap. Without a payment method an account stays at those numbers, whatever its mode. Add one and you can move every slider to its maximum, and the meter prices each node and each namespace above what the Space includes, by the hour and capped by the month; see Pricing.

Past the maximum? More than 5 nodes or more than 3 namespaces is a cluster of its own, not a bigger Space: take the hosted control plane, where you set the shape and the workers stay on your Hetzner account.

The dashboard is authoritative

The dashboard always shows the numbers your Space is actually running under; trust that over any figure written in a doc.

Getting started

1. Create a Space with the CLI: write a cluster.lok8s.yaml with kind: Kubehz and spec.kubehz.hosting: shared, export KUBEHZ_TOKEN (an API token from the dashboard, Access → API Tokens), then run lo provision. The dashboard lists and manages Spaces; it has no create form yet.
2. Join your first node.
3. Deploy into your namespace with kubectl, exactly as you would anywhere else.

Storage is worth reading before you deploy something stateful; see Storage in a Space. What a Space costs is on the pricing page: one Space per account is free, with 2 nodes and its first namespace included.

Doc status

Aspect	Detail
State	Live: Spaces live; nodes, namespaces and the object size cap set per Space; pricing published
Last reviewed	18 September 2026