MinIO Is Archived: Self-Hosted S3 Alternatives in 2026

MinIO's open-source repo is archived. For self-hosted S3 in 2026, use RustFS as a drop-in, SeaweedFS for proven scale, or Garage for small multi-site clusters.

For years, MinIO was the answer to "how do I run S3 on my own server?" That is no longer true. Over 2025 the company removed most of the web console from the community edition, stopped publishing free binaries and Docker images, and moved the open-source project into maintenance mode. In April 2026 the GitHub repository was archived. If your app still stores uploads, backups or build artifacts in a community MinIO instance, you are running unmaintained storage software, and it is time to plan a move.

I went through this migration myself. The uploads for this website (blog covers, project screenshots, chat attachments) used to live on local disk and in MinIO-style storage. Today they live in RustFS, with a local-disk fallback for older files. This guide covers what I learned: which alternatives are worth your time, how to choose, and how to migrate without breaking a single image URL.

Key takeaways

• MinIO community edition is no longer a safe default. No new security fixes means every exposed instance becomes riskier over time.
• RustFS is the closest MinIO look-alike: same single-binary model, same ports (9000 API, 9001 console), Apache 2.0 license.
• SeaweedFS is the mature, battle-tested choice when you have lots of files or need to grow to many servers.
• Garage is great for small clusters spread across locations, but implements only the core S3 API.
• Migration is mostly boring if your app talks plain S3: copy buckets with rclone, switch the endpoint, keep the same object keys.

Why the MinIO change matters for your business

Object storage is rarely the exciting part of a product, which is exactly why it gets forgotten. It quietly holds customer uploads, invoices, database backups and media. When the software underneath stops getting patches, three things happen:

1. Security debt grows. Any vulnerability found after the archive date stays open in the community build.
2. Docker images go stale. If you pull minio/minio:latest in CI, you may already be pinned to an old build without noticing.
3. Hiring and support get harder. New engineers will expect a maintained tool, and documentation will slowly drift away from the version you run.

The good news: S3 is a protocol, not a product. Your application code almost never needs to change. You swap the server behind the endpoint.

The best self-hosted S3 alternatives in 2026

1. RustFS: the drop-in replacement

RustFS is written in Rust, licensed under Apache 2.0, and openly aims to fill the space MinIO left. It ships as a single binary or Docker image, exposes the S3 API on port 9000 and a web console on port 9001, and the console will feel familiar to anyone who used the old MinIO UI.

docker run -d --name rustfs \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:9001:9001 \
  -e RUSTFS_ACCESS_KEY=change-me \
  -e RUSTFS_SECRET_KEY=a-long-random-secret \
  -v /srv/rustfs/data:/data \
  -v /srv/rustfs/logs:/logs \
  --restart unless-stopped \
  rustfs/rustfs:latest

Notice the 127.0.0.1 bindings. Docker publishes ports straight through iptables and bypasses UFW, so I never expose storage ports publicly. Put Nginx in front with TLS instead (for example s3.yourdomain.com), and never keep the default rustfsadmin credentials.

Choose RustFS when: you ran a single MinIO node, you want the shortest migration, and you like having a web console. Be careful: it is a younger project, so pin a version tag in production and test upgrades on staging first.

2. SeaweedFS: proven at scale

SeaweedFS has been in development for over a decade. It is built for very large numbers of files, stores small objects efficiently, and offers an S3 gateway on top of its own filer. It is Apache 2.0 licensed and has a long production track record.

Choose SeaweedFS when: you store millions of files, you expect to grow beyond one server, or you need features like tiering to cloud storage. Trade-off: more moving parts (master, volume, filer, S3 gateway) and a steeper learning curve than a single binary.

3. Garage: lightweight and geo-distributed

Garage was designed by the Deuxfleurs collective to run on modest hardware across several physical locations, with replication built in. It is light on RAM and simple to operate. It is licensed under AGPL-3.0, which is fine for running it as infrastructure, but worth a quick check with your legal team if you plan to modify and distribute it.

Choose Garage when: you want three small nodes in three places (home lab, office, VPS) instead of one big server. Trade-off: it implements the core S3 API, not every advanced feature, so check that your SDK calls (versioning, object lock, some ACL operations) are supported before you commit.

4. Ceph RGW: enterprise only

Ceph's RADOS Gateway is extremely capable, but it is a full distributed storage platform. Unless you already run Ceph or have a dedicated storage team, it is too heavy for a typical web app or SaaS.

5. Managed S3-compatible storage

Sometimes the right answer is to stop self-hosting storage. Providers such as Cloudflare R2, Backblaze B2, Hetzner Object Storage or Wasabi give you an S3 endpoint for a low monthly price. You trade control for zero maintenance. For backups, I often recommend both: self-hosted for the app, plus an offsite managed bucket for disaster recovery.

How to choose in 60 seconds

• One server, a few hundred GB, want it working today: RustFS.
• Millions of files or multi-server growth: SeaweedFS.
• Several small nodes in different locations: Garage.
• No time to run storage at all: a managed S3-compatible provider.
• Already running Ceph: Ceph RGW.

Step-by-step: migrating from MinIO without downtime

Step 1: Inventory what you have

List buckets, sizes, and which apps use which credentials. Check for bucket policies, lifecycle rules and public-read buckets, because these are the settings people forget to recreate.

Step 2: Start the new server next to the old one

Run RustFS (or your choice) on different ports or a different host. Create the same bucket names and a dedicated access key per application.

Step 3: Copy the data with rclone

rclone speaks S3 to both sides and can be re-run safely. Configure two remotes, then sync:

# ~/.config/rclone/rclone.conf
[old]
type = s3
provider = Minio
endpoint = http://127.0.0.1:9000
access_key_id = OLD_KEY
secret_access_key = OLD_SECRET

[new]
type = s3
provider = Other
endpoint = http://127.0.0.1:9100
access_key_id = NEW_KEY
secret_access_key = NEW_SECRET

# copy everything, then re-run right before the switch to catch new uploads
rclone sync old:uploads new:uploads --progress --checksum

Step 4: Point the app at the new endpoint

In most SDKs the change is two environment variables. One setting matters for every MinIO-style server: path-style addressing. Here is the Node.js client config this website uses:

import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  endpoint: process.env.S3_ENDPOINT,   // https://s3.yourdomain.com
  region: "us-east-1",                 // any value works for self-hosted
  forcePathStyle: true,                // http://host/<bucket>/<key>
  credentials: {
    accessKeyId: process.env.S3_ACCESS_KEY!,
    secretAccessKey: process.env.S3_SECRET_KEY!,
  },
});

Keep object keys identical and your public URLs never change. On this site, every upload is served through the API as /files/<key>, and if a key is not found in the bucket it falls back to local disk. That one fallback let me migrate gradually with zero broken images.

Step 5: Final sync, switch, watch

Run rclone sync one last time, deploy the new endpoint, and watch logs for 403 or 404 errors for a day. Keep the old MinIO data read-only for a week before deleting anything.

Don't forget backups

Moving storage is the perfect moment to fix backups. A bucket on the same disk as your app is not a backup. Schedule rclone sync to an offsite provider every night and test a restore. If you want a deeper walkthrough of server and database backups, read my complete guide to Linux backups.

Frequently asked questions

Can I keep using MinIO in 2026?

The software still runs, but the community repository is archived and no longer receives fixes. For internal test environments that is acceptable for a while. For anything exposed to the internet or holding customer data, plan a migration.

Is RustFS production ready?

RustFS has a stable 1.x release line and covers the core S3 API well. I run it in production for this website. As with any young project, pin a version, monitor it, and keep offsite backups.

Do I need to change my application code?

Usually not. If your app uses an AWS S3 SDK, you change the endpoint, credentials and possibly enable path-style addressing. Object keys and bucket names stay the same.

What is the cheapest way to get S3 storage?

For small projects, a self-hosted RustFS or Garage node on a VPS you already pay for costs nothing extra. For large or critical data, a managed S3-compatible provider is often cheaper than the engineering time to run storage yourself.

How long does a migration take?

For a typical web app with tens of gigabytes, a careful migration takes a few hours of work plus the copy time. Most of the effort is inventory and testing, not the copy itself.

Need help moving off MinIO?

I plan and run storage migrations, set up self-hosted S3 with TLS and backups, and make sure nothing breaks along the way. See my DevOps services or contact me with your current setup and I will reply with a clear plan and a fixed price. If you are also rethinking where your app runs, my comparison of Vercel vs self-hosting costs is a good next read.