MinIO Community Edition Archived: Planning the Move to AIStor or Elsewhere

The open-source MinIO repository on GitHub was archived on 25 April 2026 and is now read-only. Its README states that the repository is no longer maintained, that the community edition is distributed as source code only, and that legacy binaries will not receive updates. MinIO’s current product is MinIO AIStor, which is commercially licensed and offered as AIStor Free, AIStor Enterprise Lite and AIStor Enterprise.

Many lakehouses, backup systems and AI pipelines still run community MinIO. This article explains what changed, what each path forward involves, and how to plan a move to AIStor if that is the route you choose. It is not legal advice: your legal team should review the licence terms that apply to you.

What changed, in MinIO’s own words

The minio/minio repository shows that it “was archived by the owner on Apr 25, 2026”. Its README makes four points that matter for operators:

• The repository is no longer maintained.
• The community edition is distributed as source code only. MinIO no longer provides pre-compiled binary releases for it.
• Older binaries remain downloadable, but will not receive updates.
• The source remains licensed under the GNU AGPL v3.0.

The MinIO pricing page adds that the AGPLv3 edition’s codebase is frozen, with no new features, bug fixes or security patches, and that “MinIO AIStor is commercially licensed.”

The AGPLv3 code does not disappear. Anyone can still build it from source under the AGPLv3. What ends is upstream maintenance. Any vulnerability found after the freeze will not be fixed upstream, so a team that stays on community MinIO takes on that risk itself.

The AIStor editions

The pricing page lists three AIStor editions. Prices are omitted here because they change and depend on contract.

Edition	Architecture	Licence	Support described
AIStor Free	Full-featured, single-node deployment	Free to download and deploy; redistribution prohibited	Self-service community Slack and documentation
AIStor Enterprise Lite	Horizontally scalable, multi-node, for smaller capacities	Commercial, with a trial licence	Lite SUBNET subscription, with an optional direct-to-engineer add-on
AIStor Enterprise	Horizontally scalable, multi-node	Commercial, with a trial licence	Enterprise SUBNET subscription with direct-to-engineer support

Two details deserve attention. First, AIStor Free is a single-node edition, so it does not replace a distributed community MinIO cluster that depends on erasure coding across several nodes. Second, Enterprise Lite has a capacity ceiling, and the pricing page says deployments that grow past it are moved to Enterprise. Capacity growth should be part of the cost model from the start.

Features, entitlements and support terms differ by edition and contract. Confirm them with MinIO in writing for the edition you plan to run.

Three paths forward

There are three realistic options for a community MinIO deployment. None is right for every case.

1. Upgrade in place to AIStor. MinIO documents an upgrade procedure that keeps the existing data and configuration. This is usually the least disruptive option for applications, because the S3 endpoint and buckets stay the same. It introduces a commercial licence and ongoing subscription cost.
2. Migrate to a different S3-compatible store. Applications that use standard S3 APIs can move to another object store, managed or self-hosted. This avoids the AIStor licence but means copying data, re-creating buckets, policies and lifecycle rules, and re-testing every client.
3. Stay on frozen community MinIO for a defined period. This can be acceptable for isolated, non-production or short-lived systems while a migration is prepared. It should have an end date, a compensating control for network exposure, and an owner who tracks vulnerability disclosures.

A fourth idea sometimes comes up: building and patching the AGPLv3 source in-house. The licence allows it, but it turns the team into the maintainer of a storage system. That means tracking vulnerability reports, writing and testing fixes, producing builds and meeting the AGPLv3’s obligations if the modified software is offered to others over a network. Few organisations want that responsibility for a system that holds their data of record, and it should be costed honestly against the other three options.

The deciding factors are usually the same: how much data you hold, how many clients depend on MinIO-specific features such as replication, batch jobs or the admin API, what your security policy says about unmaintained software, and the cost of each option over several years.

What the in-place upgrade to AIStor involves

MinIO’s upgrade from open-source MinIO overview covers Linux, Kubernetes and airgapped environments. It recommends testing the procedure in a lower environment before production, and lists the phases as backup, installing the AIStor binary or operator, configuring the licence, upgrading and validating.

The most important statement is on the platform guides: “Upgrading from open-source MinIO to MinIO AIStor is permanent and cannot be reversed.” Plan as if there is no rollback other than restoring data to a separate system.

On Linux, the Linux upgrade guide describes these steps:

1. Export cluster configuration, bucket metadata and IAM metadata with mc admin config export, mc admin cluster bucket export and mc admin cluster iam export, and store the files securely.
2. Download the AIStor binary for the node architecture.
3. Replace the minio binary on every node.
4. Restart all nodes at the same time with mc admin service restart. The guide warns against rolling restarts, because nodes can start with incompatible binaries.
5. Verify health and version with mc admin info.
6. Register the licence, preferably with mc license register, which stores it in the object store and replicates it to all nodes.

On Kubernetes, the Kubernetes upgrade guide replaces the community operator and Tenant with the aistor-operator and aistor-objectstore Helm charts. It is tested from operator 6.x and 7.x, requires Helm 3.17 or later and cluster-admin permissions, and passes the licence to the operator install. Deleting the Tenant takes the object store offline until the new ObjectStore is created, although persistent volume claims are kept and reused. This is a planned outage, not a rolling change.

The overview page also flags hardware that may limit performance after the upgrade, such as older drives and CPUs, and suggests a new cluster on recommended hardware in some cases. For clusters well behind the latest release, it points to MinIO’s SUBNET support.

Effects on the lakehouse and AI stack

Object storage sits underneath many other systems. Before any change, map what depends on it:

• Query engines and table formats. Trino and Spark catalogs that read Apache Iceberg tables reference the S3 endpoint, credentials and TLS settings. An in-place upgrade usually keeps these unchanged. A migration to another store means updating every catalog and re-validating table metadata paths. Our enterprise lakehouse work treats this as a single, tested change.
• Replication and backup. Site replication, bucket replication and backup tools may rely on MinIO-specific behaviour. Test them after the change, including a restore.
• Identity. Policies, service accounts and OIDC or LDAP integrations are exported and imported, but their behaviour should be checked with real clients.
• Monitoring. Metrics endpoints, dashboards and alerts may need updates after a product change.

Timing matters too. An in-place upgrade on Kubernetes needs an outage window, and a migration to another store needs a period of dual running while data copies and clients move over. Both are easier to schedule when the decision is made early, rather than after a vulnerability forces it.

AIStor adds capabilities that community MinIO does not have, such as the AIStor Tables Iceberg catalog. Adopting them is a separate decision from the upgrade itself, and their availability depends on the release and licence in place.

A planning checklist

• Record every MinIO deployment, its release, node count, capacity, exposure and owner.
• Classify each one: production, non-production, or retiring.
• Confirm with your security team whether unmaintained software is acceptable, and for how long.
• Compare the three paths per deployment, including multi-year cost and capacity growth.
• For AIStor, confirm edition, capacity limits, features and support terms in writing.
• Rehearse the upgrade or migration on a copy, including a full outage window on Kubernetes.
• Export configuration, bucket and IAM metadata, and take a data backup that does not depend on the cluster being upgraded.
• Re-test every client: query engines, pipelines, backup tools and applications.
• Document the licence held, where it is registered and when it renews.

How Bassirah can help

MinIO is a Bassirah strategic technology partner. We help teams inventory community MinIO deployments, compare upgrading to AIStor with other routes, and rehearse whichever change they choose before production. See our MinIO AIStor partner page and migration and modernization services. Edition, licensing and support entitlements are confirmed with MinIO in each engagement.