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

Upgrading to SILO 20261109:

• Stop batch submissions and drain or cancel every unfinished job, including paused jobs. New manifests and progress reports use formats unsupported by 20261026; unfinished legacy jobs need resubmission after every node upgrades, while completed jobs remain completed. Do not roll back with new jobs pending. Reconcile completed work using the batch upgrade and rollback checklist.
• A single pool whose erasure sets do not all share the same hosts (typically 18 or more hosts with automatic layout) requires draining and stopping every old process before starting new ones. Rolling upgrades are unsafe because old and new nodes use different lock domains for deletes and copies.
• During a rolling upgrade, new nodes return 503 for POST ?restore while any peer is old or unreachable. Pause new restores until all nodes upgrade. Full multi-pool lifecycle and S3 bulk-delete protection also require all serving nodes to run the fixed version.
• Preserve peer discovery during bootstrap; Kubernetes headless services must retain publishNotReadyAddresses: true. ready does not wait for storage and IAM, and cluster can succeed before a restarted node mounts its remote drives. Before resuming applications, write a small object through each node, then read every acknowledged object through every node and verify bytes and versions, using an overall deadline and per-request timeouts. See the startup window and data-path checks.
• With helm upgrade --reuse-values, explicitly set image.tag=RELEASE.2026-11-09T00-00-00Z; otherwise the saved old image tag remains in use.

Upgrading to 20261026: Upgrade all writer nodes and verify built-in policy Reset, LDAP long-DN login, remote-tier historical reads and multipart replication. Storage timeout and cancellation behavior is retained; a timeout does not prove that underlying I/O stopped or that the write did not commit. Read-quorum and healing rules are unchanged; this release does not add distributed fencing or repair pre-existing inconsistent objects. See the 20261026 upgrade checks.

1. Back up cluster settings. Export bucket metadata and IAM configuration with mc admin cluster bucket export and mc admin cluster iam export. For versions with durable IAM revocation, also back up complete backend storage and encryption material: live exports omit deletion history. Follow IAM upgrade and recovery.
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. Upgrade through packages or artifacts. SILO permanently disables in-place updates; the compatibility variable MINIO_UPDATE cannot re-enable them.
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/silo.rpm

   DEB (Debian/Ubuntu)

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

   Binary

   Verify the downloaded archive against its release checksum before extracting it. The archive checksum does not apply to the extracted executable. Then install it:

   sudo install -m 0755 ./silo /usr/local/bin/silo

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

3. Run silo --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

   Native packages use silo.service; otherwise coordinate systemctl restart silo across all nodes through your automation. Custom installations should use their actual unit name. Do not improvise a rolling mixed-version deployment unless the target release explicitly supports it.

5. Check cluster status with mc admin info, and run a bounded signed S3 write and readback check through each restarted node before you resume application traffic; see Startup Readiness Window. Then verify 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 silo --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.