MinIO

What is MinIO?

MinIO speaks the S3 API against local disks, so applications written for cloud object storage work unchanged while the data stays in your building. It is the standard answer when a tool requires an S3 bucket.

Best for

S3-compatible storage for apps that expect a cloud bucket

Why choose MinIO

MinIO exists because a surprising number of applications require an S3 bucket and will not run without one. It implements the S3 API against local disks, so software written for cloud object storage works unchanged while the data stays on hardware you control and the bill stays zero. It is a single binary with a straightforward deployment, supports erasure coding for redundancy, and offers versioning and lifecycle rules that match what the hosted services provide. For anyone assembling a self-hosted stack where a tool demands object storage, it is frequently the difference between running that tool and not running it at all. It also gives you a place to put backups that is separate from the machine being backed up, which is most of what makes backups useful.

Replaces

• AWS S3
• Google Cloud Storage
• Azure Blob Storage

Key features

• S3-compatible API with versioning and lifecycle rules
• Erasure coding across multiple drives
• Built-in web console
• Client-side encryption support

What to watch out for

The open-source product has undergone significant change in how it is distributed and what defaults apply, so guidance written for an earlier version may not match what you install — check the current release notes rather than the most popular blog post. The console and the management surface are not the same thing, and relying only on the console leaves you without automation. It is designed for large numbers of large objects, and workloads dominated by very many tiny files perform poorly compared with a purpose-built store. Scaling beyond a single node requires a deliberate distributed setup with its own failure modes, and the default credentials must be changed before it is ever reachable by anything else.

How to deploy

• Docker with drives mounted directly
• Generate access keys in the console
• Plan the disk layout before writing data

Getting started

Deploy it with a persistent volume and immediately replace the default access key and secret — an exposed MinIO with stock credentials is a common finding. Create a bucket per application and a user per bucket rather than sharing one credential everywhere. Decide whether you need erasure coding or simple mirrors before loading data, because reconfiguring storage later means migrating it. Enable versioning and lifecycle rules on the buckets where accidental deletion matters. Then point your backup software at it, and verify a restore from that backup, since storage you have never restored from is storage you do not know works.

Typical setup

One binary with a persistent volume, default credentials replaced before it is reachable by anything else, and a bucket plus a dedicated user per application rather than one shared credential. Versioning and lifecycle rules are enabled where deletion could be accidental. Redundancy is configured deliberately — erasure coding or a mirror — rather than assumed from a single node. It is the destination for other services' backups, which means a restore from it has been performed at least once, because storage nobody has restored from is untested storage.

Who should look elsewhere

Do not use it as a general-purpose network filesystem — it is object storage, and POSIX-style workloads will be both slow and awkward. Avoid it if your data is mostly enormous numbers of tiny files, where a filesystem-backed store or a store designed for small objects fits better. And if you are running only a handful of containers on one machine with no application demanding S3, a plain directory and a sync tool will do the same job with less to operate.

Project health

• GitHub stars: 61,345
• Last code push: 2026-04-24
• Open issues: 80
• Status: repository is archived

Figures pulled from the GitHub API and refreshed periodically.