MinIO vs Garage

For years this was a genuine argument: MinIO's erasure coding and enormous S3 API surface against Garage's deliberately small scope. It is not an argument any more, and a page that presents it as one is out of date. MinIO's community edition was hollowed out in 2025 and archived in 2026. This page is mostly about what to do instead, including the option nobody sells you, which is running no object store at all.

What the specification table decides#

Maturity reads legacy for MinIO, and that is the whole page in one cell. Operational load is 4 against 3, and MinIO's 4 now includes compiling it yourself and tracking Go CVEs, because nobody else will. Licence is the other row to read: AGPL-3.0 on both, except MinIO's says "repository archived", and the vendor's recommended successor is not AGPL at all.

Exactly what happened to MinIO#

Three dates, in order.

24 May 2025. RELEASE.2025-05-24T17-08-30Z deprecated the embedded management console, moving it out to a separate object browser, and removed external identity provider login (OIDC and LDAP) from the community build, making it part of the commercial product. This was a breaking change delivered as a routine upgrade. People who pulled the latest image lost their admin UI and their directory logins in one step, and found policy and replication management had moved to mc on the command line.

February 2026. The project was marked unmaintained.

25 April 2026. GitHub archived minio/minio. The README opens by stating the repository is no longer maintained. The last release remains RELEASE.2025-10-15T17-29-55Z, which was itself a privilege escalation fix. There will be no further security releases, no issue triage and no new community binaries or images.

The company's own path forward is AIStor, and AIStor Free is not a licence change to MinIO. It is a different product under a EULA whose free tier permits use in standalone mode only, meaning a single node, no distributed clustering, no high availability, and no modifying, reverse engineering or redistributing. That may be an acceptable trade for a one-box homelab if you read it and accept it. It is not open source and it will not run a cluster.

One more consequence people underestimate: docs.min.io now documents AIStor exclusively. Configuration references, tuning guidance and troubleshooting for the community server are no longer published, so search results may describe flags your archived binary does not have, or the reverse. If you are still running it, save a local copy of the documentation your version needs before you need it.

If you are running MinIO today, do this#

Not "migrate eventually". A specific list, this month.

1. Pin the version. Stop using latest. Pin RELEASE.2025-10-15T17-29-55Z explicitly so an image refresh cannot move you.
2. Get the admin surface off the network. Bind the console and API to a private interface, put an authenticating proxy in front, and make sure port 9000 is not reachable from the internet. There is no vendor issuing you a patch when the next CVE lands.
3. Verify what you are backing up. The buckets are the obvious part. .minio.sys on every drive holds access keys, policies, bucket metadata, versioning and lifecycle configuration. Copying only bucket directories gives you objects with no identities attached. Replicate at the S3 layer instead.
4. Copy the data out at the S3 layer. This is also the migration:

rclone copy minio-old:photos garage-new:photos --transfers 8 --checkers 16 --fast-list
rclone check minio-old:photos garage-new:photos --one-way

1. Decide the destination honestly. For most self-hosters that is Garage. For some it is no object store at all, which is the next section.

If you genuinely cannot move yet, you can still build the archived code with Go 1.24 or later (go install github.com/minio/minio@latest), and the images up to the final release remain pullable and multi-arch. You are the maintainer now. That is a real job, and for a home server it is not a job worth having.

Where Garage actually fits#

Garage is AGPL-3.0-only, written in Rust, built and run in production by Deuxfleurs since 2020, and releasing on a real cadence: 2.0.0 in June 2025, 2.4.0 on 6 September 2026. It was designed for a specific situation that describes a lot of self-hosters: a few ordinary machines on separate sites and consumer uplinks, wanting geographic redundancy without renting cloud storage.

Read the scope limits before you commit, because they are deliberate and they are not going to change:

• No object versioning and no object lock, so no S3-layer immutability.
• No bucket policies or ACLs. Garage substitutes its own per-access-key-per-bucket permission model.
• No server-side encryption and no bucket notifications.
• Full replication rather than erasure coding, so replication_factor = 3 means one third of your raw disk is usable capacity. MinIO's erasure coding was substantially more efficient here, and that is a genuine loss.

For a restic, Kopia or Borg target, every one of those absences is irrelevant. Those tools encrypt client side already, they do not use bucket policies, and they do not need versioning. The one that stings is object lock, because it is exactly how you would make a backup bucket immutable against a compromised client. On Garage you have to solve that somewhere else, which is covered in Backups that actually restore.

A working single-node start:

# /etc/garage.toml
metadata_dir = "/var/lib/garage/meta"
data_dir     = "/var/lib/garage/data"
db_engine    = "lmdb"
replication_factor = 1
rpc_bind_addr = "[::]:3901"
rpc_secret    = "<openssl rand -hex 32>"
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = ".s3.example.org"

Then the two commands people miss, in order:

garage layout assign -z home -c 2T $(garage node id -q | cut -d@ -f1)
garage layout apply --version 1
garage bucket create backups
garage key create restic-web1
garage bucket allow --read --write backups --key restic-web1

layout assign only stages the change. Nothing happens until layout apply --version N, and getting N wrong is refused rather than guessed. New operators assign capacity, see garage status unchanged, and conclude the cluster is broken.

Two more things to know: the 1.0 to 2.0 upgrade was not rolling, requiring every node stopped and restarted simultaneously because the RPC protocol changed, and 2.0 reworked the admin API around /v2/ paths so most /v1/ endpoints were removed and anything you scripted against them breaks. Take a garage meta snapshot --all before any major upgrade, and give the snapshot directory room, because the documentation warns Garage may hold up to three snapshots needing roughly four times the database size.

The option nobody sells you: just use a directory#

Here is the uncomfortable part. A large share of self-hosted S3 deployments exist to give one backup tool a destination. That is a bad reason.

restic writes to a local path, to SFTP, or to rest-server. Borg writes over plain SSH. Kopia writes to a filesystem or SFTP. All three of those are simpler, faster, have fewer moving parts and cannot be broken by a cluster layout mistake:

restic -r /mnt/backup/repo init
restic -r sftp:backup@nas:/srv/restic/web1 init

Running Garage so that restic can write to s3://backups on the same machine adds a daemon, a metadata database, a replication factor, a layout, four ports and a second thing to upgrade, in exchange for nothing. Run Garage when at least one of these is true:

• You have a second consumer that speaks only S3 and cannot speak anything else.
• You want geographic replication across two or three sites, which is Garage's actual design goal.
• You are giving other people scoped credentials to buckets on your storage.

Otherwise, use a directory, and spend the effort on testing restores instead. See restic vs BorgBackup and Backup planner.

Which one for your situation#

What to do next#

If you run MinIO, put the five steps above on this month's list, starting with pinning the version and getting port 9000 off any public interface. If you are choosing fresh, start Garage single node with replication_factor = 1, create one bucket, point a restic repository at it, and restore a file before you move anything real.

Before you do either, ask whether you need object storage at all. Backups that actually restore covers the destination question properly, Backup planner sizes the storage, and ZFS, btrfs, mdadm or one disk covers the layer underneath both of these, which is the one that actually loses data. If you want the backup client side of the decision, restic vs Kopia and Duplicati vs restic cover it, and the Backup category has every profile including rclone and BorgBackup.