MinIO Support After Project Archival

Go straight to an AI summary of this blog post instead

On 13 February 2026, MinIO Inc. archived the community minio repository. The project had passed 59,000 stars and over one billion Docker pulls. The installed base spans Kubernetes object storage, CI/CD artifact repositories, ML model registries, and on-prem data lakes. All of it now runs on a codebase that no longer receives upstream security fixes.

For teams that chose MinIO to run S3-compatible object storage on servers they manage, the practical question is where to find ongoing MinIO support and security maintenance now that upstream support is no longer provided. This post walks through what changed, the realistic options, and where TuxCare’s Endless Lifecycle Support fits.

What changed and when

The shift happened in stages over roughly fifteen months.

In early 2025, MinIO Inc. removed most administrative features from the community edition’s web console, leaving only a basic object browser. Full management capabilities were moved to the company’s commercial product. Pre-compiled binary releases tapered off during the same period; the community edition began shipping only as source code.

On 3 December 2025, the company placed the community repository into maintenance mode. New features were halted, and security fixes were handled case by case rather than according to any committed schedule.

On 13 February 2026, the repository was archived on GitHub. It is now read-only: no new commits, no new pull requests, no further security fixes from MinIO Inc. on the community codebase. Official MinIO support has shifted entirely to AIStor, the commercial successor.

Several CVEs have already been disclosed against the last community release, including CVE-2026-39414, CVE-2026-34204, GHSA-9c4q-hq6p-c237, and GHSA-hv4r-mvr4-25vw. MinIO Inc. has shipped fixes for some of these in AIStor, but no patches are reaching the archived community codebase that the existing installed base is running. For teams that want to keep their existing deployment, this is a clear MinIO support gap.

Why this matters for operators

Two pressures converge for any team running MinIO in production.

The first is compliance. PCI DSS, HIPAA, SOC 2, and FedRAMP all impose remediation timelines for known vulnerabilities – typically 30 days for high-severity findings, sometimes shorter. A “case-by-case” upstream policy was already a tight fit for these timelines. An archived repository with no further fixes is a non-starter. Audit findings begin to accumulate the moment a new CVE lands and a deadline starts ticking.

The second is risk drift. Every new CVE disclosed against the last community release makes the operating position harder to defend internally. Security teams escalate. Risk registers grow. Doing nothing has its own deadline, set by whichever audit comes next.

The options on the table

Operators running MinIO today have four realistic paths.

Option	Cost	What it requires	Trade-off
Stay on the archived release	$0	Nothing	CVE exposure grows; not viable under most compliance regimes
Migrate to AIStor	Reported from ~$96K/year for ≤400 TiB usable + migration costs	Product migration, new licensing, retraining	Different product, different operational model
Migrate to an OSS alternative	Engineering time	Data transfer, S3-compatibility validation, re-certification	Substantial project; no alternative is a one-for-one replacement
Subscribe to a third-party maintenance program	Subscription fee	Continue running the existing MinIO	Depends on the program’s scope and delivery model

Open-source alternatives worth shortlisting include SeaweedFS, Garage, RustFS, and Ceph RGW. Each is a real project with active maintainers and a different architectural footprint from MinIO. None of them is a drop-in replacement.

The fourth option – third-party MinIO support – covers programs that fork the community codebase and continue patching it. Their scope, delivery format, and commitments vary. TuxCare’s Endless Lifecycle Support (ELS) for MinIO is one such program. The rest of this post walks through what it provides and how it differs from the alternatives.

What ELS for MinIO provides

TuxCare’s Endless Lifecycle Support for MinIO keeps customers on the MinIO codebase they already run. Patches are delivered as binary packages (RPM, DEB, and Go binaries) that drop into existing VM, bare-metal, and on-prem deployments without re-architecting the runtime.

Each subscription includes:

Rapid SLA-backed CVE response for as long as the customer needs the supported release
Complete coverage of both direct and transitive dependencies at no extra cost
Tested updates that preserve compatibility with existing deployments
Plug-and-play integration with existing workflows and CI/CD pipelines
Signed, tamper-proof updates from TuxCare-hosted repositories
A Software Bill of Materials (SBOM) is shipped with each patched release. Because MinIO is a Go binary with vendored dependencies, the SBOM provides operators and auditors with a single, authoritative manifest of what’s actually in each release.
Vulnerability Exploitability eXchange (VEX) context showing which CVEs in the SBOM are already remediated, so security teams can focus attention where action is still required
24/7 expert support covering CVE triage, custom patch requests, and troubleshooting

Patches are owned by TuxCare engineers and shipped on an SLA-backed cadence. The customer keeps running the codebase they validated, with MinIO support handled by a vendor that backs the work commercially.

How ELS differs from other MinIO support options

Three characteristics define how ELS approaches MinIO maintenance.

The first is the delivery model. ELS ships as binary packages. Alternative maintenance programs ship only as hardened container images, which suits Kubernetes-native shops but does not fit deployments running MinIO on VMs, bare metal, or on-prem. A customer running MinIO outside of containers cannot adopt a container-only solution without redesigning the deployment.
The second is the scope of coverage. ELS commits to backporting fixes for both direct and transitive dependencies as part of the standard subscription. MinIO bundles a deep tree of Go dependencies, and CVEs against those vendored deps regularly require non-trivial backports. That work is part of the standard ELS commitment, not an extra-cost item.
The third is delivery commitment. Patches arrive on a published SLA-backed cadence, with response times tied to severity. Compliance frameworks like PCI DSS, HIPAA, SOC 2, and FedRAMP set hard remediation deadlines, and a predictable delivery schedule is what lets operators meet them.

These characteristics matter most for operators running MinIO outside of containers, especially under compliance pressure.

What to do next

If you’re running MinIO in production and need ongoing MinIO support beyond upstream archival, TuxCare’s Endless Lifecycle Support is available today.

Learn more or reach out to our team to discuss your environment requirements at: https://tuxcare.com/endless-lifecycle-support/minio-eol-support/.

Summary