MINIO on Pigsty v5.0

MINIO Cluster Model

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

MINIO is Pigsty’s compatibility module name for object storage. The current v4.5.0 source deploys Silo through minio_type: silo and organizes a group of object-storage instances into a cluster.

Each cluster is an autonomous S3-compatible object-storage unit consisting of at least one instance and exposing service through the S3 API port.

There are three core entities in Pigsty’s MINIO module:

Cluster: An autonomous object-storage service unit serving as the top-level namespace for other entities.
Instance: A single Silo server process running on a node and managing local disks.
Node: A hardware resource abstraction running Linux + Systemd environment, implicitly declared.

Silo also retains the Storage Pool concept for expansion.

Module: MINIO

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

MINIO is Pigsty’s compatibility module name for S3-compatible object storage. The current role deploys Silo, and minio_type accepts only silo.

Silo preserves the MinIO S3/Admin APIs, MINIO_* environment variables, disk format, and mcli client interface, and can serve as a PostgreSQL pgBackRest backup repository. The module name, parameter prefix, and monitoring job retain the MINIO / minio_* namespace for compatibility with existing inventories and operational entry points.

Important

minio and rustfs are no longer valid minio_type values and fail during identity validation. Before upgrading a MinIO cluster managed by an older release, complete a backup, validate MinIO-to-Silo compatibility, and rehearse rollback. Do not treat package replacement as an already-accepted data migration. External MinIO, RustFS, or other S3 services can still serve as pgBackRest repositories, but the current MINIO role does not manage them.

Usage

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

After you configure and deploy Silo with the playbook, use this page to access it through the compatible S3 and mcli interfaces.

Deploy Cluster

First, define a single-node, single-disk object-storage cluster in the config inventory and explicitly pin its engine:

minio: { hosts: { 10.10.10.10: { minio_seq: 1 } }, vars: { minio_cluster: minio, minio_type: silo } }

Then, run the minio.yml playbook provided by Pigsty against the defined group (here minio):

Configuration

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

Before deploying the MINIO module, define a Silo object-storage cluster in the config inventory. The current role requires minio_type: silo and supports these inventory deployment modes:

Single-Node Single-Disk: SNSD: Single-node single-disk mode, can use any directory as a data disk, for development, testing, and demo only.
Single-Node Multi-Disk: SNMD: Compromise mode, using multiple disks (>=2) on a single server, only when resources are extremely limited.
Multi-Node Single-Disk: MNSD: Multiple servers with one independent data drive each, providing compact node-level high availability.
Multi-Node Multi-Disk: MNMD: Multi-node multi-disk mode, standard production deployment with the best reliability, but requires multiple servers.

SNSD is suitable for development and testing, three-node MNSD for resource-constrained compact HA, and MNMD for production environments with higher capacity, throughput, and drive-redundancy requirements. SNMD handles drive failures within one server but cannot tolerate losing the server.

Playbook

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

The MINIO module provides two built-in playbooks:

minio.yml: Install and configure Silo
minio-rm.yml: Remove Silo, its configuration, and optionally its data

`minio.yml`

minio.yml runs with hosts: all, but its pre-tasks skip hosts where minio_cluster is undefined. The role then validates that:

minio_cluster is defined and non-empty
minio_seq is defined and is a non-negative integer
minio_type must equal silo

Thus, minio_cluster is the module-membership gate, while invalid minio_seq or minio_type values fail identity validation explicitly. Do not define minio_cluster in all.vars.

Administration

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

Create Cluster

To create a cluster, define it in the config inventory and run the minio.yml playbook.

minio: { hosts: { 10.10.10.10: { minio_seq: 1 } }, vars: { minio_cluster: minio, minio_type: silo } }

The configuration above defines an SNSD Single-Node Single-Disk Silo cluster. Create it with:

./minio.yml -l minio  # Install Silo on the minio group

Remove Cluster

To destroy a cluster, run the dedicated minio-rm.yml playbook:

Monitoring and Alerting

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

Administration UI

Silo provides an administration UI through minio_admin_port, which defaults to 9001. Access it directly at https://<node-ip>:9001.

Some configuration templates also expose the administration entry point at m.pigsty. Login credentials come from minio_access_key and minio_secret_key.

HTTPS and Certificate Trust

Object storage uses HTTPS certificates issued by the Pigsty CA by default. Browsers and container clients must trust that CA. Do not substitute disabled certificate verification for a correct trust configuration in production.

Metrics

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

The MINIO module collects Silo metrics through /minio/metrics/v3. The metric set varies with server versions and enabled features, so this page documents the stable interfaces used by current dashboards and alerts rather than treating a complete scrape from one version as a permanent contract.

Stable Identity Labels

All object-storage targets use these Pigsty labels:

Label	Meaning	Example
`job`	Fixed module namespace	`minio`
`flavor`	Actual backend	`silo`
`cls`	`minio_cluster` identity	`minio`
`ins`	`<minio_cluster>-<minio_seq>` instance identity	`minio-1`
`ip`	Inventory management address	`10.10.10.10`
`instance`	Metric target address	`10.10.10.10:9000`

Queries and recording rules should prefer the stable cls, ins, and ip identity labels.

FAQ

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

Which backend does the MINIO module deploy by default?

In v4.5.0, the current source deploys Silo—and only Silo. The only valid value for minio_type is silo. MINIO remains the compatibility module name; it does not mean the MinIO server is running.

Explicitly set minio_type: silo for new clusters.
Both minio_type: minio and minio_type: rustfs fail during identity validation.
External MinIO, RustFS, or other S3 services can still serve as pgBackRest repositories, but the current MINIO role does not manage them.
Before upgrading a MinIO cluster managed by an older release, validate the MinIO-to-Silo data compatibility, backup, and rollback procedure.

Why does the Pigsty repository still carry MinIO or RustFS packages?

Upstream MinIO switched to source-only distribution on 2025-10-15, marked the repository as maintenance mode on 2025-12-03, and archived it on 2026-04-25. Here, “source-only distribution” means that new prebuilt community binaries stopped being published—not merely RPM and DEB packages.