Run a dedicated management cluster in your own account
For regulated and high-assurance environments, you can run the management cluster in your own Hetzner account instead of Syself's. Nothing about how you use your workload clusters changes; what changes is where the control plane and its keys live. This option closes the one management-cluster caveat that the rest of the security tab calls out.
Where the management cluster runs#
Where the management cluster runs is a choice. The management cluster is the Syself-operated cluster that provisions and reconciles your workload clusters, and it runs in one of these places:
- Syself-hosted (the default). Syself hosts the management cluster. Simplest to adopt, and correct for most teams.
- Dedicated. The management cluster runs in your own Hetzner account. Syself operates it for you, but it sits inside your boundary.
The workload-cluster experience is identical either way: the same kubectl, the same objects, the same features. The choice is only about where the management plane lives.
What moving it into your account changes#
Moving it into your account puts these inside your boundary, which is exactly what a regulated or sovereignty-sensitive environment needs:
- Key custody. With the default, the etcd encryption key Secret lives in the Syself-operated management cluster. In the dedicated model it lives in yours, so no key ever leaves your account. This is the caveat What Syself can and cannot do and Data at rest and key custody call out, closed.
- Audit scope. The management cluster's own audit trail is inside your account, so an auditor's scope stays entirely within your boundary.
- Provider trust. Nothing about your control plane depends on trusting a Syself-operated environment; the whole stack, management and workload, is in infrastructure you control.
When it is worth it#
A dedicated management cluster adds operational overhead and cost, so it is worth it when the requirement is real:
- a regulated environment (finance, health, public sector) where a third-party-operated control plane is not acceptable,
- a sovereignty requirement that every component and key stay in your jurisdiction and your account,
- an audit that must not extend into another organization's infrastructure.
For most teams the Syself-hosted default is the right choice. Use dedicated when the assurance requirement justifies running and paying for a management cluster of your own. Syself operates it for you either way, so the difference is where it runs, not who keeps it healthy. It fits alongside sovereignty and data residency and the wider compliance model .
Multi-tenant isolation for agencies
How to keep one client's cluster provably unable to reach another's, and how to isolate tenants inside a shared cluster when you must.
Restrict API server access
Limit which clients reach the Kubernetes API server through the load balancer with a KubeGate source-CIDR policy, and verify a blocked client is denied.