Residency and sovereignty are different. Residency is where the disks sit. Sovereignty is who owns the servers, who holds the keys, and whose courts can reach the company running them. Jurisdiction follows ownership, not location. An EU region on a US-owned cloud gives you residency. It does not give you sovereignty.

Think of a safe deposit box in the Frankfurt branch of a foreign bank. The box is in Frankfurt. The bank is not. A court order to the bank's headquarters reaches all of its branches, including that one. Moving the box to another branch does not help, because the order applies to the bank, not to a building.

With Syself Autopilot, Syself's managed Kubernetes service, you own the account, the servers, and the keys. Because you own all three, the operator's home jurisdiction no longer reaches your data.

Your clusters run in your own account#

Your workload clusters run on servers in your own Hetzner account. They do not run inside a Syself multi-tenant service. The rental contract, the invoices, and the servers are yours. Syself provisions, upgrades, and replaces those servers, but Syself is not the operator of record. In GDPR terms you are the data controller of your own infrastructure: the party that decides why and how personal data gets processed.

People at Syself cannot reach your cluster. The automation can, but only for provisioning and lifecycle. It does not touch or process your application data. For an auditor: your data sits in a Hetzner account you own, in a cluster only you have workload access to, and Syself is outside your data-processing scope.

Nothing is shared across tenants. Every workload cluster gets its own API server, its own etcd, and its own certificate authorities. No shared Syself service sits in your control plane.

etcd is the cluster's database, where Kubernetes stores every object, including Secrets. One cluster's Secrets stay in that cluster's etcd and nowhere else.

A failure in one cluster does not affect another.

One piece is Syself-operated: the management cluster. It runs the controllers that create, upgrade, and heal your clusters, and it holds your cluster's declaration. If you turn on etcd encryption, it also holds the one Secret with your encryption config, and the key-custody section below covers that.

A cluster runs in one region#

A cluster runs in exactly one region. You choose it once at creation, through the region topology variable, and the default is fsn1. Everything in the cluster stays in that region. Hetzner has regions in the EU, in the US, and in Singapore, so you can keep a cluster inside EU jurisdiction, on EU-owned infrastructure, in your own account. You can also put it in the US or Asia if that is where your data has to sit.

The region is per cluster, not per node pool. A running cluster does not move between regions.

Who holds which key#

Only the etcd encryption key is a custody question. The OS integrity keys are not. The table shows who generates each key, where it is stored, and who can read it.

Neither OS key holds a secret you would hand over. Neither one protects your data either; they prove integrity, not confidentiality. The module-signing key signs every kernel module during the build, then it is destroyed. The verity root hash belongs to the read-only OS and is public on purpose, so you can recompute it from the released image and check a node yourself. Syself Linux covers how the immutable OS is built and verified.

Encryption at rest for etcd is opt-in and off by default. Until you enable it, Kubernetes stores Secrets in etcd unencrypted. You generate the key yourself, and no external key management service sits in the path. But the management cluster starts your API server, and it has to hand that API server the key at startup, so the Secret with your encryption config is stored in the management cluster. That key stays inside Syself-operated infrastructure for as long as encryption is on. This is the trade for a managed control plane: the platform that starts your API server can read that key. Running a dedicated management cluster in your own account closes that caveat.

Encryption at rest is not retroactive. Existing Secrets stay plaintext until you re-apply them, which rewrites them through the new encryption. It is also not access control: the API server decrypts on read, so any request your RBAC authorizes returns plaintext. Least-privilege RBAC is the control for that path, not encryption. The rotation steps, and how to re-encrypt what was written before, are in encrypt etcd .

What leaves the region#

Your application data never leaves the region or your account. The only footprint outside the cluster is in the management cluster: your cluster's declaration, and, if you enable encryption, the one config Secret.

On disk, node volumes and PersistentVolumes are plaintext by default. The immutable OS gives you integrity, not confidentiality: it tells you if a block changed, but it does not keep the contents secret. If your data needs encryption at rest, encrypt it in the application, or build a volume-encryption layer from the dm-crypt and cryptsetup pieces already in the image. No provisioning step makes encrypted volumes for you, and no KMS integration ships: nothing fetches keys from Vault, a cloud KMS, or an HSM.

How to decide if this fits#

You own the account, the servers, the keys, and the data-controller role, in a region you pick. Syself runs the platform on top.

If you need EU jurisdiction, your own account, your own data-controller role, and no control plane shared with other tenants, Syself Autopilot meets that as it ships. Pick an EU region, turn on etcd encryption, and re-encrypt what was written before.

A few things are still exposed. The one config Secret for etcd encryption sits in Syself-operated infrastructure. Disks in your own account are plaintext. Any Secret is readable in plaintext by anyone your own RBAC allows.

If your rule is stricter, that no third party may ever hold key material, or that every disk must be encrypted at rest, the platform alone does not meet it. Plan application-layer encryption and your own key handling on top before you put regulated data on it.

Your workload layer is portable. Your manifests, Helm charts, kubectl workflows, and data are standard upstream Kubernetes and move anywhere. The platform underneath, the immutable node OS, the node agent, the gateway, and the controllers, is Syself's own software.

The platform depends on no provider private network, so the same design runs on more than one provider. You are not locked in to a single provider.

The sovereignty claim is also standardized. A cluster can prove it conforms to the Sovereign Cloud Stack , the European initiative Syself builds the Kubernetes layer for.

These nodes run over the open internet using per-connection identity. The security model explains how that works. What you own, what Syself manages shows which side of the responsibility split the config Secret and the plaintext disks fall on. For the standard we built this on, see Kubernetes for the Sovereign Cloud Stack .