Hoe het werkt

kubehz draait om één vraag: hoeveel wil je uit handen geven, en wat ben je bereid te delen om dat te krijgen? Twee onafhankelijke assen beantwoorden die vraag, en een strikte privacygrens maakt het antwoord veilig.

Twee assen

Je kiest ze afzonderlijk in cluster.lok8s.yaml onder spec.kubehz:

spec:
  kubehz:
    hosting: self          # self | hosted
    access: registered     # none | registered | managed
    apiUrl: https://api.kubehz.cloud

Hosting — wie draait het control plane

Waarde	Betekenis	Status
self	Jij rolt het control plane uit en beheert het op je eigen Hetzner-account. De normale lok8s-flow.	Beschikbaar
hosted	kubehz draait het control plane (etcd, apiserver, scheduler) op zijn infrastructuur; jij draait alleen workers.	Available

Access — hoeveel kubehz ziet en doet

Waarde	kubehz ziet	kubehz doet	Status
none	Niets: helemaal geen contact met het platform.	Niets.	Beschikbaar
registered	Alleen-lezen gezondheid: Kubernetes-versie, nodes & status, gezondheid van control-plane-componenten, certificaatvervaldatum.	Toont het in het dashboard.	Beschikbaar
managed	Beheerdata voor healing-beleid, capaciteitsbewaking, gewenste staat.	Legt de gewenste staat vast; jouw cluster haalt die op en voert de acties uit die aanstaan.	Beschikbaar (Supporter+)

De alledaagse combinatie is hosting: self + access: registered: jouw cluster op jouw account, kubehz als een alleen-lezen dashboard. access: managed is daarbovenop live: het voegt de beheerfuncties van kubehz toe (healing-beleid, capaciteitsbewaking en beheer van de gewenste staat, aangestuurd vanuit het dashboard) en vereist een Supporter-abonnement of hoger. Een managed cluster registreert en wordt geclaimd precies zoals een registered cluster; de abonnementspoort geldt zodra je beheerfuncties aanstuurt.

De vertrouwensgrens — wie je Hetzner-token nodig heeft

Dit is het deel dat ertoe doet, dus het is de moeite waard om het precies te stellen:

• registered (self-hosted): geen Hetzner-token. kubehz krijgt alleen-lezen gezondheid en niets anders. Het kan niets wijzigen op je account of in je cluster.
• managed op je eigen self-hosted cluster: token optioneel. kubehz legt de gewenste staat vast (bijv. “upgrade naar v1.35”); de in-cluster agent haalt die op bij het platform en past die lokaal toe met de credentials die je cluster al heeft. kubehz pusht nooit je cluster in en heeft geen inkomende credential. Self-heal, schalen en upgraden hebben daarom geen token nodig: ze draaien in je eigen cluster, elk achter een eigen uitvoeringsschakelaar. Een Hetzner-token is alleen ooit nodig om je accountspecifieke prijzen te tonen, nooit om het cluster te draaien.
• hosted control plane: token vereist. Hier delegeer je echt: kubehz rolt infrastructuur voor je uit, dus heeft het toegang nodig om dat te doen.

registered, managed en hosted zijn vandaag allemaal live; de managed-grens hierboven is precies hoe de tier werkt: pull-gebaseerd en alleen uitgaand. De escalatie is bewust: je geeft elke functie alleen de toegang die ze nodig heeft, meer niet.

Jouw data — een harde belofte (self-hosted)

Voor self-hosted clusters is dit een garantie, geen extraatje:

• Alleen de data die de functie die je hebt ingeschakeld nodig heeft, verlaat ooit je cluster. registered stuurt gezondheid; managed stuurt beheerdata. Dat is de hele lijst.
• Geen telemetrie. Geen analytics. Niets anders. We verzamelen geen gebruiksdata, workload-inhoud, secrets, logs of metrics waarvoor je je niet hebt aangemeld.
• Alleen uitgaand. De in-cluster heartbeat-agentpusht volgens een schema een statusmomentopname. kubehz maakt nooit verbinding naar je cluster en houdt er geen inkomende credentials voor.
• Uitschakelen is één stap. lo kubehz deregister plus het verwijderen van de kubehz-system-namespace verwijdert alles; je cluster blijft draaien.

Omdat de agent alleen pusht wat een functie nodig heeft, schakelt het uitzetten van een functie ook de bijbehorende data uit.

Eigenaarschap — registreren en claimen

Een cluster wordt van jou op het platform in twee conceptuele stappen:

1. Registreren: bij de provisioning wordt het cluster aangemeld bij kubehz (of voer lo kubehz register uit). Het verschijnt als pending.
2. Claimen: in het dashboard claim je het pending cluster om eigenaarschap te bewijzen en het aan je account te koppelen. Zodra het is geclaimd, is het van jou.

Dat is het hele model: register → claim → owned. Claiming beschrijft beide handshakes volledig: een eenmalige claimcode, of een SSH-vingerafdruk die tegen je Hetzner-account wordt geverifieerd.

Principes

• Open source eerst. lok8s, de CLI die alles uitrolt, is open source en werkt zonder kubehz. Je zit nooit vast.
• Eerlijke prijzen. Prijzen komen uit gemeten kosten op onze eigen vloot en we leggen onze prijzen uit.
• EU-datasoevereiniteit. Infrastructuur in Duitsland; geen afhankelijkheden van Amerikaanse cloud.

Volgende stappen

• Registratie: schakel vandaag alleen-lezen zichtbaarheid in
• Dashboard & account: wat je krijgt zodra je hebt geclaimd
• Gehost control plane: het gedelegeerde pad

Documentstatus

Aspect	Detail
Status	live: self-hosted, managed en hosted beschikbaar; facturering start op 1 november 2026
Laatst gecontroleerd	2026-08-14