Key takeaway
- MinIO object storage explained: erasure coding, documented limits, and what the archived community repository means for your 2026 deployment choice.
MinIO is an S3-compatible object storage server written in Go, used to keep unstructured data such as backups, logs, media and model artefacts on private cloud, Kubernetes and on-premises infrastructure. The architecture is still worth understanding, but the product status has changed: according to the MinIO GitHub repository, the community repository was archived by its owner on 25 April 2026 and is read-only, the source is licensed under the GNU AGPLv3, and the community edition is distributed as source code only with no pre-compiled binary releases.
For an enterprise buyer that means one decision comes before any design work: which edition and support route you will run. This guide explains how MinIO stores and protects objects, what its documented limits are, how it fits with Kubernetes and cloud-native storage, and how to choose a path in 2026.
What is MinIO object storage?
Object storage keeps data as objects (the data, its metadata and a key) inside buckets, and clients reach it over an HTTP API. MinIO implements the Amazon S3 API, so applications written for S3 can usually be pointed at a MinIO endpoint. It runs as a single server with one or more disks, or as a distributed cluster across several hosts. Disks can be locally attached drives or volumes provided by the platform, for example Kubernetes persistent volumes. The persistent storage guide covers the Kubernetes side.
The video above gives a short walkthrough of MinIO as private cloud object storage.
How does MinIO protect data with erasure coding?
According to the MinIO documentation, the server uses a Reed-Solomon erasure coding implementation. Each object is split into data and parity shards spread across the drives of an erasure set, so objects can be rebuilt after drive failures without keeping full copies.
| Topic | What the documentation says | Why it matters |
|---|---|---|
| Erasure set size | 2 to 16 drives by default. Newer AIStor releases (RELEASE.2026-02-02T23-40-11Z or later) allow up to 32 when configured. | Set size and count are fixed when a server pool is initialised, so plan them before first use. |
| Parity | From 0 up to half the set size. Production deployments should use at least EC:3. | Higher parity tolerates more drive loss and leaves less usable capacity. |
| Read quorum | Any K shards (K is the number of data shards) can reconstruct an object. | Reads continue while enough drives are online. |
| Write quorum | K drives must acknowledge a write, or K+1 when parity is exactly half the set. | Writes need slightly more than reads when parity is at its maximum. |
| Healing | When read quorum is met, any data or parity shard can rebuild damaged shards. | Failed drives can be replaced and repopulated. |
Source: MinIO erasure coding documentation, read 13 November 2026. That page sits in the current AIStor documentation, so confirm the figures against the docs for the edition you run.
What are the documented limits of MinIO?
The limits page in the archived community repository (minio-limits.md) lists the figures below. Amazon documents its own limits in the S3 FAQs.
| Limit | MinIO (archived community docs) | Amazon S3 (S3 FAQs) |
|---|---|---|
| Maximum object size | 50 TiB | 50 TB |
| Largest single PUT | 5 TiB | 5 GB |
| Multipart upload | Up to 10,000 parts, 5 MiB to 5 TiB each | Recommended for objects over 100 MB |
| Minimum servers (erasure coding) | 2 | Not applicable (managed service) |
| Versions per object | 10,000 (configurable, not recommended beyond that) | Not stated in the FAQs page read |
The same MinIO page lists S3 APIs that MinIO does not support, including BucketACL, BucketCORS, BucketWebsite, BucketAnalytics, BucketMetrics, BucketLogging and ObjectACL. Check your applications against that list before treating MinIO as a drop-in replacement.
Which MinIO route should an enterprise choose in 2026?
| Route | When it fits | Current status (13 November 2026) |
|---|---|---|
| Community source, self-built | Labs, development and test clusters where you can own builds and patching | Repository archived 25 April 2026 and read-only; source only; production use of source-compiled binaries is at your own risk, per the README |
| MinIO AIStor Free | Standalone, community-scale use | Described in the README as a full-featured standalone edition with a free licence; read the licence terms first |
| MinIO AIStor Enterprise | Distributed production with commercial support | Described in the README as the distributed edition with commercial support |
| Another S3-compatible store | You need an actively maintained open-source route | Assess against the S3 API surface you actually use |
The README also notes that commercial or proprietary use cases need AIStor licensing, and the source licence is AGPLv3. Ask legal and procurement to review both before you build a platform on either.
How does MinIO fit into Kubernetes and private cloud?
On Kubernetes, MinIO consumes disks as persistent volumes and serves S3 to the workloads around it. The AIStor documentation includes a guide titled "Deploy MinIO AIStor on Kubernetes" and a separate OpenShift guide. In a containerised estate, treat object storage like any stateful service: pin it to dedicated nodes and drives, set resource limits, and monitor drive health and healing. For wider context see multi-cloud and hybrid strategy and distributed systems observability.
What security and cost controls does object storage need?
- Credentials: use unique access and secret keys per application, held in a secrets manager or orchestrator secrets, never in images or code.
- Transport and access: serve over TLS and give each workload only the buckets it needs.
- Audit: log who read and wrote which bucket, and keep the logs outside the storage cluster.
- Cost: parity and replication trade usable capacity for resilience. Model raw versus usable capacity before purchase, and compare self-hosted operations effort with a managed service.
Confirm encryption and audit features in the documentation of the exact edition you deploy, because feature sets differ between editions.
How should you adopt object storage step by step?
- List the S3 APIs your applications call and compare them with the documented unsupported list.
- Choose the edition and support route, and record the licence decision.
- Design erasure sets and parity for your failure budget before the first deployment, as set size cannot change afterwards.
- Pilot on non-production data, test drive failure and healing, and measure with your own workloads.
- Add credentials management, TLS, logging and capacity alerts before production.
Where does object storage fit with AI agents?
Object stores often hold the documents, logs and datasets that AI agents read. The storage layer only keeps the bytes; deciding which agent may use which data, under which policy, is a separate layer. ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents, and AgentAnalyst lets teams ask questions of enterprise data in plain language. See also agentic workflows and, for database choices alongside object storage, NoSQL databases.
When is MinIO not the right choice?
Avoid it when you need a managed service with no operations effort, when your applications depend on S3 APIs that MinIO does not support, or when your policy forbids source-only software or AGPL-licensed components without a commercial licence. Small data volumes often do not justify running a distributed storage cluster at all.
To map one data access decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.
MinIO FAQs
Is MinIO still maintained?
The community GitHub repository was archived by its owner on 25 April 2026 and is read-only. MinIO's commercial AIStor editions are described in the same README.
What licence does MinIO use?
The README says the source is licensed under the GNU AGPLv3. It also says AIStor includes licensing for workloads that need commercial or proprietary use.
What is the maximum object size in MinIO?
The archived community limits page lists 50 TiB per object, with a 5 TiB maximum per PUT and multipart uploads of up to 10,000 parts.
How does MinIO erasure coding protect data?
It uses Reed-Solomon coding to split objects into data and parity shards across the drives of an erasure set, so objects can be read and healed while enough shards remain.
Can MinIO replace Amazon S3?
It implements the S3 API, but its documentation lists S3 APIs it does not support. Test your applications against that list first.
Next Steps for Minio S3 Deployment
Talk to our experts about implementing Minio S3 for scalable object storage. Learn how industries and different departments use S3 actions like data retrieval and management to enhance workflows and decision-making. Minio optimizes cloud storage operations, improving efficiency and responsiveness.
Ready to put AI agents to work? See an ElixirClaw demo: the agentic OS to build, orchestrate and govern AI agents across your enterprise systems.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE