Upgrade

This section documents best practices and tutorials for updating the MinIO AIStor server on Linux and Kubernetes infrastructure to a newer release.

All MinIO AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds.

Applications using MinIO or S3 SDKs can rely on the built-in transparent retry to ensure continuous operations during the update procedure.

Use the following commands to back up your cluster settings before starting the decommissioning process:

• mc admin cluster bucket export
• mc admin cluster iam export
• mc admin config export

You can use these snapshots to restore bucket, IAM, and cluster settings to recover from user or process errors as necessary.

The Release Notes page provides a reference for identifying the changes applied in each release. Review the associated release notes between your current MinIO AIStor version and the newer release so you have a complete view of any changes.

Pay particular attention to any releases that are not backwards compatible. You cannot trivially downgrade from any such release.

Each release also publishes SBOM and dependency artifacts. Compare CycloneDX or SPDX SBOMs between your current and target versions to identify dependency changes and review any newly introduced components before upgrading.

MinIO AIStor uses a testing and validation suite as part of all releases. However, no testing suite can account for unique combinations and permutations of hardware, software, and workloads of your production environment.

You should always validate any MinIO AIStor upgrades in a lower environment (Dev/QA/Staging) before applying those upgrades to Production clusters, or any other environment containing critical data. Performing updates to production environments without first validating in lower environments is done at your own risk.

For MinIO AIStor clusters that are significantly behind latest stable (6+ months), consider using MinIO SUBNET for additional support and guidance during the upgrade procedure.

For clusters on Windows or macOS, you can upgrade the Server at any time by performing a binary replacement on the server and restarting the process.

For clusters in a container such as Podman or Docker, use the relevant pull command to retrieve the latest image and restart your container process. If you have pinned to a specific container image, replace that image with the latest release RELEASE.2026-04-11T03-20-12Z

System maintenance operations such hardware, firmware, or OS upgrades may require minutes or hours to complete during which all software running on that host is unavailable. For upgrade procedures that require longer periods of downtime, use a rolling upgrade pattern at the host level to take one or more systems offline at a time. MinIO AIStor erasure coding supports availability if one or more nodes require downtime during system maintenance.

The number of hosts you can safely take offline depends on the erasure code stripe and parity used for deploying the cluster. For example, consider a cluster with 8 servers and 8 drives each with a stripe size of 8 and parity of 3. As per the erasure code calculator, the cluster can tolerate up to 3 server failures while maintaining read and write quorum. Taking 2 nodes down at a time ensures a buffer of 1 additional node which could fail incidentally while maintaining cluster operations.

Certain architectures, such as rack-aware clusters, may support taking a larger number of hosts down for maintenance at once. Consult with MinIO support using SUBNET before conducting maintenance operations for additional oversight and guidance.

MinIO AIStor supports downgrading to previous versions, except where explicitly stated otherwise. Any features, improvements, or APIs not supported in the previous versions become unavailable upon downgrade. Take precautions to coordinate with any client applications before committing to a downgrade operation.

A fully upgraded cluster bumps the API version immediately once all nodes are online and support the newer version, which leaves no window to roll back after a clean upgrade. Set MINIO_API_BUMP_BAKE_TIME to a duration, for example 1h, on every node to hold the previous API version for that long after the cluster is fully upgraded before committing the bump.

During the bake time, the cluster continues to write data in the previous version’s format, so downgrading the server binary remains safe. This mirrors the bake time of a blue/green deployment: the older release stays recoverable until the window elapses, after which the bump commits automatically and the switch becomes permanent.

The default is 0, which bumps immediately. Because new API-version features stay inactive until the bump commits, a longer bake time also delays their availability. To wait out the bake time, keep all nodes online on the newer release for the configured duration; the cluster commits the bump on its own once the window passes.

MinIO AIStor supports upgrading a cluster from the open-source MinIO on Linux, Kubernetes, or airgapped environments. Upgrade procedures guide you through replacing the server binary, adding the license, updating Custom Resource Definitions, and restarting the cluster on MinIO AIStor.

For detailed procedures, see Upgrade from open-source MinIO.