Module: MINIO

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.

MINIO is an optional module. When using it as a pgBackRest S3 repository, deploy it before the PGSQL module. TLS certificates and the host baseline come from the NODE / CA capabilities.

Quick Start

The following inventory explicitly defines a single-node Silo cluster. Both minio_cluster and minio_seq are required identity parameters; production inventories should explicitly set minio_type: silo.

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

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

The inventory group name may differ from minio_cluster. Roles calculate actual membership from each host’s minio_cluster identity. Do not define minio_cluster in all.vars, or every host will be treated as an object-storage member.

After deployment, use these entry points:

• S3 API: https://sss.pigsty:9000 (configure DNS or /etc/hosts explicitly for the domain)
• Administration UI: https://<node-ip>:9001
• Command line: mcli ls sss/ (a preconfigured alias is written on the admin node and cluster members)

The default administrator credentials are minioadmin / S3User.MinIO. They are for demos only and must be changed before production deployment.

Deployment Modes

Silo uses the following Pigsty inventory deployment modes:

minio_data is always a directory path. Distributed and multi-drive deployments require these paths to reside on non-root, persistent filesystems. For example, /data/minio may be a subdirectory of a separately mounted /data filesystem, but not merely a directory on the root filesystem.

The multi-pool expansion semantics of minio_volumes come from the MinIO-compatible interface retained by Silo. Validate operations and rollback against the actual Silo version before production scaling.

Core Capabilities

• Compatible interface: Silo retains minio_* parameters, the S3 port, TLS, and the mcli provisioning flow
• HA topologies: Supports single-node, multi-node single-drive, and multi-node multi-drive deployments, with multiple independent clusters in one inventory
• Backup repository: Can serve as a remote pgBackRest S3 repository
• Security baseline: Enables HTTPS by default and uses the Pigsty CA to issue a certificate for every instance
• Observability: Scrapes Silo metrics through /minio/metrics/v3 and provides Grafana dashboards and alerts
• Operational compatibility: Module name, target directories, monitoring labels, and client aliases retain the MINIO namespace