Evaluating a Private S3 Alternative: What Self-Hosted Object Storage Actually Buys You

If you're an engineer weighing storage backends right now, the landscape has shifted underneath you. The default private S3 alternative that most teams reached for is gone. MinIO's open-source edition has been archived. The EU is about to ban egress fees entirely. And the legal basis for sending European personal data to US-hosted services is, at best, shaky. This is a genuine inflection point, not a marketing angle. The question of whether enterprise private cloud storage is worth the operational cost has a different answer in 2026 than it did two years ago.

Key Takeaways

• MinIO's open-source repository was archived in early 2026, removing the default self-hosted S3-compatible option and forcing teams to re-evaluate SeaweedFS, Garage, Ceph, or commercial alternatives.
• "Private" storage is a spectrum across four axes: legal jurisdiction, physical residency, encryption-key custody, and inference-time data flow. Getting one right and ignoring the others doesn't actually protect you.
• Self-hosted object storage eliminates egress fees and gives you cost predictability, but you inherit full responsibility for durability, patching, and capacity planning.
• The EU Data Act will ban switching and egress fees entirely from January 12, 2027, changing the economic math for repatriating data from hyperscalers.
• Data residency and data sovereignty are not the same thing. Storing data in Frankfurt on a US-incorporated provider's infrastructure does not give you sovereignty.

Why Did the Default Self-Hosted Option Disappear?

MinIO was the answer most teams gave when asked "what do you use for S3-compatible self-hosted storage?" It was fast, well-documented, easy to deploy, and AGPL-licensed. Then through 2025, the company pivoted toward AIStor, a commercial product targeting AI workloads. Features were stripped from the community edition. Container images were pulled from public registries. By early 2026, the GitHub repository was archived and made read-only, with no new features, no community contributions, and no guaranteed security patches.

This matters beyond MinIO itself. Many teams adopted self-hosted object storage specifically because it felt like the privacy-safe, vendor-independent choice. MinIO's arc is a cautionary tale: self-hosted does not mean future-proof. Operational sovereignty requires evaluating a vendor's business model and license trajectory, not just where the bytes sit today. A storage layer that goes read-only on GitHub leaves you patching your own CVEs or migrating under pressure, neither of which is fun.

What Are the Actual Alternatives Now?

The field has reopened. Here's what's credible for teams that need an S3-compatible API and want to self-host:

SeaweedFS is Apache 2.0 licensed, written in Go, and built on an architecture inspired by Facebook's Haystack paper. It handles billions of small files efficiently and has an active maintainer community. If your workload is heavy on small objects (logs, embeddings, image thumbnails), it's the most commonly cited replacement.

Garage is a Rust-based, AGPLv3-licensed project built by the French collective Deuxfleurs. It targets a different niche: small self-hosters running geo-distributed storage on modest hardware. If you're running three nodes across two apartments and a friend's basement, Garage was designed for you. It's not trying to compete at enterprise scale.

Ceph (via its RADOS Gateway) remains the heavy-duty option. It's battle-tested, supports S3 and Swift APIs, and handles petabyte-scale deployments. The tradeoff is operational complexity. Running Ceph well requires dedicated expertise. Most teams that choose Ceph either have a storage engineer on staff or accept that they're about to hire one.

Commercial options exist too. Cloudian and Scality offer enterprise S3-compatible storage with support contracts. Wasabi provides hosted S3-compatible storage with no egress fees but is not self-hosted, so it doesn't address jurisdiction concerns. Each sits at a different point on the control-versus-convenience spectrum.

Is Cloud Storage Private?

Not inherently, and the word "private" does a lot of hiding here. When AWS or GCS says your data is "private," they mean access-controlled: no one can read your bucket without credentials. That is a different claim than "no one can be compelled to hand over your data by a foreign government."

The distinction is between data residency and data sovereignty. Even if your data never leaves Europe, if your cloud provider is US-incorporated, the CLOUD Act allows US law enforcement to compel that provider to hand over data stored anywhere in the world, including EU data centers. Amazon, Microsoft, Google, IBM, Oracle: all are subject to this. Storing objects in eu-west-1 does not give you sovereignty. It gives you residency.

For many workloads, residency is sufficient. If you're storing public assets or non-regulated data, the jurisdictional question is academic. But if you're handling health records, financial data, or EU personal data that falls under GDPR, the distinction is load-bearing. Your compliance team will care even if your engineering team does not.

What Does Self-Hosting Actually Buy You Over S3 or GCS?

Three things, and they're concrete enough to evaluate against your specific situation.

Cost predictability and no egress tax

AWS S3 charges roughly $0.023/GB-month for standard storage, plus approximately $0.09/GB for data transfer out to the internet. Moving 5 TB out costs around $450. Self-hosted storage on your own network has zero egress fees because the data moves over infrastructure you already pay for. The storage cost becomes a one-time hardware purchase (or a predictable lease), not a meter that runs every time a pipeline reads a file.

This matters most for workloads with high read-to-write ratios. If you write data once and read it rarely (cold archives, backups), S3's pricing is hard to beat. If you're running ML training jobs that scan the same dataset repeatedly, or serving assets from a CDN origin, egress fees can dwarf storage costs within months.

Jurisdiction and key custody

Self-hosting on your own hardware means you control the physical location and the encryption keys. No third party can be compelled to hand over data they don't have access to. This is the strongest version of "private" available: you are the only party with the keys, and no legal mechanism can compel a non-existent intermediary.

The partial version of this is a regional or sovereign cloud provider incorporated in your own jurisdiction. The sovereign cloud market is roughly $80 billion in 2026, growing at about 35.6% year-on-year, precisely because enterprises want this middle ground between hyperscaler convenience and full self-hosting.

Air-gap capability

Some environments (defense, critical infrastructure, certain healthcare systems) require storage that is physically disconnected from the internet. No cloud provider, by definition, can offer this. Self-hosted object storage is the only option for air-gapped deployments.

When Is Self-Hosting Not Worth the Operational Cost?

Often. This is the part that most "self-host everything" articles skip.

Self-hosted durability is entirely the operator's responsibility. AWS guarantees 99.999999999% (eleven nines) durability on S3. That number represents decades of engineering in erasure coding, cross-region replication, and silent data corruption detection. If you self-host, you own all of that. Your erasure coding configuration, your disk replacement SLA, your monitoring for bit rot. Most teams underestimate this. A three-node cluster with replication factor 3 is not eleven-nines durable. It's maybe five or six nines if you're diligent about replacing failed drives promptly.

Operational burden scales with cluster size. At 10 TB, self-hosted storage is a weekend project. At 500 TB, it's a full-time job. At 5 PB, it's a team. If your core product is not storage, every hour spent on disk failures and capacity planning is an hour not spent on what you actually ship.

If you don't have a regulatory or jurisdictional requirement that forces self-hosting, and your egress costs are manageable, S3 or GCS is probably the right answer. The operational cost of self-hosting is real and ongoing. Don't take it on for philosophical reasons alone.

How Does the EU Data Act Change the Economics?

Substantially, and on a fixed timeline. The EU Data Act became applicable on September 12, 2025. From that date, switching fees and egress fees were permitted only as "cost-covering charges." Starting January 12, 2027, cloud providers in the EU will no longer be allowed to charge switching fees or egress fees at all.

This changes two calculations. First, the cost of getting out. If you're currently on S3 and considering repatriation, the egress bill for moving your data out drops to zero in January 2027. That removes the single largest financial barrier to switching storage backends. Second, the cost of staying. If egress is free, the ongoing cost advantage of S3 over self-hosted storage narrows to just the per-GB-month storage fee. For read-heavy workloads, the savings from self-hosting shrink considerably once egress is off the table.

Hyperscalers are already adjusting. Some have preemptively waived egress fees for full account exits. The practical effect is that if you're in the EU and evaluating a migration, the window between now and January 2027 is the planning phase. The cost barrier disappears on a specific date.

Why Is Data Sovereignty Now an Architecture Constraint, Not Just a Policy?

Because the legal landscape has fractured in ways that affect system design, not just procurement.

The EU-U.S. Data Privacy Framework collapsed in late 2025 when the European Court of Justice invalidated its adequacy decision. This left organizations without a clear legal mechanism for transferring EU personal data to US-based services. If your storage backend is in the US, or your storage provider is US-incorporated, you may not have a valid legal basis for storing EU personal data there at all.

Separately, at least 34 countries have enacted or strengthened data localization requirements that restrict where AI processing can occur. This isn't just about storage anymore. If you're running RAG pipelines, fine-tuning, or inference on data stored in your object store, the compute that touches that data is also subject to residency and sovereignty rules. Sovereignty is now an architecture constraint spanning training, fine-tuning, and inference, not just a question of where the bytes sit at rest.

This is why evaluating storage backends in isolation is insufficient. You can self-host your object storage on hardware you own in a jurisdiction you control, but if your inference pipeline sends that data to a frontier provider's API endpoint in Virginia, you've created the exact jurisdictional exposure you were trying to avoid. The storage layer is necessary but not sufficient. The real question is whether any part of your data pipeline touches a jurisdiction or vendor with legal backdoor exposure.

What About Enterprise Private Cloud Storage Specifically?

Enterprise private cloud storage typically means one of three things, and they have very different risk profiles:

On-prem hardware running an S3-compatible layer (Ceph, SeaweedFS, or a commercial product like Scality). Maximum control, maximum operational burden. You own the disks, the network, the keys, and the patching schedule.

A hosted private cloud from a regional provider. Companies like OVHcloud, Hetzner, or Scaleway (all EU-incorporated) offer S3-compatible object storage where both the hardware and the legal entity sit in the EU. You get most of the convenience of a managed service without CLOUD Act exposure. The tradeoff is that these providers are smaller, may have fewer regions, and their durability guarantees are typically less battle-tested than AWS.

A dedicated tenancy on a hyperscaler. AWS Outposts, Azure Stack, GCP Distributed Cloud. The hardware sits in your data center, but the software and support come from a US-incorporated company. This gives you physical residency but does not solve sovereignty for CLOUD Act purposes. It's a common enterprise choice and a common enterprise mistake when sovereignty is the actual requirement.

For teams building AI products that handle regulated data, option two is gaining traction fastest. The sovereign cloud segment's rapid growth reflects enterprises concluding that full self-hosting is too expensive and hyperscaler dedicated tenancy doesn't actually solve the legal problem.

How Should You Evaluate Storage Backends After MinIO?

Start with your actual constraints, not your preferences. Here's a decision framework that's honest about the tradeoffs:

1. Do you have a hard jurisdictional requirement? If yes, eliminate any option where the provider is incorporated in a jurisdiction that has compelled-disclosure laws reaching your data. This rules out US hyperscalers for EU personal data, regardless of region selection. Self-host or use a provider incorporated in your jurisdiction.
2. What's your egress pattern? If you write once and read rarely, the cost case for self-hosting is weak. If you read heavily (ML training, analytics, asset serving), calculate your projected egress bill on S3 for 12 months. If it exceeds the cost of hardware plus one engineer's time, self-hosting starts to pencil out.
3. What's your durability requirement? If you need eleven-nines durability and can't staff a storage team, you need a managed service. If you can tolerate six or seven nines (common for data that exists in multiple systems and can be re-derived), self-hosting on a three-to-five node cluster with erasure coding is viable.
4. What's your operational capacity? Be honest. A self-hosted object store needs monitoring, alerting, capacity planning, firmware updates, disk replacement, and security patching. If you're a team of four and storage is not your product, the hidden cost is real and ongoing.
5. Does your data pipeline extend beyond storage? If you're sending stored data to an inference API hosted by a frontier provider, your storage-layer sovereignty doesn't cover the full data flow. Map the entire pipeline before deciding where to invest in control.

What Does "Private" Actually Mean for AI Workloads?

For AI products specifically, "private" has to cover more than the storage layer. Your object store might hold training data, user uploads, model weights, or retrieval corpora. Each of these has a different sensitivity profile and a different exposure surface.

Training data at rest is a storage problem. Encryption-key custody and physical residency matter here. Data in transit to an inference endpoint is a network and jurisdiction problem. Data processed by a model during inference is an entirely separate problem: the model provider sees the input, which means storage-layer encryption doesn't protect it during processing.

This is why we think about privacy as a per-path property at Selina. A file uploaded through SelinaSEND is zero-knowledge, end-to-end encrypted. The storage layer never sees plaintext. But memory (the adaptive context Selina maintains across conversations) is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference time. Being precise about which paths carry which guarantees is the only honest approach. Claiming "everything is encrypted" without specifying the path is marketing, not engineering.

The same logic applies to your object storage evaluation. "Our storage is private" is not a meaningful claim unless you specify: private from whom, at what layer, and during which operations.

Is 2026-2027 Actually a Good Time to Move?

The timing argument is unusually strong right now, for structural reasons rather than hype reasons.

Three things are converging. The economic barrier to leaving hyperscalers (egress fees) is being legislated away in the EU. The legal basis for US-hosted EU data processing is unsettled after the DPF invalidation. And the default self-hosted option (MinIO's community edition) has disappeared, forcing a re-evaluation that was going to be painful whenever it happened.

If you were going to re-evaluate your storage backend eventually, the forcing functions have arrived. The EU AI Act's Article 10 data governance enforcement began August 2, 2026, with fines up to €35 million or 6% of global annual turnover for high-risk AI systems lacking documented data governance. If your AI product is classified as high-risk and your data governance story involves "we store everything on S3 in us-east-1," that's a conversation you want to have proactively rather than reactively.

The business case and the compliance case are pointing in the same direction at the same time. That doesn't happen often. When it does, it's worth acting on.

A Practical Starting Point

If you're evaluating today, here's a minimal viable approach:

Pick SeaweedFS or Garage for a proof-of-concept, depending on your scale. Deploy on three nodes with erasure coding. Run your existing S3 workload against it for two weeks. Measure throughput, tail latency at p99, and operational interrupts (disk failures, OOM events, upgrade friction). Compare the total cost of ownership, including your team's time, against your current cloud storage bill plus projected egress.

If the numbers work and you have the operational capacity, migrate. If they don't, consider a sovereign cloud provider in your jurisdiction as the middle ground. Either way, map your full data pipeline, not just the storage layer, because a private object store feeding a US-hosted inference API is sovereignty theater.

The storage layer is the foundation. It is not the whole building.

If you're building an AI product and want to see how we handle per-path encryption and adaptive memory without claiming more than we deliver: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io