MinIO is archived: the self-hosted S3 alternatives worth using

MinIO just went read-only. The community repo was archived on April 25, 2026, after a messy few months: maintenance mode declared in December 2025, a first archive in February, a brief unarchive, then locked for good. If you're running it today, it still works. But you're now on software that gets no new features, no compatibility fixes, and no promised security patches. MinIO's own answer is to buy their AIStor product.

So if you self-host object storage, or you're about to, you need a plan. Here are the three replacements actually worth your time, and how to pick.

Why MinIO fell out of favour

Nothing broke technically. MinIO is fast, mature, and still one of the better self-hosted object stores ever shipped. The trouble is the paperwork.

The license moved to AGPL-3.0. That one letter matters. If you run MinIO as the storage backend inside a product or service that isn't itself AGPL, you need a commercial license. For a lot of teams that's not about the money. It's the uncertainty. AGPL gets a red flag from legal departments no matter how defensible your specific use is, and nobody wants that conversation mid-project.

On top of the license, MinIO keeps tilting toward big enterprise buyers. The features and docs follow the money. If you just want simple storage for a modest setup, you're no longer the customer they're building for.

What "S3-compatible" actually means

Before comparing anything, kill the assumption that S3-compatible is a yes/no property. It isn't.

The basic calls (PutObject, GetObject, DeleteObject, ListBuckets, ListObjects) work almost everywhere. The pain starts with the less common stuff: multipart uploads at specific part sizes, Object Lock, Bucket Versioning, server-side encryption, pre-signed URLs with particular parameters. If your app or tooling leans on any of those, check it explicitly before you commit. I've been burned by assuming versioning was there when it wasn't, and finding out during a restore is the worst possible time.

The other things that decide real-world pain: how the system spreads data across nodes and survives a node dying, whether it ships a proper Helm chart for Kubernetes, and how much RAM and babysitting it needs day to day. The smaller your team, the more that last one dominates.

RustFS: the direct swap

RustFS is the youngest of the three and it's aiming straight at MinIO's spot. Same deployment model, same S3 API, but written in Rust and licensed Apache 2.0. That license is the whole point. Apache 2.0 goes almost anywhere without a legal review.

Getting it up is familiar if you've run MinIO:

# RustFS runs as UID 10001, so prep the directory first
mkdir -p ./data && chown -R 10001:10001 ./data

docker run -d --name rustfs \
  -p 9000:9000 -p 9001:9001 \
  -e RUSTFS_ACCESS_KEY=mykey \
  -e RUSTFS_SECRET_KEY=mypassword \
  -v ./data:/data \
  rustfs/rustfs:latest /data

Port 9000 is the S3 API, 9001 is the console. One warning: leave the access and secret keys unset and it falls back to rustfsadmin/rustfsadmin. Set them in production, always. If you're new to locking down a self-hosted service, run through a self-hosted security checklist before you expose anything.

The nice part: it speaks to the mc client (MinIO's own CLI), so muscle memory carries over. Same commands, different binary.

The honest part: it's early. The Helm chart is still in progress, Object Lock and some encryption modes have gaps, and it hasn't been benchmarked head to head against the others. Treat it as a promising long-term bet, not something to drop critical data on this week.

SeaweedFS: the proven workhorse

SeaweedFS is a different animal. It's been around since 2012, written in Go, and running in real production at medium and large scale. When MinIO retreated, Kubeflow Pipelines made SeaweedFS its default object store. That tells you something.

The architecture is split on purpose: a master server for metadata, volume servers for the actual data, and an optional filer that gives you the filesystem view and the S3 emulation. That split is where the power comes from. It's also where the complexity comes from.

docker network create seaweedfs

# Master: manages metadata and coordinates the cluster
docker run -d --name weed-master \
  --network seaweedfs -p 9333:9333 \
  chrislusf/seaweedfs master

# Volume: stores the actual data
docker run -d --name weed-volume \
  --network seaweedfs -p 8080:8080 \
  -v ./data:/data \
  chrislusf/seaweedfs volume -mserver=weed-master:9333 -dir=/data

# Filer: exposes S3, apps connect on 8333
docker run -d --name weed-filer \
  --network seaweedfs -p 8333:8333 \
  chrislusf/seaweedfs filer -master=weed-master:9333 -s3 -s3.port=8333

A minimal setup needs a master and a volume server. For high availability you want three masters with RAFT consensus. The Helm charts are mature, well ahead of RustFS. This is more moving parts than a single binary, and you should count that operational cost honestly. If you're running this on your own boxes, pairing it with a solid reverse proxy setup keeps the S3 endpoint clean and TLS-terminated.

Where it shines: lots of small and medium files. User uploads, build artifacts, backups. It also does FUSE mounts, WebDAV, and its own HTTP interface next to S3, so if you need more than one way in, it's rare company. Versioning and Object Lock have limits, so verify those if you rely on them.

If you're treating object storage as serious infrastructure and you have the ops capacity, this is the most solid starting point of the three.

Garage: light and geo-distributed

Garage comes from a completely different design goal: distributed storage across places that aren't in the same data center. Geo-redundancy is baked in, which is exactly the thing MinIO and SeaweedFS don't do well.

There's no master node. Every node is a peer, coordination runs through a RAFT-like protocol, and it deliberately spreads replicas across the zones you define.

# Garage needs a config file or it won't start
cat > ./garage.toml << 'EOF'
metadata_dir = "/meta"
data_dir = "/data"
replication_factor = 1
rpc_secret = "$(openssl rand -hex 32)"
rpc_bind_addr = "[::]:3901"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"

[admin]
api_bind_addr = "[::]:3903"
EOF

docker run -d --name garage \
  -p 3900:3900 -p 3901:3901 -p 3903:3903 \
  -v ./garage.toml:/etc/garage.toml \
  -v ./data:/data \
  -v ./meta:/meta \
  dxflrs/garage:v1.0.1

docker exec garage garage node list
docker exec garage garage layout assign -z dc1 -c 1000000000000 <node-id>
docker exec garage garage layout apply --version 1

Setup is about as light as it gets. One binary, one TOML file, done. A node is happy on a small VPS with 2 GB of RAM, and the Kubernetes Helm chart is good.

The trade-off: it's not built for extreme throughput or thousands of requests a second, and Object Lock plus Versioning are missing or experimental. One more thing to know, and it catches people out: Garage is AGPL-3.0, same as MinIO. For internal use that's usually fine. For a proprietary product, you're back to the same legal review you were trying to escape. RustFS and SeaweedFS are Apache 2.0, which is why the license column matters more than it looks.

For a home lab, a small production system, or anything needing redundancy across locations, Garage is the elegant pick. With VPS prices climbing across the board in 2026, the fact that one node runs on 2 GB of RAM is a real cost lever.

Side by side

So which one

There's no single winner, and anyone who tells you otherwise is selling something. Match it to what you actually need.

If you want the closest thing to "swap the binary and keep my processes," watch RustFS, but test it hard first. If object storage is real infrastructure for you and you've got the ops hands to run it, SeaweedFS is the proven, scalable choice. If you want lean, low-maintenance storage, or you need data spread across locations, Garage is the cleanest fit as long as AGPL is fine for your use.

The bigger lesson under all of this: pick the smallest thing that does the job. Same reasoning as why most projects never need more than SQLite. A three-master SeaweedFS cluster for a side project storing a few gigs of uploads is a maintenance trap you'll resent in six months.

What to do now

Open your app and grep for the S3 features you actually call. If it's just put, get, list, and multipart, all three alternatives cover you and the choice comes down to license and ops. If you touch Object Lock or Versioning, that narrows the field fast, so confirm support before you migrate a byte.

Then stand one up in a container this week, point a staging bucket at it, and run your real workload against it. Don't trust a comparison table, including this one, over your own logs.