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 has two budgets: how many nodes you may register, and how many namespaces you may have. Both are shown on the Space’s page in the dashboard, counted live. The ceilings follow your account mode:

Account mode	Nodes per Space	Namespaces per Space
Free	2	1
Supporter	5	3
Enterprise	10	5

Need more? Ask for a higher limit from the Space’s page in the dashboard, or with POST /api/spaces/{id}/limit-requests (the resource, the value you want, and a short reason). We review each request by hand and raise the ceiling on the Space itself, so your account mode does not change.

The dashboard is authoritative

The table shows today’s defaults. The dashboard always shows the limits your Space is actually running under; trust that over any number 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: the first Space, its first namespace and two nodes are free.

Doc status

Aspect	Detail
State	Live: Spaces live; ceilings per account mode with limit requests; pricing published
Last reviewed	5 September 2026