Upgrade MinIO AIStor on Linux

This page documents upgrade procedures for AIStor Server clusters on bare-metal Linux infrastructure.

Each procedure below replaces the binary on every node and then restarts the cluster. Decide how you want the cluster to restart before you start. By default all nodes restart at the same time, which typically finishes in under 3 seconds and is the mode MinIO recommends. A rolling restart keeps the cluster serving throughout but takes longer, requires a load balancer, and still reconnects the clients attached to each restarting server. See Choose a restart mode.

In site-replicated deployments, Security Token Service (STS) tokens are signed with the site replicator service account credentials rather than the root credentials.

Any STS tokens previously signed by root credentials are no longer valid after upgrading to a version that includes this change. After the upgrade, clients must regenerate their STS tokens as usual.

Upgrade MinIO AIStor using DEB or RPM

Use these steps to upgrade a MinIO AIStor cluster where the server process is managed by systemctl, such as those created using the MinIO AIStor DEB/RPM packages.

This procedure assumes you have the MINIO_CONFIG_ENV_FILE variable set on all MinIO AIStor nodes.

Update the MinIO AIStor binary on each node
RPM (RHEL)
Use the following commands to download the latest stable MinIO AIStor RPM and update the existing installation. Use the command appropriate for your host system CPU architecture.

The package is now named aistor rather than minio, and it obsoletes and replaces the older minio package. Use dnf install rather than dnf update, which matches on the installed package name and does not process the rename. The download URL is unchanged.

AMD64
```
curl --retry 10 --progress-bar -L  "https://dl.min.io/aistor/minio/release/linux-amd64/minio.rpm" -o minio.rpm
sudo dnf install minio.rpm
```
ARM64
```
curl --retry 10 --progress-bar -L  "https://dl.min.io/aistor/minio/release/linux-arm64/minio.rpm" -o minio.rpm
sudo dnf install minio.rpm
```
DEB (Debian/Ubuntu)
Use the following commands to download the latest stable MinIO AIStor DEB and upgrade the existing installation. Use the command appropriate for your host system CPU architecture.

AMD64
```
curl --retry 10 --progress-bar -L  "https://dl.min.io/aistor/minio/release/linux-amd64/minio.deb" -o minio.deb
sudo dpkg -i minio.deb
```
ARM64
```
curl --retry 10 --progress-bar -L  "https://dl.min.io/aistor/minio/release/linux-arm64/minio.deb" -o minio.deb
sudo dpkg -i minio.deb
```
Run minio --version on each node to validate that you successfully upgraded all binaries to the same version. Do not proceed unless all nodes use the same MinIO AIStor binary version.
Restart the cluster

Run the mc admin service restart command to restart the server processes in the cluster.

To restart every server at the same time, run:
```
mc admin service restart ALIAS
```
To keep the cluster serving requests throughout, add --rolling with a graceful wait period:
```
mc admin service restart ALIAS --rolling 2m
```
Replace ALIAS with the alias of the MinIO AIStor cluster to restart.

Without --rolling, every server restarts at the same time. The restart typically completes in under 3 seconds, and S3 clients reconnect on their own, so applications generally do not notice it.

With --rolling, the servers restart in sequence and the cluster keeps serving throughout, provided a load balancer routes new requests away from each server while it restarts. Clients already connected to a restarting server still reconnect, because a load balancer cannot move an established connection. See Choose a restart mode.
Validate the upgrade

Use the mc admin info command to check that all MinIO AIStor servers are online, operational, and reflect the installed MinIO AIStor version.
Upgrade AIStor Client

Upgrade your mc binary to match or closely follow the server release. You can use the mc update command to update the binary to the latest stable release:
```
mc update
```
Bump the API version

Starting with RELEASE.2026-04-11T03-20-12Z, the cluster leader automatically advances the cluster to the latest API version after a rolling upgrade that changes the API version. By default, the bump happens immediately once all nodes are online and support the latest version. If some nodes are temporarily absent, the cluster tolerates their absence for up to one hour before committing the bump.

Automatic bumping is enabled by default. To disable it and manage the API version manually, set MINIO_API_AUTO_BUMP=off on all nodes before upgrading.

Starting with RELEASE.2026-07-24T16-43-31Z, you can delay the bump instead of disabling it. Set MINIO_API_BUMP_BAKE_TIME on all nodes to a duration, for example 1h, to configure a bake time. The cluster then holds the previous API version for that long after it is fully upgraded. The bump commits once all nodes have stayed online on the newer release for that duration. The bake time applies only while every node is online. If a node drops out, the cluster commits the bump once the remaining quorum has held the newer release for one hour, however long a bake time you configured, so a longer rollback window depends on keeping every node online for it. During the bake time, the cluster keeps writing data in the previous version’s format, so downgrading the server binary remains safe. The default is 0, which commits the bump immediately. A bake time applies only while automatic bumping is enabled. Features that require the new API version stay inactive until the bump commits, so a longer bake time also delays their availability.

When automatic bumping is disabled, or when upgrading to a release earlier than RELEASE.2026-04-11T03-20-12Z, run the following command once all nodes are running the new version:
```
mc admin update ALIAS --bump-api
   
```
Replace ALIAS with the alias of the MinIO AIStor deployment.

This command is a one-time operation per upgrade and does not restart the cluster. It ensures all nodes in the cluster agree on the same API version after the binary update.

An API version bump is irreversible

Bumping the API version is a one-way operation. Once the version is bumped, whether automatically or with mc admin update ALIAS --bump-api, you cannot roll it back, and downgrading the server binary is only possible if the API version has never been bumped. Running an older binary after a bump fails to start with an unsupported API version error.

If you need to retain the ability to downgrade, set MINIO_API_AUTO_BUMP=off before upgrading so the version is not bumped automatically. To keep a bounded rollback window instead of disabling the bump, set MINIO_API_BUMP_BAKE_TIME to a duration. For recovery steps when a node fails to start due to an API version mismatch, see API version startup errors.

Upgrade MinIO AIStor through binary replacement

You can download and manually replace the minio server binary on each of the host nodes in the cluster. You must then restart the cluster, such as by using mc admin service restart. This method targets clusters that do not rely on the DEB or RPM packages for installation.

Download the MinIO AIStor binary

Download the latest stable MinIO AIStor binary for Linux and copies it to /usr/local/bin. The command overwrites the existing minio binary at that path. Use the command appropriate for your host system CPU architecture.

AMD64
```
curl --retry 10 --progress-bar -L  https://dl.min.io/aistor/minio/release/linux-amd64/minio
chmod +x ./minio
```
ARM64
```
curl --retry 10 --progress-bar -L  https://dl.min.io/aistor/minio/release/linux-arm64/minio
chmod +x ./minio
```
Replace the older binary

Move and overwrite the existing binary using root permissions if necessary.
```
sudo mv -f ./minio /usr/local/bin/minio
```
Repeat for all nodes in the cluster.
Restart the cluster

Use the mc admin service restart command to restart the cluster, either all at once or with --rolling as shown in the DEB and RPM procedure above.

Let mc admin service restart drive the restart rather than restarting nodes by hand. With --rolling, the command sequences the servers, gives each one a graceful wait period, and waits for each batch to report healthy before starting the next. Restarting nodes by hand does none of that, and clients connected to a node you restart receive connection errors unless a load balancer routes traffic away from it first. See Choose a restart mode.

Monitor the status of the cluster using journalctl -uf minio. Once all nodes reach healthy status, you can further validate the upgrade using mc admin info.
Upgrade AIStor Client

Upgrade your mc binary to match or closely follow the server release. You can use the mc update command to update the binary to the latest stable release:
```
mc update
```
Bump the API version

Starting with RELEASE.2026-04-11T03-20-12Z, the cluster leader automatically advances the cluster to the latest API version after a rolling upgrade that changes the API version. By default, the bump happens immediately once all nodes are online and support the latest version. If some nodes are temporarily absent, the cluster tolerates their absence for up to one hour before committing the bump.

Automatic bumping is enabled by default. To disable it and manage the API version manually, set MINIO_API_AUTO_BUMP=off on all nodes before upgrading.

Starting with RELEASE.2026-07-24T16-43-31Z, you can delay the bump instead of disabling it. Set MINIO_API_BUMP_BAKE_TIME on all nodes to a duration, for example 1h, to configure a bake time. The cluster then holds the previous API version for that long after it is fully upgraded. The bump commits once all nodes have stayed online on the newer release for that duration. The bake time applies only while every node is online. If a node drops out, the cluster commits the bump once the remaining quorum has held the newer release for one hour, however long a bake time you configured, so a longer rollback window depends on keeping every node online for it. During the bake time, the cluster keeps writing data in the previous version’s format, so downgrading the server binary remains safe. The default is 0, which commits the bump immediately. A bake time applies only while automatic bumping is enabled. Features that require the new API version stay inactive until the bump commits, so a longer bake time also delays their availability.

When automatic bumping is disabled, or when upgrading to a release earlier than RELEASE.2026-04-11T03-20-12Z, run the following command once all nodes are running the new version:
```
mc admin update ALIAS --bump-api
   
```
Replace ALIAS with the alias of the MinIO AIStor deployment.

This command is a one-time operation per upgrade and does not restart the cluster. It ensures all nodes in the cluster agree on the same API version after the binary update.

An API version bump is irreversible

Bumping the API version is a one-way operation. Once the version is bumped, whether automatically or with mc admin update ALIAS --bump-api, you cannot roll it back, and downgrading the server binary is only possible if the API version has never been bumped. Running an older binary after a bump fails to start with an unsupported API version error.

If you need to retain the ability to downgrade, set MINIO_API_AUTO_BUMP=off before upgrading so the version is not bumped automatically. To keep a bounded rollback window instead of disabling the bump, set MINIO_API_BUMP_BAKE_TIME to a duration. For recovery steps when a node fails to start due to an API version mismatch, see API version startup errors.

Upgrade MinIO AIStor using CLI commands

The mc admin update command updates the MinIO AIStor binary on all hosts in the cluster and then restarts them. The command requires the following:

All host machines must have access to the internet such that they can resolve calls to the dl.min.io subdomain.
The system user and group minio-user have write access to the MinIO AIStor minio binary, typically located at /usr/local/bin.

Use chown 775 minio-user:minio-user /usr/local/bin to set the appropriate permissions on all hosts prior to attempting to run the command.

For example, the following command updates a cluster with the alias PRODUCTION:

mc admin update PRODUCTION

The command provides a prompt to confirm the upgrade procedure. Follow the prompt to confirm and start the upgrade. Once completed, the cluster automatically restarts, with all hosts restarting at the same time.

To restart the hosts in sequence instead and keep the cluster serving requests, add --rolling with a graceful wait period:

mc admin update PRODUCTION --rolling 2m

A rolling update requires a load balancer in front of the cluster. See Choose a restart mode.

Use the mc admin info command to validate the MinIO AIStor version used by the cluster post upgrade.

Bump the API version

Starting with RELEASE.2026-04-11T03-20-12Z, the cluster leader automatically advances the cluster to the latest API version after a rolling upgrade that changes the API version. By default, the bump happens immediately once all nodes are online and support the latest version. If some nodes are temporarily absent, the cluster tolerates their absence for up to one hour before committing the bump.

Automatic bumping is enabled by default. To disable it and manage the API version manually, set MINIO_API_AUTO_BUMP=off on all nodes before upgrading.

Starting with RELEASE.2026-07-24T16-43-31Z, you can delay the bump instead of disabling it. Set MINIO_API_BUMP_BAKE_TIME on all nodes to a duration, for example 1h, to configure a bake time. The cluster then holds the previous API version for that long after it is fully upgraded. The bump commits once all nodes have stayed online on the newer release for that duration. The bake time applies only while every node is online. If a node drops out, the cluster commits the bump once the remaining quorum has held the newer release for one hour, however long a bake time you configured, so a longer rollback window depends on keeping every node online for it. During the bake time, the cluster keeps writing data in the previous version’s format, so downgrading the server binary remains safe. The default is 0, which commits the bump immediately. A bake time applies only while automatic bumping is enabled. Features that require the new API version stay inactive until the bump commits, so a longer bake time also delays their availability.

When automatic bumping is disabled, or when upgrading to a release earlier than RELEASE.2026-04-11T03-20-12Z, run the following command once all nodes are running the new version:

mc admin update ALIAS --bump-api

Replace ALIAS with the alias of the MinIO AIStor deployment.

This command is a one-time operation per upgrade and does not restart the cluster. It ensures all nodes in the cluster agree on the same API version after the binary update.

An API version bump is irreversible

Bumping the API version is a one-way operation. Once the version is bumped, whether automatically or with mc admin update ALIAS --bump-api, you cannot roll it back, and downgrading the server binary is only possible if the API version has never been bumped. Running an older binary after a bump fails to start with an unsupported API version error.

If you need to retain the ability to downgrade, set MINIO_API_AUTO_BUMP=off before upgrading so the version is not bumped automatically. To keep a bounded rollback window instead of disabling the bump, set MINIO_API_BUMP_BAKE_TIME to a duration. For recovery steps when a node fails to start due to an API version mismatch, see API version startup errors.