How to build a sovereign cloud — playbook for EU and Central Asia in 2026

Sovereign cloud is no longer a niche topic. EU member-state mandates, Kazakhstan procurement-portal sovereignty clauses, and several APAC initiatives have made sovereignty a market category. Hyperscaler “sovereign” regions try to address this but face structural limitations (US-vendor relationship, control-plane dependencies).

The opportunity for purpose-built sovereign cloud products is real — but the engineering, certification, and operational work is non-trivial.

What sovereignty actually means

Sovereignty is more than data residency. The full requirements:

1. Data residency at every layer — production, backup, observability, CI/CD, telemetry
2. Encryption with customer-controlled keys — HSM, documented rotation, emergency access procedures
3. Open-source platform foundation — transparency and exit-readiness
4. Supplier-chain transparency — to second hop minimum
5. Air-gap option for the most sensitive workloads
6. Audit-trail completeness in regulator-consumable formats
7. No phone-home telemetry — opt-in only
8. Operational independence — sovereign cloud team under sovereign jurisdiction

A “sovereign cloud” product that doesn’t satisfy all of these substantively will fail under regulator audit.

Specific sovereignty frameworks

Each jurisdiction has its own framework:

EU

• EUCS (EU Cybersecurity Certification Scheme for Cloud Services) — emerging EU-wide framework
• SecNumCloud (France) — strict French sovereign requirement
• BSI C5 (Germany) — German cloud security catalogue
• DORA — financial-services-specific, applies to cloud providers serving banks
• NIS2 — broader cybersecurity; cloud providers are an Annex I sector (essential or important entities depending on size)

Central Asia

• Kazakhstan — procurement-mandated sovereignty for public-sector workloads.
• Other CIS — various national frameworks emerging

Other regions

• France SecNumCloud outside France: increasingly referenced
• APAC — Singapore IM8, India MeitY, Australia IRAP, etc.

Architectural patterns for sovereign cloud

Pattern 1: full on-prem sovereign cloud

Customer hardware, customer-operated, customer-controlled at every layer. Maximum sovereignty; maximum operational footprint. Right for the most sensitive workloads (classified data, banking core).

Pattern 2: managed sovereign cloud

Cloud provider hardware + sovereign jurisdiction + customer-controlled keys + transparent supply chain. Operational simplification with substantive sovereignty. Right for most regulated enterprise workloads.

Pattern 3: hybrid sovereign + non-sovereign

Critical-function workloads on sovereign cloud; non-critical on hyperscaler. Common pattern in financial services.

Pattern 4: edge sovereign cloud

Sovereign cloud distributed to edge sites within jurisdiction. Right for workloads that need both sovereignty and edge proximity (IoT, telco).

Cozystack as sovereign cloud foundation

Cozystack is open-source (Apache 2.0), CNCF Project-governed (community-governed roadmap), supports air-gap deployment and opt-in volume encryption at rest (LINSTOR and LUKS) with a passphrase you hold; audit logs have configurable retention (default 30 days) and can be shipped to your own immutable store.

Specifically for sovereign cloud builders:

• Multi-tenant Tenant CRD model — for customer-facing sovereign cloud product
• Cozystack Dashboard — customer-facing self-service surface
• WHMCS billing integration — for a subscription customer-facing offering (an Ænix product on top of Cozystack, not an upstream component)
• Air-gap install supported and documented
• VictoriaMetrics + VictoriaLogs — self-hosted observability (no SaaS dependency)
• Cilium networking — sovereignty-friendly, no proprietary network platform dependency

Implementation timeline

A sovereign cloud product takes longer to build than a non-sovereign cloud:

• Discovery + assessment: free 30-minute discovery call, then a fixed-price Platform Readiness Assessment (14 or 28 days)
• Single provider at provider scale: platform live in weeks once hardware is ready, with the productized installer
• National or operator programme: a 3-6 month pilot, then 9-18 months to full multi-region operation
• Certification work: runs alongside the build; its scope can move the date of the first certified service
• Customer onboarding: ongoing

Ænix engagement

Ænix builds sovereign cloud products end-to-end, with a team of about 20 people in the EU and Central Asia. Open-source foundation. Procurement-ready documentation.

For details see the sovereign cloud builder service and Ænix Public Cloud Platform.