Upgrade a Silo Deployment

Upgrade Silo by installing a verified server artifact on every node and then restarting the deployment as one coordinated operation. A full-cluster restart creates a brief availability interruption. Applications should retry failed or interrupted requests; operation atomicity does not remove the need for retry handling.

This page covers systemctl-managed and manually managed bare-metal deployments. When Ansible, Terraform, containers, or another orchestrator owns the service, apply the same release, verification, and restart boundaries through that tool instead of editing its managed files by hand.

Before You Upgrade

1. Back up cluster settings. Export bucket metadata and IAM configuration with mc admin cluster bucket export and mc admin cluster iam export.
2. Choose a published Silo release. Use Download & Install, Silo release notes, and GitHub Releases. A local tag, branch commit, draft release, or uploaded draft asset is not a published release.
3. Verify the artifact. Check its SHA-256 digest against the checksum published with that exact release. Pin one release across all nodes.
4. Read every intervening release note. Pay particular attention to format, identity, configuration, and downgrade warnings.
5. Test the exact upgrade in a lower environment. Exercise representative reads, writes, policies, lifecycle rules, replication, notifications, and recovery procedures before production.
6. Disable the inherited in-place updater. Set MINIO_UPDATE=off in the server environment and restart the service so the setting takes effect.
7. Check bucket-scoped policies for object-only resources. In the exported IAM configuration, look for statements that grant one of twelve bucket-level write actions — or s3:* — on a resource pattern containing /, with no bare bucket ARN for the same bucket. Those statements no longer authorize those actions. Add the bare ARN alongside the object pattern; see Bucket and Object Resources. Built-in policies and any statement using arn:aws:s3:::* are unaffected.

systemctl-Managed Deployments

1. Download the same published server release for every node from Download & Install, then verify its checksum.

2. Install the package or replace the binary on every node without restarting only part of the cluster:

   RPM (RHEL family) DEB (Debian/Ubuntu) Binary

   RPM (RHEL family)

   sudo dnf install /path/to/minio.rpm

   DEB (Debian/Ubuntu)

   sudo dpkg -i /path/to/minio.deb

   Binary

   sha256sum ./minio
   sudo install -m 0755 ./minio /usr/local/bin/minio

   Replace /usr/local/bin/minio with the path returned by command -v minio when your installation uses a different location.

3. Run minio --version on every node. Do not proceed until every node reports the same intended release.

4. Restart all server processes as one coordinated operation. Where the admin API is available, use:

   mc admin service restart ALIAS

   Otherwise coordinate systemctl restart minio across all nodes through your automation. Do not improvise a rolling mixed-version deployment unless the target release explicitly supports it.

5. Validate the deployment with mc admin info, then test representative S3 reads and writes, console access, identity login, and any configured replication or notifications.

6. Upgrade the client separately from Download & Install. Standalone artifacts use mcli; source builds and the container retain mc.

Manually Managed Deployments

For a process managed by a user script or another supervisor, download and verify the same Silo binary on every node, replace the executable at the path used by that supervisor, confirm minio --version, and restart all nodes as one coordinated operation. The service account must be able to execute the new binary; the operator performing the replacement must be able to write its installation path.

After restart, run the same validation described above. Preserve the previous verified binary until validation completes so that any rollback decision can follow the target release’s documented downgrade constraints.