MinIO Is Archived: Move to Garage

Full example: Working Garage + Nextcloud Compose stack at github.com/KingPin/sumguy-examples/tree/main/self-hosting/garage-nextcloud

If you deployed MinIO last week, you deployed software that was already dead — you just didn’t know it yet. On April 25, 2026, the MinIO Community Edition repository went read-only. Archived. Done. The kind of GitHub tombstone that makes your ops runbook feel like a museum exhibit.

This wasn’t a shock for anyone who’d been paying close attention. It was the final frame in a slow-motion farewell that started years ago. But if you had a “MinIO is the S3-compatible storage layer” line in your homelab docs and never looked twice at it, here’s the full story — and more importantly, where to go next.

The Slow Walk to the Graveyard

MinIO didn’t flip a switch one morning. It was a managed exit, executed in stages:

• May 2025 — The admin console was quietly removed from Community Edition. No more web UI unless you were on a commercial license.
• October 2025 — New binary and Docker image distributions for CE stopped. No new builds hitting Docker Hub.
• December 2025 — Official announcement that CE was entering maintenance mode. Translation: “we’re done but we haven’t said it out loud yet.”
• February 12, 2026 — Repository status updated to “no longer maintained.” GitHub badge, the whole thing.
• April 25, 2026 — Repo archived. Read-only. The last commit is the last commit.

That’s nearly a year of deprecation signals before the final archive. The community kept filing issues, opening PRs, writing docs, and shipping blog posts through most of it. The maintainers weren’t exactly waving people off either.

They Took the Contributions and Ran

Here’s the part that deserves some editorial honesty.

MinIO’s community edition became the default S3-compatible storage answer for self-hosters because the community built a massive knowledge base around it. Stack Overflow answers. Ansible roles. Docker Compose tutorials. Nextcloud integration guides — including mine from last week, which now has a deprecation banner on it pointing here. Every one of those contributions was free reach. Free trust. Free sales material for a commercial product the company was building in parallel.

This is the same playbook Elastic ran with OpenSearch. HashiCorp ran with Terraform before the BSL switch. Redis Labs ran before the relicense. MongoDB ran before SSPL. The pattern is boringly consistent: open source the project, let the community grow it, use that traction to build enterprise credibility, then close the door once the commercial product is established enough to stand on its own. MinIO’s AIStor is the thing they were building toward. CE was the distribution mechanism for building the audience.

Every company has a justification. MinIO’s is that the open-source model wasn’t sustainable, that hyperscalers were eating their margins — the usual. These aren’t always wrong arguments. But the outcome for self-hosters is identical regardless of the reason: the software you contributed to, wrote about, and built infrastructure around gets locked behind a sales call. The contributions don’t come back.

So: no anger, no dramatic farewell post. Just a clear-eyed acknowledgment that this was a business decision, not a technical one, and we move on to something better maintained.

What Still Works, What Doesn’t

To be fair to the facts: the archived MinIO binary still runs. Fire it up on a fresh server today and it boots fine. It’ll probably boot fine in 2027. Software doesn’t rot on its own.

Here’s where the actual risks stack up:

• Security patches: zero. A CVE in the Go runtime, in MinIO’s auth layer, in the S3 signature verification code — nobody’s fixing it. The archived state isn’t “slow maintenance,” it’s “this is the final state of the code.” Full stop.
• Admin console: already gone. If you were on any CE build from May 2025 onward, you lost the web UI. The /minio/console/ endpoint doesn’t exist. If you’re still using a pre-May build, you’re running software that’s even older.
• mc client: still works. The MinIO client binary speaks S3, so it’ll talk to any S3-compatible endpoint, including Garage. This is actually useful for migration (more on that shortly).
• No new features, no new releases. If a new S3 API feature becomes relevant for your Nextcloud, Immich, or Seafile setup, MinIO CE won’t add it.

For an existing deploy with no immediate migration path, running archived MinIO isn’t catastrophically wrong — it’s a calculated risk. But starting a brand-new self-hosted object storage setup on archived software in 2026 is indefensible. There are better options.

Meet Garage

Garage is built by Deuxfleurs, a French self-hosting collective. It’s funded by NLnet (the same European research fund that backs a lot of the open internet infrastructure you use without knowing it). It’s AGPL-3 licensed. It’s written in Rust. And it had a fresh release on April 16, 2026.

The design philosophy is the important part. MinIO was always pitching at enterprise scale — high-throughput, erasure coding, multi-site replication at data-center scale. Garage is explicitly designed for small geo-distributed self-hosted deployments. Think: your home server, a VPS, maybe a friend’s machine in another city. Three nodes distributed across locations you actually control, not AWS availability zones you’re renting.

That’s a different problem from what MinIO was solving. And it means Garage makes different tradeoffs — ones that are a lot more sensible for the average person reading a blog called SumGuy’s Ramblings at 11pm because their Nextcloud is out of disk space.

Garage also ships an experimental K2V API — a key-value store built alongside the S3 API. It’s not production-stable yet, but it hints at where the project is going: a general-purpose lightweight storage backend, not just an S3 clone.

Garage vs MinIO at a Glance

The S3 compatibility gap is real but narrow for most use cases. Nextcloud, Immich, Seafile, most backup tools — they all hit the core S3 API. If you’re doing something that depends on complex object versioning or S3 Select, check Garage’s compatibility docs before committing. For standard homelab workloads: you’re fine.

The Setup Story Is Now Better

This is the part that genuinely surprised me. The April 16, 2026 Garage release added --single-node mode, and with it two flags that remove almost all of the bootstrapping friction: --default-access-key and --default-bucket.

Old MinIO single-node setup required setting root credentials via environment variables, exposing a console port, running mc alias set to configure the client, then mc admin user and mc mb to create a service user and bucket. Four or five steps before your first file was stored. It was fine, but it was ceremony.

New Garage single-node: three flags and you’re done. Your application gets an access key and a bucket on first boot without touching a config file.

Here’s a working Compose file:

services:
  garage:
    image: dxflrs/garage:v1.1.0
    container_name: garage
    restart: unless-stopped
    ports:
      - "3900:3900"   # S3 API
      - "3901:3901"   # Admin API
      - "3902:3902"   # RPC (internal, can be unexposed for single-node)
    volumes:
      - garage_meta:/var/lib/garage/meta
      - garage_data:/var/lib/garage/data
    environment:
      - GARAGE_SINGLE_NODE=true
      - GARAGE_DEFAULT_BUCKET=nextcloud
      - GARAGE_DEFAULT_ACCESS_KEY=garagekeyid
      - GARAGE_DEFAULT_SECRET_KEY=garagesecretchangethis
    command: >
      /garage server
      --single-node
      --default-bucket nextcloud
      --default-access-key garagekeyid
      --default-secret-key garagesecretchangethis

volumes:
  garage_meta:
  garage_data:

docker compose up -d
# S3 endpoint is ready at http://localhost:3900
# Bucket "nextcloud" already exists, credentials already set

That’s it. No mc alias. No mc admin. No console port to worry about. Your 2 AM self will appreciate it.

The full Garage + Nextcloud stack (with Nextcloud’s config.php objectstore block pre-configured to point at this Compose setup) is in the examples repo linked at the top.

Migrating From MinIO to Garage

If you have an existing MinIO deploy with data in it, migration is straightforward. Garage speaks S3, so the MinIO client treats it as just another S3 remote.

Path 1: mc mirror

# Add your existing MinIO as a source
mc alias set old-minio http://your-minio-host:9000 MINIO_ACCESS_KEY MINIO_SECRET_KEY

# Add new Garage as destination
mc alias set new-garage http://your-garage-host:3900 garagekeyid garagesecretchangethis

# Mirror everything (--overwrite skips objects already at destination)
mc mirror --overwrite old-minio/your-bucket new-garage/your-bucket

Path 2: rclone sync (if you don’t have mc)

# Configure rclone with two S3 remotes: minio-old and garage-new
# (use rclone config to set up both, then:)
rclone sync minio-old:your-bucket garage-new:your-bucket --progress

Then update your application config. For Nextcloud, the relevant block in config.php:

'objectstore' => [
  'class' => '\\OC\\Files\\ObjectStore\\S3',
  'arguments' => [
    'hostname' => 'minio.internal',
    'port' => 9000,
    'bucket' => 'nextcloud-data',
    'key' => 'MINIO_ACCESS_KEY',
    'secret' => 'MINIO_SECRET_KEY',
    'hostname' => 'garage.internal',
    'port' => 3900,
    'bucket' => 'nextcloud',
    'key' => 'garagekeyid',
    'secret' => 'garagesecretchangethis',
    'use_ssl' => false,
    'use_path_style' => true,
  ],
],

One thing worth knowing: the April 2026 Garage release explicitly relaxed the requirements on imported access keys to make transitions from other S3 providers smoother. If you had key IDs that didn’t match Garage’s default format, the new release is more forgiving. It reads like they anticipated exactly this migration wave from MinIO.

What About the MinIO Community Fork?

There’s a community fork that restores the admin console and rebuilds the binary distribution pipeline. The people maintaining it are doing real work and their motivations are genuine — they want to keep using MinIO without paying MinIO Inc.

It’s a legitimate option if you have a complex MinIO setup with specific features you depend on and the migration to Garage feels too heavy. No judgment.

But for a greenfield deploy in 2026, Garage is the healthier bet. The fork depends on a small group of maintainers sustaining stamina for an indefinitely long project with no institutional support and a commercial upstream that has every incentive to diverge. Garage has a multi-person team, NLnet funding with documented renewal history, and a clear design vision. Those aren’t guarantees, but they’re better odds.

If Garage ever goes dark, you’re back to the same migration problem — except Garage’s data is in standard S3 format, so you’ll just be doing this same rclone sync to whatever comes next.

So Here We Are

Last week I published a guide to running MinIO with Nextcloud. That post is now stamped with a deprecation banner pointing here. If you want the historical context, the old post is still up — it’s accurate for what it was, it’s just describing software that’s been retired.

Replacing a deprecated tool isn’t a catastrophe. It’s maintenance. Self-hosted infrastructure means you own the whole stack, and part of owning the stack is knowing when a component’s upstream has moved on. MinIO served a lot of homelabs well for a lot of years. Garage looks like it was designed by people who actually run the kind of setups we run.

Archive the old config. Open the garage door. Your buckets aren’t going anywhere.