UK/EU Data Sovereignity Focused | S3-Compatible Object Storage: Best Options Beyond AWS

Most object storage choices look different on the pricing page and strangely similar in production. The reason is simple: the interface most teams care about is still S3-compatible object storage.

If your tooling already speaks S3, you usually don't want to rewrite backup jobs, SDK integrations, AI data pipelines, or internal services just because the backend changes. What matters then is not only API compatibility, but also licence terms, egress costs, jurisdiction, and how much operational work your team can absorb.

If you need the short version, SeaweedFS and Garage are the strongest self-hosted alternatives to MinIO right now, stack8s is the simplest managed option for GDPR-sensitive workloads, and Cloudflare R2 or Wasabi are hard to ignore when egress fees dominate the bill.

Think of S3 as the USB-C port of object storage. Once the interface is there, clients, SDKs, and workflows can move with much less friction.

Why S3 compatibility matters so much

Amazon S3 is no longer just an AWS product feature. Its API is the de-facto standard for object storage. Tools like aws cli, rclone, s3cmd, backup software, analytics jobs, and plenty of application frameworks already assume that an S3 endpoint is available.

That is why "S3-compatible" matters. In plain terms, it means a storage system exposes the same HTTP API shape as AWS S3, enough for existing tools and clients to keep working. In many cases, the change is mostly operational: point your client at a different endpoint, swap credentials, and keep the rest of the workflow intact.

This is where the real value shows up. Local development, on-prem clusters, Kubernetes workloads, edge sites, and managed cloud storage can all fit under the same access pattern. Your application doesn't need to care whether the bucket sits in AWS, a rack in your own data centre, or an EU cloud provider's storage platform.

That said, "S3-compatible" is not a guarantee of perfect parity in every edge case. Common object operations are usually the easy part. Advanced behaviour around policies, versioning, lifecycle rules, replication, or less common API calls can vary between products. The label tells you where to start, not where every implementation ends.

For DevOps teams, CTOs, and finance leaders, this is why the storage decision is rarely only about price per GB. S3 compatibility gives you portability. The harder questions are about compliance, operations, legal risk, and network egress.

The self-hosted S3-compatible options worth looking at

Self-hosted object storage still makes sense when you need hard control over data location, when compliance pushes you on-prem, or when cloud bills keep climbing past the point of reason. This is also the route many teams take when they want sovereign infrastructure without giving up standard tooling.

MinIO is no longer the default answer

MinIO became popular for good reasons. It is written in Go, fast, fairly easy to run, and historically one of the closest fits to the S3 API outside AWS. For years, it was the obvious first answer when a team asked for self-hosted object storage.

That has changed.

MinIO moved its Community Edition to the AGPL-3.0 licence and shifted to a source-only distribution model. Pre-built binaries are no longer provided for the open-source version. For production use, that means either self-compiling and accepting the legal position that comes with AGPL, or paying for a commercial licence.

The bigger issue is maintenance. The Community Edition repository was archived in February 2026 and is now read-only. No active development, no security patches, no open-source binary releases. Existing deployments do not stop working overnight, but new evaluations should treat that as a hard signal.

For new deployments, MinIO Community Edition is no longer the low-friction open-source choice it used to be.

MinIO still has name recognition, extensive documentation, and strong API compatibility in its history. But if you're choosing now, not inheriting an older platform, the conversation has moved on.

Ceph and RadosGW are built for scale, not convenience

Ceph sits at the other end of the spectrum. It is not only object storage. It also handles block and file storage, with the S3-compatible layer provided by RADOS Gateway, often shortened to RadosGW.

This is the option for very large data estates, multi-protocol storage, and environments where fault tolerance and scale matter more than simplicity. Petabyte-scale storage is normal territory for Ceph. High availability is part of the design, not an add-on feature.

The trade-off is operational weight. Ceph asks for real storage knowledge, more planning, and suitable hardware. Smaller teams often find it oversized. If your use case is a modest internal object store for application uploads or backups, Ceph can feel like bringing a container ship to move a van-load of boxes.

Still, when the requirement is "one distributed storage system that can handle serious scale and more than one protocol", Ceph stays in the shortlist.

Garage is small, lean, and strong in distributed setups

Garage is a lightweight distributed object store written in Rust. It is aimed at the situations where Ceph is too heavy and a single-node tool is not enough. That makes it interesting for small clusters, edge locations, and geographically distributed deployments.

The project is explicit about its design goals. As described in the Garage project repository, it is built for self-hosting at small to medium scale, across nodes that may live in different physical locations. That is a useful fit when you need replication across sites but do not want the full operational cost of Ceph.

Garage is also resource-efficient. That matters more than it first appears. Plenty of storage clusters are not built on ideal hardware. They are built on whatever a team can justify, fit, or keep running close to the workload.

The catch is licensing. Garage uses AGPL-3.0, so the same commercial licence questions that push teams away from MinIO can still apply here. If that is acceptable in your environment, Garage is one of the clearest options for lean, distributed, self-hosted S3 storage.

SeaweedFS is excellent when small objects dominate

SeaweedFS started with a clear strength: handling huge numbers of small files efficiently. That is still the part worth paying attention to. It has grown into a full S3-compatible object store, but its edge remains high read and write throughput, especially with many small objects.

That matters in the real world. Backup metadata, AI artefacts, research outputs, logs, thumbnails, and application-generated blobs often arrive as lots of small objects, not giant archives. Ceph has traditionally been weaker in that pattern. SeaweedFS is much more comfortable there.

Its feature set is broader than many teams expect. You get replication, erasure coding, cloud tiering, and even FUSE mounting. The licence is Apache 2.0, which removes a lot of the legal friction that appears with AGPL-based alternatives.

If you strip the category down to practical choices, SeaweedFS is one of the strongest answers for teams that want self-hosted S3-compatible storage without MinIO's current licensing and maintenance problems. It is also one of the easier options to defend in commercial environments because the licence story is straightforward.

RustFS is promising, but still early

RustFS is one of the more interesting newer projects in this space. It is written in Rust, released under Apache 2.0, and positioned directly as a MinIO alternative. The RustFS project advertises full S3 compatibility, Kubernetes support, a compact binary size, and features such as WORM compliance, active replication, versioning, and cross-cloud redundancy.

On paper, that is a strong mix. Rust brings memory safety without a garbage collector. The Apache licence is far easier to handle in commercial environments than AGPL. The project also targets multi-cloud and edge use cases, which lines up well with modern AI, analytics, and hybrid infrastructure patterns.

But the limitation is not subtle: RustFS is still in alpha. There is no stable production release, the community is small, and there is not much independent evidence yet on long-term operation at scale.

So where does that leave it? Not as the safe default for production today. More as a project to watch closely if you want an Apache-licensed, modern replacement for the role MinIO used to fill.

Kubernetes changes the equation, but it doesn't remove the storage problem

If your workloads already live in Kubernetes, it is natural to ask whether object storage should live there too. This is where Rook enters the picture.

Rook is a Kubernetes operator that manages Ceph inside the cluster. It handles deployment, scaling, and recovery through Kubernetes-native workflows, which removes a good chunk of the manual work that usually comes with Ceph. The Rook object storage documentation shows how it exposes an in-cluster object store through an S3 API.

That is a strong fit for teams that already trust Kubernetes as their operational control plane. You can run S3-compatible storage without depending on a separate external storage platform, and you keep provisioning and recovery aligned with the rest of your cluster operations.

The important caveat is that Rook makes Ceph more approachable, not simple in the abstract. Ceph is still Ceph. The architectural weight does not disappear just because the installation path is cleaner.

For Kubernetes-heavy organisations, though, Rook plus Ceph is often the right midpoint. You get serious storage capabilities, better automation, and an object store that stays close to the workloads using it.

Managed S3-compatible providers are often the practical choice

Not every team wants to run storage. Fair enough. Managed object storage removes the day-two burden, which is often where self-hosted plans get stuck.

Cloudflare R2 is the obvious name when egress charges are the main pain point. Its R2 storage service keeps the S3-compatible API and removes egress fees, which changes the economics for media delivery, public assets, and any workload that reads data out frequently. If your storage bill is inflated by outbound traffic rather than raw capacity, R2 is hard to ignore.

Backblaze B2 stays popular because the pricing is easy to follow and support across backup tools is broad. It is commonly used for backups and archives, and it works well with rclone and similar tooling. B2 is less about flashy positioning and more about being a sensible, lower-cost place to park data.

Wasabi takes a similar angle on cost, with no egress fees and no API request charges, but there is an important condition. Free egress applies only when your monthly data transfer does not exceed the amount of data stored, a 1:1 ratio. That is fine for many backup or archive patterns. It is less comfortable for heavy public delivery workloads. Wasabi is also a US-based provider, which makes it a poor fit for stricter GDPR requirements unless extra contractual measures are in place.

stack8s Object Storage is the cleanest managed option in Europe for many organisations. For teams that need UK/EU data location (more than 30 regions available in the jurisdiction) without running their own object store, that is a simple answer. It is affordable, straightforward, and much easier to explain in compliance discussions than a US provider with EU marketing wrapped around it.

How the main options compare in practice

A side-by-side view makes the trade-offs easier to spot.

The pattern is clear. Ceph is for scale, SeaweedFS is for performance with small objects, Garage is for lean distributed deployments, Rook is for Kubernetes-first teams, and stack8s is the easiest managed route when EU jurisdiction matters.

The real choice is self-hosted versus managed

The API discussion matters, but the operational model usually decides the outcome.

Self-hosted storage is the right move when you need full control over data location, when rules such as GDPR, BSI, or NIS2 push you towards on-prem infrastructure, or when you already have Kubernetes and storage expertise in-house. It also makes sense once managed cloud costs outgrow the salary and complexity of running the platform yourself.

Managed storage wins when your team does not want to become a storage operator. That is common, and often the right call. If speed matters, if the data is public or lower risk, or if the organisation wants elasticity without up-front infrastructure work, managed S3-compatible storage is usually the cleaner answer.

For AI, analytics, and research workloads, this decision gets sharper. Object storage is often where model artefacts, datasets, checkpoints, logs, and pipeline outputs accumulate. At that point, jurisdiction and egress can matter more than raw storage cost. Moving data across clouds or across borders is where bills and compliance reviews start to bite.

If you're weighing where object storage should live across on-prem, EU cloud, and hybrid AI infrastructure, you can Book a Meeting with our Infra Experts.

Pick the constraint that matters most

S3 compatibility is the easy part to appreciate and the hard part to live without. It gives you portability across tools, clouds, and self-hosted platforms, which is why it remains the default interface even outside AWS.

The harder call is choosing which trade-off you can live with. SeaweedFS and Garage are the strongest current MinIO alternatives for self-hosted use, Ceph stays the heavy option for large-scale estates, Rook makes sense for Kubernetes-native teams, and stack8s is the clean managed answer for EU-sensitive workloads.

Once you frame the decision around licence terms, operational effort, egress, and jurisdiction, the shortlist gets much smaller, and much easier to defend.