Building the Sovereign Internal Developer Platform

An exit-by-design reference architecture for DORA, NIS2 and SecNumCloud-era platform engineering. Authored by Weave Intelligence.

Digital sovereignty stopped being a procurement preference in 2026. NIS2, DORA and the EU Data Act now require proof of provider diversification and tested exit strategies. Outside Europe, India’s DPDP Act, Brazil’s LGPD and shifting US export controls push the same direction. A sovereign Internal Developer Platform (IDP) is the architectural answer: a control plane that keeps software delivery operational even if a foreign legal, commercial or connectivity tie is severed overnight.

This whitepaper sets out the reference architecture – five planes, the tooling that earns a place in each, and the validation matrix that tells you whether your stack is genuinely sovereign or just hosted on European soil. It’s written for platform leads, CIOs and compliance owners building toward exit-by-design.

On 12 June 2026, a US export-control directive forced a frontier AI vendor to disable service for every non-American customer worldwide overnight, including EU governments mid-procurement. Any capability hosted in a single jurisdiction can be revoked on national-security grounds the affected users are never made aware of.

- Building the Sovereign IDP, Weave Intelligence (2026)

What you’ll learn from the sovereign IDP whitepaper

🎯 Why “data residency” alone fails the sovereignty test – and what the legal sandwich (CLOUD Act vs GDPR) really costs

 

🎯 The five-plane reference architecture for a sovereign IDP: developer control, integration & delivery, resource, security, observability

 

🎯 How IaC, GitOps and framework-agnostic orchestration deliver portability across SecNumCloud, hyperscalers and air-gapped environments

 

🎯 Six sovereign use cases: multi-cloud provisioning, Kubernetes, CI/CD, IAM, observability, database management

 

🎯 AI sovereignty: keeping code and IP out of foreign training pipelines with open-weight, locally hosted models

 

🎯 The sovereign validation matrix – 10 questions to audit your current platform against DORA-grade exit requirements

Frequently Asked Questions

A sovereign Internal Developer Platform is an IDP architected for exit-by-design: every component – portal, orchestrator, version control, secrets, CI/CD, observability – can be self-hosted or swapped without rewriting golden paths. Sovereignty is measured by workflow portability: whether the components that build, deploy and run your software keep working if a foreign provider, licence or jurisdiction is removed overnight. Data residency alone doesn’t deliver it.

A sovereign cloud is infrastructure operated under a single legal jurisdiction, with the corporate entity, control plane and management APIs immune to extraterritorial legal reach (such as the US CLOUD Act). In Europe, the SecNumCloud qualification is the strictest benchmark – providers like OVHcloud, Cloud Temple, NumSpot and Bleu hold it. A US-owned hyperscaler hosting data in a Paris data centre does not qualify, because the control plane remains subject to US law.

No. Open source is necessary but not sufficient. Open-core models (Backstage, Elasticsearch, HashiCorp tooling) keep enterprise features proprietary; once a team adopts the open core, lock-in returns through the commercial layer. License changes (SSPL, BSL) and hyperscaler co-option of community projects erode the assumption that “open source = portable”. The sovereignty test is whether the organisation can self-host, operate and migrate away from the tool without dependency on a single commercial entity.