Deployment and Upgrades on SILO

Deploy a Silo Tenant

Mon, 01 Jan 0001 00:00:00 +0000

This procedure deploys a Silo server image as a Tenant managed by MinIO Operator v7.1.1. The upstream Operator repository was archived and made read-only on 2026-03-20, so this is a frozen compatibility baseline rather than an actively maintained Operator path. MinIO Operator, Tenant, the minio.min.io API group, and the CRD field names are upstream Kubernetes contracts and therefore retain their original names.

The verified baseline below creates a four-server Tenant. A single-node topology is useful for local testing, but its production failure model and storage layout are outside the scope of this procedure.

Deploy Operator With Helm

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Helm is a tool for automating the deployment of applications to Kubernetes clusters. A Helm chart is a set of YAML files, templates, and other files that define the deployment details. The following procedure uses a Helm Chart to install the MinIO Kubernetes Operator to a Kubernetes cluster.

Warning

The upstream MinIO Operator repository was archived on March 20, 2026. This procedure is pinned to its final release, v7.1.1, as a frozen compatibility baseline. It does not imply ongoing upstream maintenance or support; validate it against your Kubernetes platform before production use.

Deploy Silo on RHEL-Compatible Linux

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying Silo on RHEL and binary-compatible Linux distributions.

Silo publishes RPM packages and standalone Linux archives for x86-64 and ARM64. The project does not publish a separate RHEL support-lifecycle matrix, so the inherited point-in-time release list has been removed. Use a distribution release still supported by its vendor, keep the kernel and system libraries current, and validate the exact storage and workload configuration before production use.

Deploy a Silo Tenant with Helm Charts

Mon, 01 Jan 0001 00:00:00 +0000

Overview

This procedure requires the Kubernetes cluster have a valid Operator deployment. You cannot use the MinIO Operator Tenant chart to deploy a Tenant independent of the Operator.

Deploy Silo on Ubuntu Linux

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying Silo on Ubuntu Linux.

Silo publishes DEB packages and standalone Linux archives for x86-64 and ARM64. The project does not publish a separate Ubuntu support-lifecycle matrix, so the inherited point-in-time release list has been removed. Use an Ubuntu release still supported by its distributor, keep the kernel and system libraries current, and validate the exact storage and workload configuration before production use.

Upgrade a Silo Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Warning

Legacy upstream upgrades

If the deployment still runs an upstream MinIO release older than RELEASE.2024-03-30T09-41-56Z with AD/LDAP enabled, read the upstream notes for RELEASE.2024-04-18T19-09-19Z and complete its migration steps before moving to Silo. These names and links identify upstream release contracts and are intentionally retained.

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.

Upgrade MinIO Operator

Mon, 01 Jan 0001 00:00:00 +0000

You can upgrade the MinIO Operator at any time without impacting your managed MinIO Tenants.

As part of the upgrade process, the Operator may update and restart Tenants to support changes to the MinIO Custom Resource Definition (CRD). These changes require no action on the part of any operator or administrator, and do not impact Tenant operations.

This page describes how to upgrade from Operator 5.0.15 to 7.1.1. See Upgrade MinIO Operator 4.5.8 and Later to 5.0.15 for instructions on upgrading to Operator 5.0.15 before starting this procedure.

Deploy Silo as a Container

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying Silo as a container on an operating system that supports containerized processes.

This documentation assumes installation of Docker, Podman, or a similar runtime which supports the standard container image format. Published pgsty/silo release images use Red Hat Universal Base Image 9 Micro.

Functionality and performance of the Silo container may be constrained by the base OS.

The procedure includes guidance for deploying Single-Node Multi-Drive (SNMD) and Single-Node Single-Drive (SNSD) topologies in support of early development and evaluation environments.

Expand a Distributed Silo Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Silo supports expanding an existing distributed deployment by adding a new Server Pool. Each pool expands the total available storage capacity of the cluster.

Expansion does not provide Business Continuity/Disaster Recovery (BC/DR)-grade protections. While each pool is an independent set of servers with distinct erasure sets for availability, the complete loss of one pool results in MinIO stopping I/O for all pools in the deployment. Similarly, an erasure set which loses quorum in one pool represents data loss of objects stored in that set, regardless of the number of other erasure sets or pools.

Modify a Silo Tenant

Mon, 01 Jan 0001 00:00:00 +0000

You can modify tenants after deployment to change mutable configuration settings. See MinIO Custom Resource Definition for a complete description of available settings in the MinIO Custom Resource Definition.

The method for modifying the Tenant depends on how you deployed the tenant:

Kustomize

For Kustomize-deployed Tenants, you can modify the base Kustomization resources and apply them using kubectl apply -k against the directory containing the kustomization.yaml object.

kubectl apply -k ~/kustomization/TENANT-NAME/

Modify the path to the Kustomization directory to match your local configuration.

Decommission Server Pools

Mon, 01 Jan 0001 00:00:00 +0000

MinIO supports decommissioning and removing server pools from a deployment with two or more pools. To decommission, there must be at least one remaining pool with sufficient available space to receive the objects from the decommissioned pools.

Starting with RELEASE.2023-01-18T04-36-38Z, MinIO supports queueing multiple pools in a single decommission command. Each listed pool immediately enters a read-only status, but draining occurs one pool at a time.

Decommissioning is designed for removing an older server pool whose hardware is no longer sufficient or performant compared to the pools in the deployment. MinIO automatically migrates data from the decommissioned pools to the remaining pools in the deployment based on the ratio of free space available in each pool.

Deploy Silo on macOS

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying Silo onto Apple macOS hosts for development and evaluation.

Silo publishes separate macOS archives for Intel and Apple Silicon. The current project CI runs on Linux and does not establish a macOS support-lifecycle guarantee, so the inherited, dated list of “supported” macOS releases has been removed. Validate the exact operating-system version and workload before production use.

Upgrade a Silo Tenant

Mon, 01 Jan 0001 00:00:00 +0000

The following procedures upgrade a single Silo Tenant using either Kustomize or Helm. Test the exact server image, Operator/chart version, and rollback procedure in a non-production Tenant first.

Caution

Keep the server image on pgsty/silo and use only a tag or digest published on the Silo download page. The upstream Tenant defaults use a MinIO image. Also keep MINIO_UPDATE=off; the inherited in-place updater still targets the upstream MinIO feed and is not a Silo upgrade path.

Deploy Silo on Windows

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying Silo onto Microsoft Windows hosts for development and evaluation.

Silo publishes Windows archives for x86-64 and ARM64. The current project CI runs on Linux and does not provide Windows runtime coverage, so the old upstream list of “officially supported” Windows releases has been removed. Validate the exact Windows edition, filesystem, service wrapper, and workload before relying on it in production.

Expand a Silo Tenant

Mon, 01 Jan 0001 00:00:00 +0000

This procedure documents expanding the available storage capacity of an existing MinIO tenant by deploying an additional pool of MinIO pods in the Kubernetes infrastructure.

Warning

Important

The MinIO Operator Console is deprecated and removed in Operator 6.0.0.

See Modify a MinIO Tenant for instructions on migrating Tenants installed via the Operator Console to Kustomization.

Prerequisites

MinIO Kubernetes Operator

This procedure requires a valid installation of the MinIO Kubernetes Operator and assumes the local host has a matching Operator installation. It uses v7.1.1, the final upstream release before the repository was archived, as a frozen compatibility baseline.

Migrate from Gateway or Filesystem Mode

Mon, 01 Jan 0001 00:00:00 +0000

Background

The MinIO Gateway and the related filesystem mode entered a feature freeze in July 2020. In February 2022, MinIO announced the deprecation of the MinIO Gateway. Along with the deprecation announcement, MinIO also announced that the feature would be removed in six months time.

As of RELEASE.2022-10-29T06-21-33Z, the MinIO Gateway and the related filesystem mode code have been removed. Deployments still using the standalone or filesystem MinIO modes that upgrade to MinIO Server RELEASE.2022-10-29T06-21-33Z or later receive an error when attempting to start MinIO.

Delete a Silo Tenant

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites

MinIO Kubernetes Operator

The procedures on this page require a valid installation of the MinIO Kubernetes Operator and assume the local host has a matching Operator installation. They use v7.1.1, the final upstream release before the repository was archived, as a frozen compatibility baseline.

See Deploy MinIO on Kubernetes for complete documentation on deploying the MinIO Operator.

Tenant Persistent Volume Claims

The delete behavior of each Persistent Volume Claims (PVC) generated by the Tenant depends on the Reclaim Policy of its bound Persistent Volume (PV):

Upgrade Legacy MinIO Operators

Mon, 01 Jan 0001 00:00:00 +0000

MinIO supports the following upgrade paths for older versions of the MinIO Operator:

Current Version	Supported Upgrade Target
5.0.15 or later	7.1.1
5.0.0 to 5.0.14	5.0.15
4.2.3 to 4.5.7	4.5.8
4.0.0 through 4.2.2	4.2.3
3.X.X	4.2.2

To upgrade from Operator to 7.1.1 from version 4.5.7 or earlier, you must first upgrade to version 4.5.8, then upgrade to 5.0.15. Depending on your current version, you may need to do one or more intermediate upgrades to reach v4.5.8.