Hetzner is a European provider, so both the infrastructure and the company that operates it sit under EU jurisdiction. That answers two of the three questions sovereignty raises: where the data is stored, and whose law governs the provider. The third question is whether you can leave. Fractal Cloud answers that one: the same versioned definition used to provision a Hetzner environment provisions the equivalent environment on another provider, so choosing Hetzner does not create a new dependency.
Yes. Fractal Cloud supports production ready Kubernetes environments on Hetzner Cloud with security, resilience, and operational best practices built in. Platform Teams can standardize Kubernetes environments, while Development Teams deploy and manage applications through reusable Blueprints and automated workflows.
Fractal Cloud automates the provisioning and lifecycle management of Kubernetes environments on Hetzner Cloud. Platform Teams define reusable blueprints with built in security, governance, and operational controls, while Development Teams deploy and manage applications through standardized workflows without dealing with provider specific infrastructure details.
Yes, with one distinction worth making. Fractal Cloud recreates the target environment on the new provider from the same versioned definition, so the architecture, the policies and the operational setup come across unchanged. Application data and persistent state still have to be moved with the appropriate replication or backup and restore process. What normally makes a migration expensive is rebuilding and re-certifying the environment, and that part is already described in the Fractal.
Search "platform engineering best practices" and every list repeats the same five words: golden paths, platform as a product, less cognitive load. True, and not enough. What does a golden path look like the moment a developer clicks "create environment"? What breaks if a team skips it?Here are 10 practices with that next layer attached. Check a few against your own setup this afternoon.
A CTO watches uptime, team velocity, and the monthly cloud bill. Those three are easy to watch: they update themselves, they have dashboards, and they compare month over month without anyone building anything.Now try to answer a different question from those same three dashboards. For each production environment, how long has it been since it last matched the definition it was built from? Uptime cannot tell you. Velocity measures the code your teams ship, not the infrastructure they stopped touching. The bill goes up when things are neglected, not down, so it does not even point in the right direction.That question has a measurable answer, and almost nobody measures it.
Aligning infrastructure teams and development teams comes down, first of all, to the operating model. Tools matter, but on their own they explain little of what slows delivery down.Over the past few years almost every organization has tried to speed up delivery by adopting cloud, containers, and CI/CD pipelines. The outcome tends to repeat itself: developers want to move fast, while whoever runs the infrastructure has to guarantee security, compliance, and cost control. A structural conflict follows, where developers experience controls as a brake and Ops read team autonomy as a risk.There is a fairly precise way to measure that conflict: the cognitive load on developers, meaning how much they have to hold in their head before they can ship. When every team needs Kubernetes, Terraform, IAM policies, and the quirks of each provider, the time spent wiring infrastructure together is time taken from the product. Gartner estimates that by 2026, 80% of large software organizations will have a dedicated platform engineering team, up from 45% in 2022.The useful question, then, is how to design a system where speed and governance stop competing. It is the question Fractal Cloud was built around, and it deserves a general answer before a product one.