Deploy Silo as a Container

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/minio 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.

Important

These examples cover Single-Node Single-Drive and Single-Node Multi-Drive development or evaluation deployments. They do not define a production Multi-Node Multi-Drive topology or an upgrade contract for Docker Compose, Docker Swarm, or another container orchestrator. For a production distributed deployment, use a tested Kubernetes tenant workflow and validate persistence, networking, failure domains, and upgrades for your environment.

The examples use pgsty/minio:latest for readability. Pin a tested Silo release tag or image digest in production; latest is not a version contract.

The MINIO_UPDATE=off setting intentionally disables the server’s in-place updater. The current updater retains the upstream MinIO release feed and signing key, so container upgrades must replace the image with a verified Silo tag or digest instead of running mc admin update.

Considerations

Review Checklists

Ensure you have reviewed our published Hardware, Software, and Security checklists before attempting this procedure.

Erasure Coding Parity

Silo automatically determines the default erasure coding configuration for the cluster based on the total number of nodes and drives in the topology. You can configure the per-object parity setting when you set up the cluster or let Silo select the default (EC:4 for production-grade clusters).

Parity controls the relationship between object availability and storage on disk. The upstream MinIO Erasure Code Calculator can help compare parity levels; treat it as an upstream planning aid rather than a Silo support contract.

While you can change erasure parity settings at any time, objects written with a given parity do not automatically update to the new parity settings.

Container Storage

This procedure assumes you mount one or more dedicated storage devices to the container to act as persistent storage for Silo.

Data stored on ephemeral container paths is lost when the container restarts or is deleted. Use any such paths at your own risk.

Procedure

Start the Container

This procedure provides instructions for Podman and Docker in rootfull mode. For rootless deployments, defer to documentation by each runtime for configuration and container startup.

For all other container runtimes, follow the documentation for that runtime and specify the equivalent options, parameters, or configurations.

The following command creates a folder in your home directory, then starts the Silo container using Podman:

mkdir -p ~/silo/data

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /data --console-address ":9001"

The command binds ports 9000 and 9001 to the S3 API and Web Console respectively.

The local drive ~/silo/data is mounted to the /data folder on the container. You can modify the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD variables to change the root login as needed.

For multi-drive deployments, bind each local drive or folder it’s on sequentially-numbered path on the remote. You can then modify the minio server startup to specify those paths:

mkdir -p ~/minio/data-{1..4}

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /mnt/drive-{1...4} --console-address ":9001"

For Windows hosts, specify the local folder path using Windows filesystem semantics C:\minio\:/data.

The following command creates a folder in your home directory, then starts the Silo container using Docker:

mkdir -p ~/silo/data

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /data --console-address ":9001"

The command binds ports 9000 and 9001 to the S3 API and Web Console respectively.

The local drive ~/silo/data is mounted to the /data folder on the container. You can modify the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD variables to change the root login as needed.

For multi-drive deployments, bind each local drive or folder it’s on sequentially-numbered path on the remote. You can then modify the minio server startup to specify those paths:

mkdir -p ~/minio/data-{1..4}

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /mnt/drive-{1...4} --console-address ":9001"

For Windows hosts, specify the local folder path using Windows filesystem semantics C:\minio\:/data.

2. Connect to the Deployment

Open your browser to http://localhost:9001 to open the Silo Console login page.

You can use the embedded Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration.

Follow the Silo client installation instructions for mcli on your local host. Run mcli --version to verify the installation. Published standalone archives and Linux packages install mcli; source builds and the client container retain the mc executable name.

Once installed, create an alias for the Silo deployment:

mcli alias set silo http://localhost:9000 USERNAME PASSWORD

Change the hostname, username, and password to reflect your deployment.