MinIO is software-defined high performance object storage released under GNU Affero General Public License v3.0.

MinIO is API compatible with Amazon’s S3 cloud storage service. Use MinIO to build high performance infrastructure for machine learning, analytics and application data workloads.

What Is Object Storage?

An object is binary data, sometimes referred to as a Binary Large OBject (BLOB). Blobs can be images, audio files, spreadsheets, or even binary executable code. Object Storage platforms like MinIO provide dedicated tools and capabilities for storing, retrieving, and searching for blobs.

MinIO Object Storage uses buckets to organize objects. A bucket is similar to a folder or directory in a filesystem, where each bucket can hold an arbitrary number of objects. MinIO buckets provide the same functionality as AWS S3 buckets.

For example, consider an application that hosts a web blog. The application needs to store a variety of blobs, including rich multimedia like videos and images. The structure of objects on the MinIO server might look similar to the following:

/ #root

MinIO supports multiple levels of nested directories and objects to support even the most dynamic object storage workloads.

Deployment Architecture

Erasure Set

A set of disks that supports MinIO Erasure Coding. Erasure Coding provides high availability, reliability, and redundancy of data stored on a MinIO deployment.

MinIO divides objects into chunks and evenly distributes them among each drive in the Erasure Set. MinIO can continue seamlessly serving read and write requests despite the loss of any single drive. At the highest redundancy levels, MinIO can serve read requests with minimal performance impact despite the loss of up to half (N/2) of the total drives in the deployment.

Server Pool

A set of MinIO minio server nodes which pool their drives and resources for supporting object storage/retrieval requests. Server pools support horizontal expansion for MinIO deployments.

The HOSTNAME argument passed to the minio server command represents a Server Pool:

minio server https://minio{1...4}{1...4}

             |                    Server Pool                |

The above example describes a single Server Pool with 4 minio server nodes and 4 drives each for a total of 16 drives. MinIO requires starting each minio server in the set with the same startup command to enable awareness of all set peers.

See minio server for complete syntax and usage.

MinIO calculates the size and number of Erasure Sets in the Server Pool based on the total number of drives in the set and the number of minio servers in the set. See Erasure Sets for more information.


The whole MinIO deployment consisting of one or more Server Pools. Each HOSTNAME argument passed to the minio server command represents one Server Pool:

minio server https://minio{1...4}{1...4} \

             |                    Server Pool                |

The above example describes two Server Pools, each consisting of 4 minio server nodes with 4 drives each for a total of 32 drives. MinIO always stores each unique object and all versions of that object on the same Server Pool.

Server Pool expansion is a function of Horizontal Scaling, where each new set expands the cluster storage and compute resources. Server Pool expansion is not intended to support migrating existing sets to newer hardware.

MinIO Standalone clusters consist of a single Server Pool with a single minio server node. Standalone clusters are best suited for initial development and evaluation. MinIO strongly recommends production clusters consist of a minimum of 4 minio server nodes in a Server Pool.

Deploying MinIO


Deploy MinIO in Distributed Mode Expand a Distributed MinIO Deployment


MinIO Kubernetes Operator