MinIO and its alternatives: revisit your self-hosted S3 in 2026

For many teams, MinIO was the default answer to one simple need: “give us S3 on our own machines”. It sat behind CI pipelines, backup jobs, data lake experiments and almost every docker-compose file that needed a bucket. Most of us never thought about it again. Between May 2025 and September 2026 that quiet default changed step by step, and many setups now depend on a binary or image that nobody is updating any more.

This post walks through what changed and when, what is true today, and how the main open-source alternatives compare: Ceph RGW, SeaweedFS, Garage, RustFS and Apache Ozone. It ends with a decision guide and a migration drill you can run in a sandbox. The facts come from the MinIO GitHub repository, its release notes, MinIO’s own pricing and press pages, and each alternative’s own repository and documentation, checked on 6 October 2026. Dates are as shown on those pages. Nothing here is legal advice. Where a project makes performance claims, I have left the numbers out; read them on the project’s own page and treat them as the project’s claim.

The short version

  • MinIO moved its server and client from Apache 2.0 to GNU AGPLv3 in 2021. The client SDKs stayed on Apache 2.0.
  • In May 2025 the embedded admin console was deprecated and its LDAP and OIDC logins removed from the community build. In October 2025 the community edition became source only. The last community release, RELEASE.2025-10-15T17-29-55Z, was a security fix with no binaries attached.
  • The README declared maintenance mode on 3 December 2025 and “no longer maintained” on 12 February 2026. GitHub shows the repository archived since 25 April 2026, and the mc client repository since 14 July 2026.
  • Checked on 6 October 2026: dl.min.io answers “410 Gone” for community binaries, and the Docker Hub API answers “object not found” for minio/minio and minio/mc.
  • MinIO’s current free option is AIStor Free, a single-node edition under a free licence where redistribution is prohibited. It is not open source.
  • No alternative is a drop-in copy of MinIO. Each one has gaps in its S3 coverage that its own docs list. Pick by the S3 features you actually use, then test.

How we got here: MinIO’s licence and the 2025 changes

The MinIO code history starts in late 2014, under Apache 2.0. It became the usual self-hosted S3 server because it was a single Go binary, easy to start, and close to AWS behaviour.

The first big change came in 2021. A commit titled “update license change for MinIO” (April 2021) replaced the Apache 2.0 licence text with the GNU AGPLv3. MinIO’s blog post, “From Open Source to Free and Open Source”, said the transition was complete with RELEASE.2021-05-11T23-27-41Z, that the server, client and gateway were now AGPLv3, that the client SDKs remained Apache 2.0, and that the AGPL journey had begun in October 2019 with newer components. That post’s URL now redirects to the MinIO blog index, so I have relied on its indexed text and the commit itself.

For four years, AGPLv3 did not stop most internal users, and binaries and images were published as usual. The 2025 and 2026 changes were different in kind: they were about distribution and maintenance, not the licence.

The timeline, from primary sources

  • May 2025, RELEASE.2025-05-24T17-08-30Z. The release notes say the embedded UI console is deprecated and moved to the object-browser project, external IDP logins through LDAP and OIDC are removed and “now available as part of the AiStor Product”, and STS APIs keep working. In a later GitHub discussion, one community user described this as “taking out the admin UI”.
  • 15 October 2025. A README commit pointed the docs to source-only releases. The README now says the community edition is “distributed as source code only” and that pre-compiled binaries will not be provided.
  • Mid-October 2025. RELEASE.2025-10-15T17-29-55Z was published as a security release for CVE-2025-62506 (privilege escalation through session policy bypass in service accounts and STS). It has no binary assets; the notes tell users to go install or build their own container. The release before it had 48 assets.
  • 26 October 2025. In a GitHub discussion, a maintainer wrote that MinIO “is a source-only distribution and is meant to remain that way for the near future.”
  • 3 December 2025. The README gained a “Maintenance Mode” notice: no new features or pull requests, critical security fixes “may be evaluated on a case-by-case basis”, issues not actively reviewed.
  • 23 December 2025. MinIO announced the AIStor Free and AIStor Enterprise Lite tiers.
  • 12 February 2026. The README changed to “THIS REPOSITORY IS NO LONGER MAINTAINED”, listing AIStor Free and AIStor Enterprise as alternatives.
  • 25 April 2026. GitHub shows the repository archived by the owner. The minio/mc repository shows archived on 14 July 2026.
  • Mid-September 2026. Projects such as Milvus reported that minio/minio could no longer be pulled from Docker Hub.

What is true on 6 October 2026

  • The latest tag on the archived repository is RELEASE.2025-10-15T17-29-55Z. The last commit to master is the README change of 12 February 2026.
  • The README still says historical binaries remain at dl.min.io. That address now returns HTTP 410 with a note that the open-source MinIO Server, MinIO Client (mc) and MinIO KES projects “are archived and no longer maintained”, and that MinIO “does not provide product support, security updates, or security advisories for them”.
  • The Docker Hub API returns “object not found” for minio/minio and minio/mc. Some guides suggest quay.io instead; my anonymous pull check there did not get pull access, so test before you rely on it.
  • The old community docs URL redirects to the AIStor documentation.
  • AIStor Free, per MinIO’s pricing page, is free to download and includes the full AIStor feature set for a single-node deployment, with redistribution prohibited. Multi-node needs a paid tier (Enterprise Lite is described for deployments below 400 TiB).

The source is still there under AGPLv3 and you can still build it. What is gone is a maintained, published community build. Any MinIO you run today is a fixed snapshot, and any security fix after October 2025 is yours to find and apply.

What to look for in an alternative

Unlearn one habit first: treating “S3 compatible” as a yes or no label. Every self-hosted store implements a subset of the S3 API. The useful question is whether it covers the subset your applications call: usually multipart upload, presigned URLs, versioning, object lock, lifecycle rules, bucket policies, server-side encryption and event notifications.

The alternatives, one by one

Ceph Object Gateway (RGW)

  • Licence and governance: LGPL 2.1 or LGPL 3 for the core, per the Ceph COPYING file. The Ceph Foundation sits under the Linux Foundation.
  • Architecture: RGW is an HTTP gateway built on librados that speaks S3 and Swift on top of a Ceph storage cluster. The cluster is run by Monitors, Managers and OSDs, plus the gateways. Data protection is set per pool: replicated (the default) or erasure coded.
  • S3 limits in its own docs: the feature table lists bucket replication as “Partial: permitted only across zones” and notes a different set of canned ACLs. Versioning, lifecycle, bucket policy, website, notifications and object lock configuration are documented.
  • Footprint: the minimum hardware page asks for at least 4 GiB RAM per OSD and at least 5 GB RAM plus 100 GB of storage (SSD strongly urged) per monitor. Ceph pays off when you also need block or file storage, or a team already runs it.
  • Maturity: named releases go back to Argonaut (v0.48). Active releases are Tentacle (20.2.x, latest 20.2.4 on 18 August 2026, estimated end of life 1 June 2027) and Squid (19.2.x, latest 19.2.6, estimated end of life 31 October 2026). The v21.1.x tags are release candidates under Ceph’s own numbering, not stable releases. Checked on 6 October 2026.

SeaweedFS

  • Licence and governance: Apache 2.0. The README also points to a separate SeaweedFS Enterprise Edition at seaweedfs.com, with features such as custom erasure coding ratios.
  • Architecture: masters (one, or a Raft group of three) track volumes, not files. Volume servers store blobs in append-only volumes with a small in-memory index. Filers add a directory tree whose metadata lives in a store you choose, such as LevelDB, PostgreSQL, MySQL or Redis. The S3 gateway is stateless. Hot data is replicated, and erasure coding (RS 10+4 in the open source version) is applied to warm volumes in the background.
  • S3 limits in its own docs: the wiki lists versioning, object lock, SSE-S3, SSE-KMS, SSE-C, bucket policies and IAM as supported. It lists bucket notifications, bucket replication, website configuration, SelectObjectContent and RestoreObject as not supported, and lifecycle transition rules as not supported. It also notes that a file and a folder cannot share the same path, and only “/” works as a delimiter.
  • Footprint: one weed binary can run everything for small setups. For CI users with many buckets: each bucket is its own collection, which the wiki says usually uses 7 volumes of 30 GB by default, so lower the volume size limit.
  • Maturity: the GitHub repository dates from July 2014. The latest release is 4.48 (28 September 2026), checked on 6 October 2026.

Garage

  • Licence and governance: AGPLv3, developed by Deuxfleurs, a non-profit hosting organisation, with EU NGI funding acknowledged on its site. This is the same licence MinIO used, so if the licence was your reason to leave, Garage does not change it.
  • Architecture: written in Rust and designed for geo-distributed clusters over ordinary internet links. It does not use Raft for ordering requests. Data is chunked into blocks, deduplicated and optionally compressed with zstd. Redundancy is by replication only; the design page lists erasure coding as a non-goal. With replication_factor = 3 and consistency_mode = "consistent", writes and reads use a quorum of 2 and the docs mark read-after-write consistency as yes.
  • S3 limits in its own docs: no bucket versioning (GetBucketVersioning is a stub), no object lock, no ACLs or bucket policies (Garage uses its own per-key, per-bucket permissions), no SSE-S3 or SSE-KMS (SSE-C is implemented), lifecycle limited to expiration and aborting incomplete multipart uploads, and no replication API. Missing endpoints return 501 Not Implemented. Static website hosting is supported.
  • Footprint: the project states 1 GB RAM, at least 16 GB disk, and a network of 200 ms or less latency with 50 Mbps or more. This is the lightest option in this list.
  • Maturity: the earliest tag is v0.2.0 (March 2021), v1.0.0 came in April 2024 and v2.0.0 in June 2025. The latest is v2.4.1 (8 September 2026), with a v1.x release as recent as v1.3.1 (January 2026). Checked on 6 October 2026.

RustFS

  • Licence and governance: Apache 2.0. The README does not describe a governance model or foundation.
  • Architecture: written in Rust and deliberately close to MinIO’s model: erasure sets, pools, bitrot protection, healing, and an xl.meta object format. Its docs say pool layout rules follow MinIO, but automatic parity selection differs.
  • S3 coverage in its own docs: the README marks versioning, object lock, SSE, KMS, lifecycle and tiering, S3 Select, bucket and site replication, event notifications, IAM, OIDC and a web console as available. S3 Tables and “MinIO On-Disk Compatibility” are marked preview. The compatibility notes say ACL authorization is intentionally unsupported.
  • Reading old MinIO drives: this sits behind a rio-v2 feature that is not in the default build. The default build cannot read objects MinIO encrypted, and SSE objects with keys in KES or a KMS plugin fail closed in every build. For most teams an S3-to-S3 copy is the safer path.
  • Maturity: this is the youngest option. The repository was created in November 2023, the first alpha was published on 2 July 2025, 1.0.0 on 16 September 2026 and 1.0.1 on 3 October 2026. Checked on 6 October 2026. The README includes a performance comparison against MinIO; that is the project’s own claim and I have not repeated it.

Apache Ozone

  • Licence and governance: Apache 2.0, a top-level Apache Software Foundation project.
  • Architecture: Ozone Manager holds the namespace, Storage Container Manager manages containers of blocks on datanodes, and metadata replication uses Apache Ratis (Raft). It offers replication and erasure coding, and Hadoop filesystem interfaces next to the S3 gateway.
  • S3 limits in its own docs: the latest docs say bucket versioning, object locking, server-side encryption through the S3 API, and S3 Select are not supported; ACLs, bucket policies, CORS and website hosting are not fully implemented; lifecycle, replication and event notifications are on the roadmap. Secured clusters issue S3 secrets through Kerberos.
  • Maturity: releases 2.2.1 and 2.1.2 came out in August and September 2026, checked on 6 October 2026. Ozone suits teams already in the Hadoop and Spark world more than general CI or backup use.

At a glance

Store

Licence

Redundancy

Versioning and object lock

Footprint

Ceph RGW

LGPL 2.1 or 3

Replication or erasure coding per pool

Documented

Heavy

SeaweedFS

Apache 2.0

Replication, erasure coding for warm data

Supported per wiki

Light to medium

Garage

AGPLv3

Replication only

Not supported

Very light

RustFS

Apache 2.0

Erasure coding

Marked available

Light to medium

Apache Ozone

Apache 2.0

Replication or erasure coding

Not supported

Heavy

A decision guide

Answer these with your team and write the answers down:

  1. Which S3 features do your applications really call? Pull this from code search and gateway logs, not memory. Versioning, object lock and bucket policies alone remove some options.
  2. Is the store holding primary data, backups that must be immutable, or throwaway CI and test data? Object lock needs are very different across these.
  3. Do you need a permissive licence (Apache 2.0) by policy, or is AGPLv3 acceptable after review? This decides between Garage and the rest.
  4. How many sites, and how good are the links between them? Garage is built for several small sites over the internet; Ceph and Ozone expect a proper data centre network.
  5. Who will operate it at 2 AM? A team that already runs Ceph should probably use RGW. A two-person platform team may prefer one binary.
  6. How much maturity do you need? Ceph and Ozone have long release histories and foundation governance; RustFS reached 1.0 in September 2026.
  7. Is the paid AIStor route acceptable for some clusters? For a single node, AIStor Free exists; check its licence terms with your legal team first.
  8. Where does every MinIO image and binary in your estate come from today? Make an inventory of compose files, Helm values and CI jobs before anything else, because those break first.

If the answers say “dev and CI only, simple buckets”, Garage or SeaweedFS is usually enough. If they say “versioning and object lock for backups, permissive licence”, test SeaweedFS and RustFS hard. If they say “large, long-lived, block, file and object on one platform”, Ceph RGW is the conservative choice. Hadoop-heavy shops should look at Ozone.

Practice drill: move one bucket without surprises

Do this in a sandbox with a copy of a real bucket, not production. The commands use the AWS CLI and rclone, because mc binaries are no longer served.

  1. Check each setting against the candidate’s S3 compatibility page. Anything missing is a design decision now, not a surprise later.
  2. Start the candidate using its own quick start, create the bucket, and re-apply versioning, lifecycle and policy by hand where supported.
  3. Compare counts and sizes on both sides with rclone size old:app-data and rclone size new:app-data, and keep the output in your change record.
  4. Test your SDK calls against the new endpoint: a multipart upload of a file larger than your part size, a presigned GET URL made with aws s3 presign (and a presigned PUT from your own SDK if your application uses one), a versioned overwrite and delete if you use versioning, and an object lock retention if you use it. Newer AWS SDKs send extra integrity checksums by default; if a store rejects them, the documented AWS_REQUEST_CHECKSUM_CALCULATION=WHEN_REQUIRED setting is a quick way to confirm that is the cause.
  5. Cut over with a fallback. Point one non-critical client at the new endpoint through configuration, keep the old MinIO running read only, and run a final rclone sync before switching the rest. Keep the old store until one full backup and restore cycle has passed on the new one.
  6. Write it down: what was missing, what you changed in code, and how long the copy took on your hardware. Label any timings as your own run.

Copy the current objects with rclone, with two remotes configured (old and new):

rclone sync old:app-data new:app-data --checksum --progress
rclone check old:app-data new:app-data --one-way

rclone’s docs note that for multipart or SSE objects the ETag is not an MD5 of the data, so rclone stores its own MD5 in metadata. Where hashes cannot be compared, run rclone check --download on a sample. A plain sync copies current versions only; older versions are visible with --s3-versions and need a separate plan if you must keep them.

Inventory the source. For each bucket, record the settings a copy tool will not move for you:

aws --endpoint-url http://old-minio:9000 s3api get-bucket-versioning --bucket app-data
aws --endpoint-url http://old-minio:9000 s3api get-object-lock-configuration --bucket app-data
aws --endpoint-url http://old-minio:9000 s3api get-bucket-lifecycle-configuration --bucket app-data
aws --endpoint-url http://old-minio:9000 s3api get-bucket-policy --bucket app-data

Also note IAM users, access keys, event targets and any bucket notification setup.

The drill takes a day for a few buckets, and leaves you with a tested runbook. That is worth more than any comparison table, including this one.

Sources

comments powered by Disqus

Releted Posts

Elasticsearch and OpenSearch: revisit the fork before you pick one

Many teams still talk about “our Elastic cluster” when the cluster is actually Amazon OpenSearch Service, or about “OpenSearch” when half the code paths still use an old Elasticsearch client.

Read more

Kafka and Redpanda: revisit the choice before you treat them as the same bus

Many teams say “we run Kafka” when they mean “our services talk to a Kafka-compatible broker”. That shortcut was useful when one open source broker dominated the protocol.

Read more

OpenTofu and Terraform: revisit the fork before you pick one

Many teams picked Terraform years ago and have not looked at the choice since. In August 2023 its licence changed and a fork appeared.

Read more