Leaving MinIO: Garage, VersityGW, and RustFS

Why MinIO had to go

For years MinIO was the obvious answer for self-hosted S3. Then the rug pull started. The condensed timeline:

• November 2024: MinIO Inc. announces AIStor, a commercial AI-focused product, timed to KubeCon NA 2024 (the Enterprise tier reportedly starts around $96k/year for up to 400 TiB). Clear signal that engineering attention had moved upmarket.
• May 2025: MinIO ships RELEASE.2025-05-24, which removes account management, policy management, bucket management, lifecycle/tier management, and site replication from the Community Edition web console. The CLI (mc) still works, but the admin UI is effectively gutted. The community reaction is loud and unhappy.
• December 2025: The minio/minio repo goes into maintenance mode. New features stop. Security fixes are handled case-by-case.
• February 2026: README updated to “THIS REPOSITORY IS NO LONGER MAINTAINED”. Repo archived.

Independent write-ups: Blocks & Files, It’s FOSS, Vonng “MinIO is Dead”, and InfoQ.

First swap: Garage

I had heard good things about Garage (Rust, AGPLv3, designed for small geo-distributed clusters). On paper it looked perfect for my setup. In practice, running Garage as a single node on a Synology NAS surfaced two problems I never fully diagnosed:

1. Intermittent hangs lasting several minutes, during which both the S3 API and any in-flight transfers stalled. My best guess at the time was that the internal scrub or garbage collection loop was acquiring a lock that blocked client I/O on a single-node deployment. I never proved this conclusively (the logs at the verbosity I was running were not specific enough).
2. CPU spikes that did not always correlate with traffic.

Garage is explicitly designed for multi-node clusters with at least three nodes. Running it as a single node is technically supported but is not the intended use case, and I think this is what bit me.

Second swap: VersityGW

I moved next to VersityGW (Go, Apache-2.0). The pitch is different: it is not a storage system, it is an S3 gateway in front of a POSIX filesystem. On a Synology that I had already provisioned as a giant Btrfs volume, this fits perfectly. No erasure coding layer, no internal scrub loop, just plain files on disk with metadata in IAM directories. Backups are trivial because everything is just files.

It worked well for most of my buckets immediately. The first thing that bit me was Harbor (my container registry). Hosting Harbor on VersityGW ran into a pile of S3-protocol edge cases around blob finalization, which I never traced to specific commits. Harbor is sensitive to nuances in how CompleteMultipartUpload, HeadObject, and signed-URL GetObject are implemented, and VersityGW’s posix backend was tripping on one or more of those. Rather than file a series of issues against VersityGW for Harbor compatibility, I parked Harbor on a separate backend.

Next was Nextcloud, which uses an S3-compatible primary object store. Nextcloud always sends x-amz-acl: private on PutObject, and VersityGW v1.0–v1.2 responded with 501 NotImplemented. Every upload failed, including thumbnails and chunked file writes. I filed versitygw#1904 with the repro; PR #1875 added an opt-in --disable-acl flag in v1.3.0, and #1911 made “ignore unsupported ACL headers” the default behaviour shortly after. Today on v1.4.1 the issue is gone.

Third addition: RustFS for Harbor and Nextcloud

RustFS (Rust, Apache-2.0) is the project that markets itself most explicitly as a drop-in MinIO replacement. When I needed a second S3 endpoint for the two services VersityGW could not reliably host, RustFS was the obvious choice.

Today I run two S3 backends on the same Synology, fronted by Traefik with separate ingresses:

• VersityGW for backup buckets, document storage, certificate caches, registry mirrors that work fine with a POSIX backend, and most everything else. About 20 buckets.
• RustFS for Harbor (the container registry’s blob store), Nextcloud (with the x-amz-acl legacy bucket on this side too), a public bucket with anonymous read for static assets, and three flavours of Kubernetes backup buckets. About 9 buckets.

Both have intermittent issues. Both have responsive maintainers who fix things fast. Neither is what I would call boring infrastructure yet.

Some issues I’ve hit or filed

A non-exhaustive list, mostly so I can find them later when something breaks again.

RustFS

There are other RustFS issues and PRs I monitor on every release (#2761 Harbor push 500 on finalize, open; #2807 .usage.json read-quorum chain, closed in May 2026 but worth watching for recurrence; #2790 network FS scanner hang, open and unlikely to be fixed; #2996 scanner-timeout hardening PR, merged; #3031 multipart-put write Storage resources insufficient, open). I keep a per-version verdict table in a local skill so that “should I take the Renovate bump?” has an answer that does not depend on me remembering anything.

VersityGW

VersityGW’s other gotcha for me has been keeping the admin endpoint behind its own ingress with separate auth, because the admin API has full root authority and the public S3 endpoint should never see those calls. Once that was wired up, the system has been quiet.

Garage

No upstream issues filed. The hangs I saw on single-node Synology never produced a reproducer clean enough to send to the maintainers. I might revisit Garage once I can provision three nodes.

So is this production-ready?

If “production-ready” means “I can let it run for months and not look at it”, then VersityGW don’t really know, maybe? RustFS definitely not.

VersityGW’s posix backend is conceptually simple enough that the worst case is “files on disk that any other S3 implementation could also serve”. For backup, document storage, and registry mirrors that is the right shape.

RustFS is younger, in active development, and ships breaking changes inside the same minor-version series. Every Renovate bump is an event that needs a person reading the changelog, cross-referencing open issues against my own logs, and deciding whether to upgrade, hold, or roll back. The good news is that the maintainers are responsive and fixes do land within days. The bad news is that the load-bearing part of my Harbor registry is still on software where I rolled back inside an hour today. I keep alpha.90 warm.

I would not recommend this exact split to someone setting up a homelab from scratch in May 2026. Garage didn’t stick for me, but it’s probably the most mature option to reach for right now if you can afford multiple nodes; single-node was the wrong shape for what I needed. For a single-box setup, honestly I don’t really know. Try both VersityGW and RustFS and see which one sticks with you, but be prepared to debug a bit if you run many things on S3.

I am also keeping an eye on Alarik, another open-source S3-compatible object store.

I am apparently not the only one who ended up here. feld’s “I just want simple S3” surveys the same field (MinIO dead, Garage too heavy, SeaweedFS too slow on their setup) and lands on VersityGW for its filesystem-backed simplicity and speed. And Healthchecks.io moved to self-hosted object storage on VersityGW over Btrfs, after rejecting MinIO, SeaweedFS, and Garage as too operationally heavy for a solo operator. Same reasoning, same pick: an S3 gateway over plain files beats running a distributed storage system you don’t need.

The deeper-tech view (bucket layout, endpoints, what runs where) is in the Technical Deep Dive tab.

Topology

Both backends run as Docker containers on the same Synology NAS, with Traefik (running upstream on the Kubernetes cluster) handling TLS, virtual-host routing, and middleware. The data and IAM directories live directly on the NAS’s Btrfs volumes.

    flowchart LR
    Client[S3 clients<br/>Harbor / Nextcloud / Velero / VolSync / Flux / etc.]
    Traefik[Traefik<br/>TLS + ingress]
    VGW[VersityGW<br/>v1.4.1<br/>posix backend]
    RFS[RustFS<br/>alpha.90<br/>XL2 metadata]
    V3FS[(NAS volume<br/>/volume1/v3/data<br/>plain files)]
    R3FS[(NAS volume<br/>/volume1/r3/data<br/>RustFS metadata + data)]

    Client -->|s3 / s3api| Traefik
    Traefik -->|v3 endpoint| VGW
    Traefik -->|r3 endpoint| RFS
    VGW --> V3FS
    RFS --> R3FS
  

Two endpoints, two backends, one box. The split keeps blast radius small: if RustFS misbehaves, only the buckets that need its specific behaviour go down. The 20 buckets on VersityGW keep working. For where this slots into the broader homelab, see The Stack.

Bucket-to-backend map

The split is operational, not architectural. I will gladly consolidate down to one backend the moment one of them earns it.

Endpoints

In code examples below, replace example.com with your own domain.

Operating both at once

The day-to-day commands I run most often:

# List buckets on each
mcli ls r3/
aws s3api --endpoint-url https://v3.example.com --region us-east-1 list-buckets

# Health on each
mcli admin info r3 --json | jq '{mode: .info.mode, buckets: .info.buckets, objects: .info.objects.count}'
curl -s https://v3.example.com/health

# Copy between backends (e.g., when migrating a bucket from one to the other)
mcli mirror --watch --remove r3/<bucket>/ vgw/<bucket>/

# IAM user management
mcli admin user list r3
versitygw admin -er https://v3admin.example.com list-users

I never SSH to the NAS for storage operations. Everything is admin-API or S3-API from the laptop. The NAS is the data plane; the control plane is here.

Where this might go next

A few directions I am thinking about:

1. Retest Nextcloud on VersityGW now that x-amz-acl is silently ignored. If it works, I drop one bucket off RustFS and the blast radius shrinks.
2. Retest Harbor on VersityGW once one of the open Harbor-shaped RustFS issues (#2761 / #3031 / #3028) settles upstream and I have a quieter base to compare against. If VersityGW v1.4.x handles Harbor’s protocol now, I could collapse to a single backend.
3. Rethink how to get to three S3 nodes for my setup, possibly moving S3 off the Synology entirely, so I can reconsider Garage in its native three-node configuration.

For now: two backends, one box, alpha.90 warm, beta.4 watched. The journey off MinIO is over, the storage story is not.