The Sovereign Cloud Stack (SCS) is the European sovereign-cloud initiative. It is open source and funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK). Its goal is provider independence: a workload that runs on one SCS-compatible⁠ provider should move to another without changes. The standards, decision records, and test tooling are public at github.com/SovereignCloudStack/standards⁠.

Syself won the SCS VP-05 tender to build Kubernetes-as-a-Service for SCS, and is a founding member of the SCS Forum. Syself Autopilot runs on that same open standard.

You can run the SCS tests against your own cluster and show the results. This matters when a procurement form asks whether your platform is provider-independent, or an auditor asks how you would move off Hetzner.

Cluster Stacks#

Cluster Stacks is what Syself built for SCS: it packages the node OS, the topology, and the cluster components into one tested unit, built on Cluster API, the open CNCF standard for declaring clusters. Cluster stacks covers it in full.

Meeting the SCS Kubernetes standard#

A Syself Autopilot cluster already meets the SCS Kubernetes Cluster Standard. That standard is the set of rules a conformant cluster must satisfy: API behavior, networking, storage, access control, and control-plane spreading.

SCS publishes open standards and open test suites. Run the public suites against your own cluster whenever you want. A full pass takes about an hour.

A cluster meets the standard as it ships, with one exception. SCS wants control-plane nodes on separate physical hosts, so one failed host cannot take down two of them at once. You set one Cluster variable: a spread placement group on cloud, or bare-metal control planes, which are separate machines already.

You assemble none of the rest. The network plugin (Cilium), the storage driver, and the API-server settings all come from the cluster stack.

Syself integrates and tests that combination and versions it as one unit, and upgrades keep the cluster conformant. Build an SCS-compatible cluster lists what the standard asks for, point by point, and walks through proving conformance with the CNCF and SCS suites.

Which SCS layer applies#

SCS writes standards for two layers: the IaaS layer and the Kubernetes layer. Only the Kubernetes Cluster Standard applies to a Hetzner cluster. The IaaS layer is OpenStack, and Hetzner Cloud is not OpenStack, so there is nothing to certify there.

If a requirements document asks for "SCS conformance" with no layer named, ask which layer it means. For a Kubernetes-as-a-Service offering, that is the Kubernetes layer.

What SCS-compatible makes portable#

SCS-compatible means your workloads are portable, not the platform underneath them. Your manifests, Helm charts, kubectl workflows, and data are stock upstream Kubernetes, so they move to another SCS-compatible provider without changes. The platform under them stays with Syself: Syself Linux, KubeGate, and the provisioning and healing controllers. SCS draws its conformance boundary at the Kubernetes API, the layer your workloads run on.

What SCS does not require#

SCS does not require a hardware root of trust. Syself verifies the node operating system in software against a known hash. It uses no TPM and no Secure Boot. The SCS Kubernetes standard accepts the software check today.

Next steps:

• Build an SCS-compatible cluster walks through the setup, manifests, and the CNCF and SCS test suites.
• Meet compliance requirements shows how to present the result in an audit.
• Sovereignty and data residency covers who holds your account and your keys.

For how sovereignty and data residency work on the cluster, see Sovereignty and data residency .