In the first article of this series, I covered the infrastructure layer of a sovereign cloud platform: colocation, compute, storage, networking, and hardware security modules. These are the foundations, but, put bluntly, on their own they are little more than a collection of hardware. The real value only emerges at the platform layer. This is where the services reside that transform infrastructure into something organizations can actually use.
The question therefore shifts from what you offer to how you offer it. Scalable, secure, and operationally manageable. That sounds obvious, but in practice this is often where things go wrong.
This article describes the sovereign platform stack shown below.
The Pitfall of Pure IaaS
A sovereign platform that only provides virtual machines, storage, and network connectivity competes directly on price with the hyperscalers. That is a race you cannot win, period. AWS is estimated to operate around one and a half million servers worldwide. The economies of scale this creates are simply insurmountable for European players. Your organization’s procurement department is therefore tempted primarily by pricing, which by definition puts sovereignty under pressure.
The value of a sovereign platform therefore lies in managed services: pre-integrated, operationally managed services that take complexity away from customers. Think of databases that you do not have to patch yourself, Kubernetes clusters where the control plane is managed for you, or a secrets management solution that integrates directly with your HSM infrastructure.
The challenge is to offer a portfolio that is broad enough to remain relevant, but narrow enough to remain operationally manageable. Start lean, validate with early adopters, and expand incrementally based on the actual needs of your organization.
Databases: Why PostgreSQL Forms the Core
Databases are by far the most requested sovereign service. Almost every application requires persistent data, and professional database management is specialized work that many organizations would rather outsource.
The choice of which databases to use is not trivial. It affects licensing, operational complexity, and the degree of vendor lock-in you impose on your own organization.
Cees Berrens
PostgreSQL is the logical foundation of your sovereign database landscape for several reasons. The PostgreSQL License is permissive and places no restrictions on outsourcing or insourcing. The technology has proven itself in the most demanding production environments around the world. And the ecosystem for high availability is mature: Patroni for automatic failover combined with ETCD as a consensus store, pgBouncer for connection pooling under high concurrency, and Barman for point-in-time recovery.
MongoDB initially appears to be an attractive addition for document-oriented workloads. However, the SSPL license that MongoDB has used since 2018 requires organizations either to open-source their entire software stack or obtain a commercial license. For a platform that has sovereignty as a core value, this dependency is undesirable. FerretDB, which implements MongoDB’s wire protocol on top of PostgreSQL, offers an interesting alternative here.
Redis presents a similar licensing issue, albeit with a different outcome. In March 2024, Redis moved away from the BSD license to a restrictive dual-license model. Following strong criticism from the community, Redis nevertheless returned to open source in 2025, with AGPLv3 as an option. Despite this, Valkey—the fork launched by the Linux Foundation immediately following the license change—is the safer alternative for many providers. The BSD-3 license has no restrictions, and the community now has backing from AWS, Google, and Oracle.
Kubernetes: The Distribution Choice Matters
Kubernetes is the second pillar of a modern platform offering. The question is not whether you use Kubernetes, but which distribution you choose and how you implement multi-tenancy.
For sovereign deployments, RKE2 is a logical choice. The distribution is CNCF-conformant, ensuring compatibility with the broader Kubernetes ecosystem. More importantly for regulated environments, RKE2 is built using FIPS 140-2-validated cryptography. The GoBoring compiler and BoringCrypto module have been verified by Corsec Security, which is often a hard requirement for government customers. In addition, the distribution is hardened out of the box according to the CIS Kubernetes Benchmark and can be installed fully offline—essential for air-gapped environments.
Multi-tenancy is more complex. Kubernetes was inherently designed with single-tenancy in mind. Namespace isolation alone is insufficient for true separation between domains: a misconfiguration in RBAC or network policies can quickly result in cross-tenant access.
Cees Berrens
For enterprises with strict isolation requirements, dedicated clusters are the safest option, albeit the most expensive. For mid-market organizations, tools such as Capsule or vCluster provide better alternatives. Capsule enforces tenant boundaries through admission webhooks and gives each tenant a virtual cluster within namespaces. vCluster goes a step further by running a complete Kubernetes control plane for each tenant as a workload inside the host cluster. With more than forty million deployments and production use at organizations such as Adobe and NVIDIA, this is no longer experimental technology.
Identity Management: The Nervous System
Identity & Access Management is where the security of your platform stands or falls. Every API call, every resource access, and every audit trail runs through your identity layer. An architectural mistake here undermines all the other security measures you put in place.
Keycloak is the de facto standard for self-hosted identity providers, and for good reason. It supports all relevant protocols, offers extensive MFA options including WebAuthn/FIDO2, and has an active community.
Red Hat provides an enterprise-supported variant with RHBK (Red Hat build of Keycloak), which is the successor to the now-retired Red Hat Single Sign-On.
The architecture for multi-tenant identity requires careful choices. The approach we at Heimdallr see working best in practice is a realm-per-tenant model:
- Each customer receives its own Keycloak realm with a fully isolated user directory, client configurations, and authentication flows.
- From an architectural perspective, cross-tenant access is therefore impossible.
Enterprises also expect federation with their own identity provider—Microsoft Entra ID, Okta, or an on-premises Active Directory. You can support this through SAML or OIDC, but always retain a local credential store as a fallback. If your organization’s upstream IdP is unavailable—and that happens more often than you might expect—your platform must continue to function.
Tenant Onboarding: Automate or It Won't Scale
The speed and quality of tenant onboarding determine your operational scalability. Manual processes, service desk tickets, spreadsheets containing configuration items, and engineers manually creating resources do not scale and are error-prone. Every new tenant must be provisioned fully automatically.
A robust onboarding pipeline starts by triggering the provisioning workflow. Terraform or Crossplane then creates all tenant-specific resources: the Keycloak realm, a Kubernetes namespace with the associated quotas and network policies, a dedicated namespace in Vault for secrets, and the monitoring configuration. ArgoCD or Flux synchronizes the configuration from a Git repository, ensuring that all changes are traceable and that rollback is always possible.
With a well-automated workflow, the time from internal approval to a functioning platform can be less than thirty minutes. This is not only more efficient; it also provides a better experience than waiting weeks for manual configuration.
Compliance as a Differentiator
For a sovereign platform, compliance is not a cost center but a differentiator. You can offer security postures that hyperscalers structurally cannot provide, and for regulated sectors this can be a decisive argument.
The landscape has changed significantly in recent years. NIS2 has been in force since October 2024 and classifies cloud providers as “digital infrastructure,” with corresponding obligations: incident response within 24 hours, supply-chain security, and personal liability for directors in cases of non-compliance. Fines can reach up to ten million euros or two percent of global turnover.
For the government market, BIO2 is the relevant framework. The new version, established in September 2025, replaces the old BBN classification with a risk-based approach. Organizations determine their own risks and select appropriate measures based on ISO 27001 and 27002, supplemented by mandatory government measures.
The financial sector also has to contend with DORA, which has been in force since January 2025. Its requirements are stricter than NIS2: incident reporting within four hours, mandatory threat-led penetration testing, and documented exit strategies for all critical ICT services.
Manual compliance does not scale with this level of complexity. Policy-as-Code using Open Policy Agent, automated configuration auditing, and a SIEM such as Wazuh with out-of-the-box compliance dashboards are not nice-to-haves but necessities for remaining compliant without allowing operational costs to spiral out of control.
The core
The platform layer ultimately determines your operational scalability and your market position. The technology is available—Keycloak, Open Policy Agent, Cilium, Wazuh—and all of these technologies have been proven in production. The challenge lies in integrating them into a coherent whole that organizations actually want to use.
Three principles that we see working best in practice:
- Design API-first — the portal is a consumer, not the source of truth.
- Compliance by design — retrofitting compliance is ten times more expensive.
- Automate radically — manual processes are technical debt that charges interest.
Cees Berrens
This is the second article in a series about building sovereign cloud platforms. In the next and final installment, I will cover vertical extensions: sector-specific services for government, healthcare, and financial services, as well as the strategic roadmap toward post-quantum cryptography.
Interested in a sparring session about your sovereignty strategy? Or do you need help with architectural decisions? Get in touch through Heimdallr Professional Services.
