Sovereign Means More Than Where the Disks Sit: What OVHcloud and Scality's Joint Storage SKU Reveals About European Digital Sovereignty

On July 1, 2026, two European companies stopped arguing about digital sovereignty and shipped a product for it. OVHcloud, the French cloud provider that runs its own data centers across Europe, and Scality, the French-born object-storage vendor behind RING and ARTESCA, announced an expanded partnership with a new joint S3-compatible storage platform sold explicitly as a sovereignty product. Not a whitepaper, not a pledge, not a data-center pin on a map — a SKU.

That distinction matters more than it sounds. Until this launch, most of the European sovereignty conversation lived in grading frameworks and compliance pledges: where is the data, who can the government compel, what happens if a foreign law conflicts with a local one. OVHcloud and Scality took that abstract checklist and turned it into deployment topologies, replication guarantees, and an on-prem escape hatch. What they had to actually build to sell "sovereignty" as a specific product — rather than a marketing claim about a country code — is the most concrete answer yet to what the phrase actually requires.

Here is the upfront teardown. If a vendor tells you its storage is sovereign, these are the five dimensions a buyer now has a real product to measure that claim against:

That table is the whole post in miniature. The rest is where each row comes from, why the European Commission's own frameworks now grade exactly those dimensions, and what it implies for any self-hosted platform whose sovereignty pitch was previously "we run on Hetzner in Germany" and called it done.

What OVHcloud and Scality actually shipped​

The June 30 / July 1, 2026 announcement (GlobeNewswire, syndicated from San Francisco at 12:01 UTC) is concise about the shape of the product:

Scality's side is the storage engine. Scality RING — its scale-out object-storage system — and ARTESCA — its lighter, Kubernetes-native S3-compatible appliance — provide the S3 API, erasure coding, versioning, and lifecycle policies that make the product storage at all. Both are software-defined: they run on commodity hardware the operator provides rather than on a proprietary appliance. That software-defined character is precisely what makes the sovereignty claim architectural rather than just geographic — the storage software can run anywhere, including on hardware the customer physically controls.

OVHcloud's side is OPCP, the On-Prem Cloud Platform. OPCP is OVHcloud's packaging for running managed cloud services inside a customer's own data center or colocation facility. It adds cloud-native orchestration, a catalog of managed services, and deployment automation, all built on infrastructure that does not depend on a foreign hyperscaler underneath. Think of it as the control plane that makes "on-prem" feel like cloud without reintroducing the dependency the sovereignty product is meant to eliminate.

The joint product pairs the two: Scality's S3-compatible object storage deployed via OPCP as either a fully dedicated sovereign cloud (operated by OVHcloud in its own EU data centers, but isolated per tenant) or as a genuinely on-prem installation where the data lives on hardware in the customer's own building, administered through the same OPCP tooling. Both options include backup replication across multiple availability zones.

The target customers named in the announcement are the ones where sovereignty is not a preference but a procurement requirement: healthcare, finance, defence, and public services — sectors where a French hospital, a German bank, or a ministry cannot put regulated data on infrastructure that a non-EU government could compel through its own courts.

The line in the announcement that does the most work is also the shortest: "with no dependence on third-party hyperscalers." That phrase is doing sovereignty work across all five dimensions at once. It is not enough for the data to be in Europe if the software, the control plane, or the replication path still routes through a US-headquartered hyperscaler whose legal obligations follow the corporate parent.

Why "where the disks sit" was never enough​

The instinctive reading of "data sovereignty" is geographic: is the data in France, Germany, the EU? That reading is necessary but nowhere near sufficient, and the history of European sovereignty frameworks is essentially the history of learning why.

Legal sovereignty is the first extension beyond geography. A data center in Frankfurt operated by a US-headquartered provider is physically in the EU but legally reachable by US courts under statutes like the CLOUD Act, which can compel a US company to produce data it controls regardless of where that data physically resides. EU regulators and courts have spent a decade wrestling with whether contractual or corporate-structure fixes can actually cure that exposure. The answer that has gradually emerged — from Schrems II through the series of adequacy and transfer-framework negotiations — is that structure matters less than control, and "we have an EU subsidiary" is not control.

Operational sovereignty is the second. Even if the disks and the legal entity are both European, who holds the keys, who can push a software update, who can staff the night shift that reboots the storage cluster at 3 a.m.? If operational access or privileged tooling depends on personnel or systems outside EU jurisdiction, the sovereignty guarantee has a trapdoor. The OVHcloud × Scality product addresses this by keeping the orchestration (OPCP) itself free of hyperscaler dependencies — the tooling that administers the storage does not phone home to a control plane in another jurisdiction.

Supply-chain and technology sovereignty is the third. Sovereignty frameworks increasingly score whether the underlying technology — the storage software, the hypervisor, the network stack — is itself subject to a foreign export restriction or licensing condition that could be weaponized. Scality is a European-headquartered vendor; RING and ARTESCA do not carry the same supply-chain dependency as a storage layer built on top of a US hyperscaler's proprietary service.

Exit sovereignty — the right to leave — is the most overlooked and the most practical. A storage product that is sovereign in every other dimension but requires a multi-month, vendor-assisted export to actually leave is sovereign in the way a hotel room is yours: fully, until you try to take it with you. The on-prem option in the OVHcloud × Scality product inverts this: the data starts on the customer's hardware, so exit is not a feature to be exercised later but the initial condition.

None of these dimensions is exotic. Each one has a recent European policy fight behind it where a simpler reading of sovereignty failed in practice. The product is notable precisely because it treats that full checklist as product requirements rather than as talking points.

Why now: from voluntary grading to mandatory scoring​

The OVHcloud × Scality product did not land in a vacuum. It landed in a European policy window where sovereignty stopped being a voluntary self-assessment and started becoming a procurement filter.

The Cloud Sovereignty Framework (September 2025) introduced the vocabulary that everyone now uses. It defines eight sovereignty objectives — spanning strategic, legal, data, operational, supply-chain, technology, security, and environmental dimensions — and scores each one on a Sovereignty Effectiveness Assurance Level (SEAL) from 0 to 4:

• SEAL-1: Jurisdictional Sovereignty — EU law is at least applicable.
• SEAL-2: Data Sovereignty — EU law applies and data handling meets defined thresholds.
• SEAL-3: Digital Resilience — EU actors exercise meaningful influence over operations, with only marginal non-EU control.
• SEAL-4: Full Digital Sovereignty — technology and operations are under complete EU control, with no critical non-EU dependencies.

A service can score differently on each objective, and the meaningful score is the weakest link — a SEAL-4 on data residency paired with a SEAL-1 on operational control is not a sovereign service, it is a European data center with a non-European admin panel.

The Sovereign Cloud Framework clarification (June 1, 2026) made two things explicit: the scoring methodology behind each SEAL, and the fact that the European Commission was already using the framework to buy for itself. In April 2026 the Commission awarded a €180 million contract to procure sovereign cloud for EU institutions across four providers — a concrete demand signal that sovereignty-compliant capacity has a funded buyer, not just a grading rubric.

The Cloud and AI Development Act (CADA), proposed June 3, 2026, is the step that turns grading into law. CADA establishes a four-level assurance framework tied directly to public procurement. At the most sensitive tier — critical government and infrastructure workloads — US hyperscalers would be barred from competing outright, not merely scored lower. At lower tiers, SEAL scores become minimum eligibility thresholds: fail the threshold, fail the tender. The legislative train is moving through the European Parliament and Council through late 2026, but the direction is already set: voluntary self-assessment is becoming a pass/fail procurement gate.

The OVHcloud × Scality announcement references this window even when it does not name every instrument. The language — "100%-dedicated sovereign cloud," "on-premises via OPCP," "multi-AZ backup replication," "no dependence on third-party hyperscalers" — maps directly onto SEAL dimensions. The product is not just compatible with the framework; it reads as if it were specified against it.

That is the deeper signal. When two established European vendors judge that "we are headquartered in the EU" is insufficient on its own and instead ship a dedicated sovereign product with distinct deployment topologies and replication guarantees, they are telling you what the procurement market has already told them: the old pitch does not clear the new bar. A generic EU data center is SEAL-2 at best. The new product is aiming for SEAL-3 or SEAL-4 across more objectives — and it needs the on-prem option to do it.

The honest gaps — what one SKU still doesn't solve​

A sovereignty-graded storage product is a real step, but it is not a finished sovereignty stack. Naming the gaps is part of taking the product seriously.

Storage is one layer. A sovereign object store does not make the compute, the network, or the identity provider that sits next to it sovereign. An app that stores blobs on Scality RING via OPCP but runs its API on a US-owned serverless platform and authenticates through a US identity provider has sovereign storage holding data for a non-sovereign app. Full-stack sovereignty remains a composition problem — storage, compute, orchestration, observability, and identity each have their own SEAL scores, and the weakest one still governs.

On-prem is not free. The on-prem deployment option is the strongest sovereignty claim and also the most operationally demanding. Someone has to rack the hardware, keep the building powered and cooled, and staff the maintenance window. OPCP reduces that burden by providing managed orchestration on-prem, but it does not eliminate the fundamental tradeoff that "the data never leaves your building" also means the building and its operations are your problem. Teams that choose the on-prem path are trading one sovereignty cost (legal exposure) for another (operational ownership).

Interoperability still matters. A sovereignty product that locks a customer into a single vendor's S3 dialect or management API has replaced one dependency (a foreign hyperscaler) with another (a single European vendor). The announcement emphasizes S3 compatibility — which is the right call — but long-term sovereignty also depends on whether data and workloads can move between European providers without a rewrite. Projects like Gaia-X and federated approaches such as Virtuora are trying to solve that portability layer; a single storage SKU does not.

Certification is still catching up. The SEAL methodology, the CADA assurance levels, and the procurement thresholds are all new enough that no product has yet been through a full formal assessment at the highest levels. The OVHcloud × Scality product is clearly designed for high SEAL scores, but the certification and audit machinery that would assign those scores is still being stood up. Until then, buyers are evaluating design intent as much as verified compliance.

None of these gaps diminishes the product. They locate it correctly: a necessary storage layer in a larger stack that Europe is still assembling, not a turnkey answer to a question that spans infrastructure, law, and procurement at once.

What this means if you already self-host​

If you run a PaaS on machines you own — a Cluster API fleet on Hetzner, OVHcloud, or Scaleway hardware, with your own control plane and no hyperscaler in the critical path — much of the OVHcloud × Scality checklist will sound familiar. You already made the core sovereignty bet: the hardware is yours, the jurisdiction is the one where the data center's concrete sits, and no foreign corporate parent can be compelled to hand over data it does not hold.

What the OVHcloud × Scality product still clarifies for self-hosters is how to talk about that bet in the language procurement now uses:

• Name the deployment topology. "We run on Hetzner" is not a topology. "Single-tenant fleet on EU bare metal, control plane on the same hardware, with an on-prem option via the same Cluster API provider" is — and it maps directly to the SEAL dimensions a buyer is now scoring.
• Show the replication and backup path. Multi-AZ replication that stays inside EU-operated infrastructure is a stronger claim than "we back up to S3" when that S3 is operated by a US hyperscaler. The same logic applies to a self-hosted fleet: where do the backups go, and who operates the backup target?
• Keep the S3 API honest. S3 compatibility — which Scality provides — is also the API a self-hosted fleet typically fronts with MinIO, Garage, or SeaweedFS. The lesson is not which implementation to pick but that the API surface itself is part of the sovereignty story: an app written against vanilla S3 can move between providers, while one coupled to a proprietary storage API cannot.
• Operational control needs receipts. "We operate it ourselves" is stronger when the tooling that performs the operation is itself free of external dependencies. A fleet managed through Cluster API plus CAPH (or CAPMOX for Proxmox) with no managed-service control plane phoning home to a non-EU provider is making the same claim OPCP makes — but it needs to be stated, not assumed.

The broader point is that sovereignty is no longer a vibe that self-hosting gets credit for by default. It is a graded set of dimensions with funded procurement behind it. The OVHcloud × Scality product is useful to self-hosters precisely because it makes that grading explicit: the same checklist that specifies a sovereign storage SKU can specify a sovereign fleet, and a team that can already answer each row is further ahead than it may have realized — provided it writes the answers down.

Sovereignty turned out not to be a single property of a cloud — not "is the data in Europe" — but a stack of guarantees about law, operations, technology, and exit, each with its own failure mode. For several years the European conversation about that stack lived in frameworks and whitepapers that scored the dimensions without yet shipping infrastructure that satisfied them. The OVHcloud × Scality product is the first time two established European vendors productized the full checklist into a specific SKU with two deployment topologies, multi-AZ replication, and no hyperscaler in the path — and the fact that they had to build that much to credibly sell the word "sovereign" is itself the lesson.

The pattern is worth naming: every time a sovereignty narrative matured from marketing to procurement — from the voluntary Cloud Sovereignty Framework to the €180 million sovereign-cloud tender to the CADA assurance levels that would bar the lowest-scoring providers from the most sensitive tenders — the vague pitch got replaced by a more specific product. OVHcloud and Scality did not ship a sovereignty product because sovereignty became fashionable. They shipped one because customers with regulated data are about to be scored on it, and "we are European" stopped being a complete answer.

For teams that already self-host on EU hardware, the takeaway is not to buy this particular storage product (though some will) but to borrow its checklist. The five dimensions in the opening table — residency, operational control, topological choice, resilient replication, and reversibility — are the same five a Cluster API fleet needs to document whether its own sovereignty claim is SEAL-2, SEAL-3, or something it has not yet earned. The bar moved from where the disks sit to how the whole stack is operated, replicated, and exited. That new bar is higher, but at least it is finally written down — and for once, there is a real product to measure it against.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. No hyperscaler in the critical path, no per-GB egress meter, and an API any agent can call. Star the repo on GitHub or deploy your first app today.