If you run MinIO today or are evaluating it, there is one fact to establish before looking at any feature matrix.

The github.com/minio/minio repository was archived on 25 April 2026. The README carries a THIS REPOSITORY IS NO LONGER MAINTAINED notice, and the community edition is now distributed as source code only — pre-compiled binaries are no longer published.

So this post is not about whether open source or commercial is the better choice. That question no longer applies. Instead it covers the three things you actually need in order to decide.

What you will get from this post

• The precise state of MinIO OSS as of September 2026, and the timeline that led here
• What differs between OSS and AIStor — and which of those claims are verifiable versus vendor-stated
• What source-only distribution and AGPLv3 now put on your plate
• Three paths for teams already running MinIO OSS, with recommendations by profile

Everything here reflects September 2026. This is a fast-moving topic, so re-check the primary sources before making a decision that matters.

The companion post, MinIO OSS Production Issues, catalogs the concrete operational problems. This post is about what to decide; that one is about what is actually broken.

---

Part 1. The State of MinIO OSS in September 2026

1.1 What is verifiable

Restricting ourselves to what can be confirmed directly from the repository and official docs:

The operationally heavy item here is "will not receive updates." It does not mean there will be no new features. It means there will be no bug fixes and no security patches.

1.2 How we got here

This was not a single announcement. It unfolded in stages over four years.

The May 2025 console reduction became a trust issue less because of the features than because of how it happened: no advance notice and no warning in the initial changelog. Teams upgraded and found the management UI simply gone.

1.3 What disappeared from the web console

What remains in the community console is roughly bucket creation and object browsing. The following moved to the mc CLI only:

• User management
• Access policy management
• Bucket deletion
• Bucket permission settings
• Configuration changes, real-time monitoring, replication controls

The capabilities were not removed outright — they moved to the CLI. But the weight of that difference varies enormously by organization.

• Teams with existing automation — if you were already scripting mc, the practical impact is small.
• Teams that operated through the console — runbooks, self-service for non-engineering staff, and the fast visual check during an incident all vanish at once. That rewrite cost lands on you.

---

Part 2. What Actually Differs Between OSS and AIStor

2.1 First, what is the same

The core object storage functionality is still in OSS. Features present at the freeze do not disappear.

• S3-compatible API, erasure coding, bitrot protection
• Distributed deployment, server pool expansion
• Versioning, object lock (WORM), lifecycle and tiering
• Bucket replication, site replication
• Server-side encryption, IAM policies, LDAP and OIDC integration
• Prometheus metrics

A MinIO OSS cluster that runs well today will not stop tomorrow. That is worth stating plainly. The problem is not the static feature set — it is the risk that accumulates over time.

2.2 AIStor-exclusive capabilities

The capabilities MinIO states are AIStor-only:

If you run a lakehouse, AIStor Tables carries the most weight on this list. Putting an Iceberg REST catalog inside the object store means one whole operational component goes away. We covered what it takes to stand up a separate catalog in Building an Apache Iceberg REST Catalog Server; if you know that operational burden, this line item will register.

2.3 Separating vendor claims from verifiable fact

Care is needed here. MinIO's own comparison material states:

• 13,061 commits of divergence between AIStor and OSS
• 245 source files and 24 new internal packages absent from OSS
• 47+ critical fixes exclusive to AIStor — preventing data loss, corruption, split-brain
• 85+ high-priority fixes — memory leaks, lock contention, throughput degradation
• With RDMA, up to 3.75x lower latency and 90% CPU savings during erasure coding

All of these figures are MinIO's own and cannot be independently verified. For the "47+ critical fixes" in particular, no CVE identifiers and no individual vulnerability descriptions have been published. The benchmark methodology is likewise undisclosed.

That does not make the information useless — the direction is plausible on its face, since one side is actively developed and the other stopped in October 2025. But do not quantify your risk off the number 47. The verifiable fact is simply this: no fix of any kind has landed in OSS since October 2025. That sentence alone is sufficient for a risk assessment.

The split looks like this:

---

Part 3. What Source-Only Distribution Puts on Your Plate

The end of binary distribution is not a "just run one more build" problem. Responsibility shifts from the vendor to you.

3.1 What you now own

• Build pipeline — pinned Go toolchain, reproducible builds, artifact storage. If you did not have this, you need it now.
• Container images — if you relied on official images, you now build, sign, and scan them in-house.
• Supply chain verification — signed artifacts, SBOM, vulnerability scanning are all yours.
• Security backporting — if an upstream vulnerability appears, no one will fix it. You patch it yourself or accept it.
• Audit response — you must answer "where did this binary come from and who verified it?"

3.2 AGPLv3 has not changed, but its weight has

The license is the same. The situation around it is not.

AGPLv3 triggers source disclosure obligations even when software is offered as a network service. Until now there was a safety valve: "if this becomes a problem, buy the commercial license." That commercial license is now AIStor, and moving to it is not a license purchase — it is a move to a different product.

MinIO's README states that commercial use is "at your own risk" with no warranties under AGPLv3.

If you embed and ship MinIO inside a product you sell, this is not a technical review item — it is a legal review item. Engineering should not decide it alone.

---

Part 4. Three Paths

If you already run MinIO OSS, there are realistically three options. Here is an honest account of when each makes sense.

4.1 Option A — Stay on frozen OSS

When this is reasonable

• Internal-only deployments with no internet exposure
• Small, stable, with no growth planned
• Non-production — development, test, PoC
• Data that can be regenerated if lost (caches, derived data)

What you accept

• Any vulnerability discovered from here is permanently open. Only mitigation (network isolation, access control) is available.
• Known bugs stay forever. You work around them.
• Compatibility friction with new hardware, OS, and Go versions accumulates over time.
• Every time staff turns over, someone has to explain why you are on this frozen version.

What you must do anyway

Choosing A is not the same as doing nothing. At minimum:

• Record the exact deployed version and archive the binary internally
• Mirror a source snapshot to an internal repository
• Re-audit network exposure — block external access, separate management ports
• Actually rehearse backup and restore
• Document an exit plan and a review date (six months is a reasonable cadence)

Staying is not a permanent answer — it is a deferral with a deadline. Option A without a review date is just neglect.

4.2 Option B — Move to AIStor

When it earns its cost

• You have regulatory requirements — FIPS 140-3, security patch SLA, audit trail. There is no substitute here.
• You run a lakehouse — if AIStor Tables removes a separately operated Iceberg catalog, the TCO math changes.
• You need zero downtime — rolling updates do not exist in OSS.
• Multi-tenancy — you need per-bucket QoS.
• You already have deep MinIO operational knowledge and automation, making this the lowest-cost path.

What to weigh

• Quantify the subscription cost against the risk and migration effort of options A and C on the same basis.
• Go in knowing you are accepting lock-in. Once you depend on AIStor Tables or Delta Sharing, the cost of leaving rises sharply.
• Assess vendor risk. You need a view on how the commercial product policy of a company that wound down its OSS this way may evolve. That is vendor due diligence, not a technical evaluation.

4.3 Option C — Migrate to something else

If you were using the S3-compatible API, migration is often easier than expected. It is frequently a change of endpoint, credentials, and operational procedure rather than application code.

Starting points by profile

• Already running Ceph, or need a unified storage platform → Ceph RGW
• Hundreds of millions to billions of small files, simplicity first → SeaweedFS
• Small clusters across multiple regions → Garage
• On-premises mandatory plus vendor accountability → Cloudian
• No on-premises constraint → price out cloud S3 first. Once you include your own operational headcount, the result flips more often than people expect.

Verify before you migrate

S3 compatibility is a matter of degree. Nothing is 100% compatible. Validate these against your real workload before committing:

• Multipart upload behavior and part size limits
• Versioning and object lock (WORM) semantics
• Presigned URL expiry and signature versions
• Conditional requests (If-Match, If-None-Match) — table formats such as Iceberg depend on these
• Listing performance and pagination behavior
• Server-side encryption modes and key management integration

That second-to-last item matters most. Table formats like Iceberg and Delta can rely on conditional requests for commit atomicity, so a compatibility gap there corrupts data quietly. Do not skip this check when replacing the storage under a lakehouse.

---

Part 5. How to Approach It

5.1 Judge risk by exposure, not by size

"We're small, so we're fine" is frequently wrong. These are the axes that matter:

If two or more land in the right column, we do not recommend option A.

5.2 Recommended sequence

1. Inventory — deployed version, node and drive layout, erasure set configuration, data volume and object count, features actually in use
2. Exposure and risk assessment — grade against the table above
3. Issue review — use the checklist in MinIO OSS Production Issues to identify what you already carry
4. Cost out all three paths — staying (including risk cost), AIStor subscription, migration effort, on the same basis
5. Decide, with a deadline — whatever you choose, write the review date into the document

5.3 Closing

MinIO OSS was a good choice for a long time. We covered the structural advantages of pairing it with Trino in Why MinIO Beats HDFS, and that architectural reasoning still holds. The advantages of object storage over HDFS are not specific to one product.

What has changed is which product you implement that architecture with. The sustainability of an open source project does not appear in any feature list, yet it determines your operating cost three years out. This episode is a reminder of that.

When you put open source at the core of your infrastructure, evaluate governance structure and revenue model alongside features. For a project owned by a single company, a commercial pivot is always on the table.

---

References

• minio/minio GitHub repository — archival notice, source-only distribution
• MinIO AIStor vs MinIO OSS: Technical Comparison — MinIO's own comparison
• Critical WEB UI features removed in Community Edition (Issue #21584)
• Deprecation of the MinIO gateway
• MinIO AIStor vs OSS: 13,061 Commits of Divergence — third-party analysis

---

If you need an assessment of your MinIO deployment, a feasibility review for AIStor, or a migration design for alternative storage, get in touch. Data Dynamics supports the design and operation of object-storage-based lakehouses.