rapidsolutions
Book a call
June 2, 2026

Sovereign storage: software-defined and object storage for private cloud

sovereign storageobject storagesoftware defined storageprivate cloudCephS3 compatible storagedata residencyopen sourceEU data sovereigntyKubernetes storage

Storage is where most private cloud projects quietly succeed or fail. Compute is easy to reason about and easy to replace. Networking is well understood. Storage is the layer that holds your state, carries your compliance obligations, and is the hardest thing to migrate once it is full. If you are building a sovereign or private cloud, storage is the foundation and usually the deepest part of the build.

This is a vendor-neutral walk through what sovereign storage actually means, the layers you need to design for, and an honest map of the open-source options. We build these systems for a living and we do not sell a storage product, so the goal here is to help you choose well, not to push a stack.

Why storage is the hard part

Three things make storage the difficult corner of a private cloud.

First, it is stateful. You can drain and rebuild a compute node in minutes. You cannot do that with the only copy of your data. Every design decision around replication, erasure coding and backup is a decision about how much data loss and downtime you can tolerate.

Second, it is where sovereignty gets real. A workload running in an EU data centre still leaks sovereignty if the storage layer is operated by an entity subject to foreign disclosure law. Data residency and data sovereignty are not the same thing. Residency is where bytes physically sit. Sovereignty is who has legal and technical control over them. Data held in a Frankfurt region of a US-operated hyperscaler can still fall under the US CLOUD Act, which can compel a US company to produce data regardless of where it is stored. The EDPB has been explicit that strong encryption with keys held solely under EEA control is the supplementary measure that addresses this exposure. Storage is exactly where you implement that control.

Third, it is unforgiving operationally. Distributed storage systems have failure modes that only appear at scale or under load: split-brain, slow rebuilds, write amplification, full-cluster conditions. Getting this right needs deliberate design, not defaults.

The three layers: block, file, object

A complete private cloud usually needs all three storage types. They are not interchangeable.

Block storage presents raw volumes to a host, like a virtual disk. It is what virtual machines and databases want: low latency, random read and write, single-writer semantics. Block is the backbone for hypervisor workloads and stateful Kubernetes pods.

File storage presents a shared POSIX filesystem that many clients can mount at once. It fits shared application data, home directories, media pipelines and legacy software that expects a path on disk. The trade-off is that distributed POSIX semantics are genuinely hard, so file systems tend to be the most complex tier to operate well.

Object storage presents data as objects in flat buckets, accessed over HTTP with an S3-style API. There is no in-place overwrite and no filesystem hierarchy. In exchange you get effectively unlimited horizontal scale, built-in metadata, and a clean fit for backups, data lakes, logs, AI training corpora and application assets. Object storage is the natural home for the bulk of unstructured data, which is why it sits at the centre of most sovereign storage designs.

Software-defined storage, briefly

Software-defined storage (SDS) decouples the storage logic from the hardware. Instead of a proprietary appliance, you run open software across commodity servers and let it handle placement, replication and healing. That is what makes sovereign storage achievable: the intelligence is open, auditable and yours, and the hardware is interchangeable. The cost is that you own the operational complexity, either with your own team or through a managed-services partner.

Two data-protection strategies run through everything below:

  • Replication keeps N full copies of each piece of data. Simple, fast to recover, but storage-hungry: 3x replication means 3 TB of raw disk per 1 TB of usable data.
  • Erasure coding splits data into chunks plus parity, so you survive failures while using far less raw capacity. A typical erasure profile gives you similar resilience to 3x replication while needing roughly 1.5x raw capacity. The trade-off is more CPU, slower small writes, and longer rebuilds.

A broad map of open-source options

There is no single right tool. The right choice depends on scale, the protocols you need, your team’s depth and where the workload lives. Here is an honest landscape.

Ceph is the reference unified SDS platform. One cluster serves all three layers: RBD for block, CephFS for file, and the RADOS Gateway (RGW) for S3- and Swift-compatible object storage. It scales to petabytes, supports replication and erasure coding, and self-heals. The cost is real operational complexity, it is the most demanding system here to run safely, and it is hungry for RAM and CPU. Rook is the operator that runs Ceph natively inside Kubernetes and removes much of the day-two toil. Ceph is the default answer when you want one platform for everything at scale.

LINSTOR with DRBD takes a different path: kernel-level block replication, essentially synchronous RAID-1 across servers, orchestrated by LINSTOR. It delivers near-native disk performance with very low overhead, which makes it strong for latency-sensitive databases and VMs. It is block-only, and setup involves kernel modules and LVM, so it is less plug-and-play. Piraeus brings LINSTOR to Kubernetes.

For S3-compatible object storage specifically, the field has shifted recently and worth knowing:

  • MinIO was the default lightweight S3 server for years. Its community edition is now effectively end-of-life: the admin console was stripped out, binary distribution stopped, and the GitHub repository was archived in February 2026. The AGPL license it adopted means the code can be (and has been) forked, but the upstream community edition is no longer maintained. Treat existing deployments as needing a migration plan.
  • Garage is a lightweight, distributed object store designed for geo-redundant deployments across separate sites. No master node, all peers, zone-aware replica placement, runs on modest hardware and ARM. Excellent for multi-site and edge sovereignty. AGPL-3.0.
  • SeaweedFS is mature, fast, and especially good with very large numbers of small objects. It offers S3, FUSE and WebDAV, has solid Kubernetes integration, and is Apache-2.0 licensed. A strong general-purpose choice at scale.

For Kubernetes-native persistent volumes:

  • Longhorn is the simplest distributed block storage for Kubernetes: easy to run, good UI, snapshots and backups built in. Best for edge and small-to-mid clusters; latency can spike under heavy load.
  • OpenEBS is modular; its Mayastor engine gives high IOPS with lower CPU cost than Ceph, focused on block, without object features.

For the storage substrate itself:

  • ZFS is the gold standard local filesystem: checksumming, snapshots, compression, native encryption. It underpins many of the systems above as the per-node layer.
  • GlusterFS is a scale-out network filesystem still found in production, though momentum has clearly moved toward Ceph and object-first designs for new builds.

S3-compatible storage as the sovereign alternative to AWS S3

The S3 API has become the de facto standard for object storage, which is good news for sovereignty. Because so much software speaks S3, you can run an S3-compatible store on your own infrastructure (Ceph RGW, Garage, SeaweedFS) and keep the same application code, the same backup tooling, the same data-lake engines, while your data stays in your jurisdiction under your keys. You get the developer ergonomics of S3 without the legal exposure of a foreign-operated cloud. This is the single highest-leverage move in most sovereign storage designs.

Encryption, key control and residency

Sovereignty is enforced at the key boundary, not the data-centre wall.

  • Encryption at rest should be on by every layer that supports it, from ZFS up through the object gateway.
  • Key control is the point. If a third party can decrypt your data, you are not sovereign no matter where the disks live. Hold keys in an EU-controlled KMS or HSM, separate from the storage operator, so no foreign entity can compel disclosure of usable data.
  • Residency still matters: pin placement to EU regions and prove it. But residency without key control is theatre.

Backup and disaster recovery

Replication is not backup. It faithfully copies your mistakes. A real sovereign storage design has independent backups (ideally immutable, object-lock style) and a tested DR plan: cross-site replication for object data, snapshot-based recovery for block and file, and regular restore drills. The failure you have not rehearsed is the one that will hurt.

Self-run or managed

Open-source SDS removes the licence lock-in, not the operational burden. The honest split:

  • Self-run when you have a storage-capable platform team and want full control. Budget for real on-call and deep expertise; Ceph in particular punishes thin staffing.
  • Managed when you want sovereign, open-source storage but not a 3am pager for a degraded cluster. A vendor-neutral partner can design, build and operate the stack on your infrastructure, in your jurisdiction, with your keys, and hand it back whenever you want it.

FAQ

Is object storage enough on its own? Rarely. Object covers the bulk of unstructured data, but VMs and databases need block, and shared application data often needs file. Most private clouds run all three.

Ceph or something lighter? Ceph if you want one platform for block, file and object at scale and can staff it. Lighter, single-purpose tools (Garage or SeaweedFS for object, Longhorn or LINSTOR for block) are easier to run when you do not need a unified platform.

Does S3-compatible mean exactly like AWS S3? The core API is broadly compatible, which is why migrations are usually smooth. Edge features and consistency guarantees vary, so validate the specific operations your applications depend on.

What about the MinIO situation? The community edition is no longer maintained as of early 2026. Existing users should plan a migration to a maintained alternative or a supported fork.

Where Rapid Solutions fits

We are a vendor-neutral engineering consultancy and managed-services partner, not a cloud provider. We design and operate sovereign, open-source-first storage on infrastructure you control, with EU data residency and keys that stay in your hands. We adapt to your stack rather than selling you ours.

If you are planning a private cloud or rethinking where your data lives, talk to us.