MinIO vs Garage vs SeaweedFS: Self-Hosted S3 on a VPS (2026)

MinIO was the answer almost everyone reached for when they wanted an S3-compatible bucket on their own VPS. That era ended on February 12, 2026, when the MinIO open-source repository was archived and turned read-only — no more security patches, no pre-built binaries, no active development. The writing had been on the wall since May 2025, when MinIO stripped the management console out of the community edition and left behind a basic object browser that could barely list files. By the time the project formally entered "maintenance mode" on December 3, 2025, most self-hosters had already started looking elsewhere.

So if you are spinning up object storage on a VPS in 2026, the question is no longer "MinIO or something else." It is "Garage or SeaweedFS" — the two community-governed projects that absorbed most of MinIO's refugees. I have been running into this exact decision across my own infrastructure, and this guide walks through the tradeoffs the way I actually evaluated them, not the way a feature matrix would.

Why I needed self-hosted S3 in the first place

Quick context on where I am coming from, because it shapes the recommendations. I run 7 aggregator and review sites on Hostinger shared hosting plus a small VPS, and across those properties I push daily content imports of roughly 100 to 200 records each. Several of those sites store images — featured images, thumbnails, scraped product shots. For CyberShieldTips, one of the security sites, I aggregate CVE data from NVD into a database that now holds a few thousand entries, and the associated assets need somewhere durable to live that is not the same disk as the web root.

For years the lazy answer was "just dump it in the uploads folder." That works until it doesn't. When you are running daily cron jobs that write hundreds of files, a flat uploads directory on shared hosting becomes a backup nightmare and a single point of failure. Moving binary assets behind an S3 API gives you versioning, lifecycle rules, and the ability to point a CDN at a bucket instead of your origin. That is the problem self-hosted object storage solves, and it is why the MinIO shutdown actually mattered to me rather than being abstract open-source drama.

The three contenders at a glance

What actually happened to MinIO

Worth being precise here, because there is a lot of hand-waving in other write-ups. MinIO did not get hacked or go bankrupt. It made a sequence of commercial decisions that, stacked together, made the community edition unusable for new deployments:

• In 2021 the core server moved from Apache 2.0 to AGPL-3.0. On its own that was survivable, but it meant any product shipping MinIO over a network had to think hard about copyleft obligations.
• In May 2025 the management console was removed from the community edition. Policy management, IAM, lifecycle configuration, site replication — all of it moved into the paid enterprise tier. The community build was left with a read-only object browser.
• On December 3, 2025 the project was put into maintenance mode.
• On February 12, 2026 the GitHub repository was archived.

The practical upshot: if you install MinIO CE today, you are deploying software that will receive no security patches. For an internet-facing storage service holding your data, that is a non-starter. I would not put it on a production VPS in 2026 under any circumstances, and the only reason to keep an existing install running is to migrate off it. Pin the last known-good binary, isolate it behind a firewall, and treat it as a temporary bridge.

Garage: the boring binary that does one thing well

Garage is built in Rust by Deuxfleurs, a small French non-profit. The thing to understand about Garage is that it was designed for a use case MinIO and SeaweedFS handle badly: object storage spread across nodes that are not in the same data center. There is no central master node — every node is a peer, coordination runs through a Raft-like protocol, and zone-awareness is baked in so replicas land in different availability zones on purpose.

For a single-VPS deployment none of that distributed cleverness matters much, but the design choices that enable it — small footprint, no master, simple config — make Garage genuinely pleasant on a modest box. It runs as a single binary, needs about 1 GB of RAM, and happily runs on an ARM CPU; people run it on Raspberry Pi clusters. The current generation is v2.x.

Where it bites you: Garage uses full replication (typically 3 copies) rather than erasure coding. That is simple and reliable, but it means a 3-replica setup consumes 3x the raw disk for the same usable capacity. For a few hundred gigabytes of images that is fine; for tens of terabytes the storage-efficiency math turns ugly fast. Garage also does not support S3 Object Lock as of the v2 line, so if your compliance story requires write-once-read-many immutability, Garage is out. And like MinIO, it is AGPL-3.0 — if you are wrapping it in a proprietary product, the same license review applies.

In my experience, Garage is the right default for exactly the kind of work I do: a handful of buckets, a few hundred gigabytes, served behind Cloudflare, where setup simplicity and low idle resource use matter more than squeezing every byte of disk efficiency. On a 2 GB VPS, a single-node Garage instance sat at well under 200 MB of resident memory when idle in my testing, which leaves room for the actual web workload to share the box.

SeaweedFS: built to swallow billions of files

SeaweedFS is the veteran of the group — roughly twelve years old, hundreds of contributors, and crucially licensed under Apache 2.0, which sidesteps the AGPL copyleft questions entirely. When MinIO retreated, Kubeflow Pipelines adopted SeaweedFS as its default object storage backend, which tells you something about where the institutional trust went.

The standout technical property is small-file performance. SeaweedFS packs small files into larger volume files, so you get O(1) disk access regardless of how many objects you store — it is engineered to handle billions of files where MinIO and Ceph start to choke. One independent benchmark had SeaweedFS finishing a 30-million-small-file workload roughly 2.5x faster than MooseFS, and it did that on rotational HDDs while MooseFS ran on SSDs. If your workload is millions of thumbnails or tiny JSON blobs, this is the architecture you want.

Where it bites you: complexity. SeaweedFS does not hand you one binary and a config file. The architecture splits across roles — master servers hold metadata, volume servers hold the actual bytes, filer servers add filesystem semantics, and a separate S3 gateway translates S3 calls into SeaweedFS's native filer API. You can run all of those on one box to start, but you are now operating four conceptual services instead of one, and the failure modes multiply. For a single VPS serving one site, that is more machinery than the job needs.

My read: SeaweedFS earns its keep the moment you are at multi-terabyte scale, or you can see yourself outgrowing a single binary within 18 months. If I were consolidating image storage for all 7 of my sites into one durable backend that needed to scale horizontally, this is where I would land. For a single property storing a few thousand assets, it is overkill.

How I would actually decide

Strip away the feature lists and the decision comes down to three honest questions:

1. How much data, and how many objects? Under a terabyte and under a few million objects: Garage. Multi-terabyte or millions-to-billions of small files: SeaweedFS.
2. Do you need Object Lock / WORM immutability? If yes, Garage is disqualified and SeaweedFS gets you partial support — evaluate carefully, and if it is a hard compliance requirement you may need to look at Ceph or a managed provider instead.
3. Does the AGPL license create friction for you? If you ship a proprietary product over a network, SeaweedFS's Apache 2.0 license is the safer pick. For internal/personal infrastructure, AGPL is a non-issue and Garage is fine.

For my own stack — aggregator sites, modest data volumes, Cloudflare in front, a single VPS or shared box doing the work — I went with Garage. The single-binary operations model means one less service to babysit, and across 7 sites where I am already juggling daily import crons, fail2ban quirks, and WAF rules, "one less thing that can break at 2 AM" has real value. The opinion I would actually stand behind: don't reach for SeaweedFS just because it scales further than you need. Match the tool to today's data, not a hypothetical future one.

VPS sizing notes from running this for real

A few practical numbers that are hard to find in the docs:

• RAM headroom matters more than the minimum. Garage's "1 GB minimum" is real, but if you co-host it with a web app and a database on a 2 GB VPS, you will be tight. I would not run a co-located object store with under 2 GB of RAM, and 4 GB if the same box also serves PHP and MySQL.
• Disk I/O is the bottleneck, not the binary. On budget VPS plans with shared NVMe, sustained write throughput during a bulk import is what determines whether your nightly cron finishes in 4 minutes or 40. Test with your real object size distribution before committing.
• Put a CDN in front regardless. Whichever store you pick, you do not want public reads hitting the origin. I front everything with Cloudflare, set long cache TTLs on the bucket-served paths, and let the object store handle writes and cache misses only.
• Back up the metadata, not just the data. SeaweedFS's filer and Garage's metadata layer are what make your objects addressable. Snapshot those on a schedule. Losing the data volumes is recoverable from replicas; losing the metadata index can orphan everything.

What this means for hosting buyers

If you are choosing a VPS specifically to run self-hosted object storage in 2026, the spec that matters is not vCPU count — these stores are I/O and memory bound, not compute bound. Prioritize, in order: disk space and disk I/O, then RAM, then network egress allowance (because serving objects burns bandwidth), and CPU last. A provider like Hetzner or Contabo that gives you generous disk and bandwidth for the money tends to beat a compute-optimized instance for this workload.

And budget for replication overhead. If Garage is keeping 3 copies, your usable capacity is one-third of raw disk. A "1 TB" plan gives you roughly 330 GB of usable, replicated storage. That single fact reshapes which hosting plan is actually the cheapest for your real capacity target, and it is the kind of thing the marketing pages never spell out.

Migrating off MinIO without downtime

If you already have data sitting in a MinIO bucket, you do not need to panic-migrate, but you should plan the move while the old binary still runs. The migration path that worked cleanly for me uses the AWS CLI or rclone, since both Garage and SeaweedFS speak the same S3 API MinIO did:

1. Stand up the new store alongside the old one. Spin up Garage or SeaweedFS on the same VPS (or a fresh one) and create buckets matching your MinIO layout. Do not touch MinIO yet.
2. Sync with rclone. Configure two remotes — minio: and garage: — and run rclone sync minio:mybucket garage:mybucket --progress. For large datasets, run it once to copy the bulk, then again to catch deltas.
3. Verify object counts and checksums. Compare rclone size on both sides. Do not trust a "looks done" — confirm the object count and total bytes match before you cut over.
4. Flip your application config. Change the S3 endpoint, access key, and secret in your app to point at the new store. Because the API is identical, your code usually does not change at all — only the endpoint URL.
5. Keep MinIO read-only for a grace period. Leave it running, firewalled, for a week or two as a fallback before you decommission it.

The one gotcha worth flagging: presigned URLs and bucket policies do not always translate one-to-one. If your app generates presigned download links, regenerate them after cutover rather than assuming the old ones still resolve. I learned that the hard way on a test bucket — the objects copied fine, but stale presigned URLs pointed at the dead endpoint.

A note on RustFS and Ceph

Two names come up constantly in these discussions, so let me address them directly rather than pretend Garage and SeaweedFS are the only options. RustFS is a newer Rust-based MinIO clone that aims to be a near drop-in replacement with a familiar console. It is genuinely promising, but in 2026 it is young — I would not put a project that new in charge of data I cannot afford to lose, though it is absolutely worth tracking for next year. Ceph, on the other hand, is the opposite problem: it is battle-tested at massive scale and supports full Object Lock, but its operational complexity is in another league. Running Ceph for a single VPS or a couple of review sites is like renting a freight train to move a sofa. Reach for Ceph when you have a dedicated storage team and petabyte ambitions, not before.

Frequently asked questions

Can I run Garage or SeaweedFS on shared hosting? No. Both need a long-running process and a port you control, which shared hosting does not give you. You need at least a small VPS. This is one of the few cases where the jump from shared to VPS is genuinely required rather than a nice-to-have.

Is self-hosting S3 cheaper than using a managed provider? It depends entirely on volume. For a few hundred gigabytes with light traffic, a managed S3-compatible provider often wins once you price in your own time. Self-hosting pays off when egress bandwidth is your big cost line, because providers charge heavily for it and a VPS with generous included bandwidth does not. Run the math on your actual egress before assuming self-hosting saves money.

Do these work with tools that expect AWS S3? Yes — that is the entire point of S3 compatibility. Backup tools like restic, Kopia and Duplicati, plus most CMS media plugins, work against Garage and SeaweedFS by just changing the endpoint. Compatibility is not 100% on exotic API features, but the common operations all work.

Which one has the easier learning curve? Garage, by a wide margin. One binary, one config file, and you have a working S3 endpoint in minutes. SeaweedFS rewards the extra learning with scale, but if you value getting it working tonight, start with Garage.

What about backups of the object store itself? Replication is not backup. A replica protects against a disk dying; it does not protect against you deleting a bucket by mistake. Run a separate scheduled job that copies objects to a second location — even a cheap remote bucket — and snapshot the metadata layer on its own schedule.

Bottom line

MinIO is done for new deployments — archived, unpatched, and steering everyone toward a paid tier. The two answers worth your time in 2026 are Garage for simplicity and small-to-medium scale, and SeaweedFS for serious file counts and Apache-license peace of mind. Pick based on your actual data volume and licensing needs, size your VPS for I/O and RAM rather than CPU, remember that replication multiplies your disk requirement, and put a CDN in front of whatever you choose. Do that and you will have S3-compatible storage that outlives the next vendor's strategy pivot.