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](/docs/hetzner/apalla/security/encrypt-etcd) 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](/docs/hetzner/apalla/security/what-syself-can-access) and [Data at rest and key custody](/docs/hetzner/apalla/security/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](/docs/hetzner/apalla/concepts/ownership/sovereignty-and-data-residency) and the wider [compliance model](/docs/hetzner/apalla/security/meet-compliance-requirements).