If you run anything data-intensive — backups, ML training sets, media, Kubernetes persistent volumes — you eventually want an S3-shaped bucket you control. MinIO is the open-source answer. It is a high-performance, S3-compatible object store written in Go: any application that speaks the S3 API can point at it with a URL change and suddenly your data lives on your own hardware, not in a vendor's bucket with an egress bill attached.
The appeal is concrete and large. MinIO saturates 25-gigabit networking on commodity hardware, scales to exabytes via erasure coding, and gives you a single binary or a distributed cluster with no proprietary lock-in. For AI/ML pipelines that would otherwise bleed money on cloud egress, that is transformative.
But MinIO has the one licence story in this batch that should make a commercial-product builder stop and read the terms. MinIO is
AGPL-3.0, a strong copyleft licence with a network clause. It was Apache-2.0 until 2021, when the project switched to AGPL. Using MinIO internally is free and unrestricted. Embedding a modified MinIO into a proprietary product you distribute — or offering it as a service built on modified MinIO — triggers AGPL obligations to release your modifications. There is also a quieter operational shift: the community edition is now
distributed as source code only, with no pre-compiled binaries for the community version. Both facts change what "just use MinIO" means depending on who you are.
This is a long, honest teardown. We cover what MinIO delivers, the S3 compatibility that makes it valuable, the erasure-coding durability model, the AGPL licence reality, the source-only distribution change, the absent CDN, and precisely where your objects and metadata go. If you are weighing MinIO against cloud S3 or against a permissively-licensed alternative, this article tells you exactly where the sharp edges are.
1. What MinIO Is
MinIO is a high-performance, S3-compatible object storage server. You create buckets, upload objects, set lifecycle policies, version buckets, and encrypt at rest — the full S3 feature set, implemented against the S3 API so existing AWS SDK code works with a configuration change, not a rewrite. It is written in Go and runs as a single static binary or in distributed mode across multiple nodes.
The project reports in the high-50-thousands to 60-thousands of GitHub stars and is among the most-deployed object stores in the cloud-native ecosystem. It is "native to Kubernetes" — the only object store suite available across every public cloud, every Kubernetes distribution, the private cloud, and the edge, in the project's own framing. For teams building AI/ML, analytics, and data-intensive workloads, MinIO is the default on-prem S3.
2. S3 Compatibility: The Whole Value Proposition
The reason MinIO matters is not that it stores blobs — lots of things store blobs. It is that it stores them
the S3 way. Any tool, SDK, or service that expects an S3 endpoint —
aws s3,
boto3, the Kubernetes CSI driver, a Rails Active Storage config, an ML data loader — points at MinIO with a different endpoint URL and a different credential, and everything works. No code changes. That drop-in compatibility is the moat: it lets you keep the S3-shaped architecture your tooling already assumes while moving the data onto hardware you own.
The honest limit: S3 compatibility is "the common subset plus most of the rest," not a byte-perfect reimplementation of every AWS quirk. Exotic S3 features (certain object-lock edge cases, specific inventory/reporting formats) may differ. For the 95% case — buckets, objects, multipart upload, presigned URLs, lifecycle, versioning, encryption — MinIO is S3. For the exotic 5%, test against your exact usage before you migrate a production pipeline.
3. Performance: Why It Is the Cloud-Native Default
MinIO is engineered for throughput. On fast commodity hardware it saturates 25GbE networking — meaning the bottleneck becomes your network, not the storage software. That matters for AI training pipelines that hammer an object store with parallel reads, and for backup targets that ingest terabytes in a window. The distributed mode stripes data across nodes so aggregate bandwidth scales with the cluster.
This is the contrast with a general-purpose filesystem or a database pressed into blob duty: those were not built to stream objects at line rate. MinIO was. If your workload is "many large objects, many parallel readers," MinIO is the right shape. If your workload is "millions of tiny files with POSIX semantics," an object store — MinIO included — is the wrong tool; use a filesystem or a purpose-built store.
4. Erasure Coding and the "11 Nines" Claim
MinIO protects data with erasure coding rather than RAID. You configure a stripe — say, 4 data and 2 parity drives — and MinIO can lose up to the parity count of drives without losing data, reconstructing from the survivors. The marketing cites "11 nines" of durability (99.999999999% annualized), the same class of claim AWS makes for S3. That durability is a function of the erasure scheme and the drive-count math, not magic.
The honest reading: erasure coding gives you fault tolerance without the space overhead of full replication (you do not triple your storage), but it assumes you have enough drives in the stripe and that you monitor and replace failed drives promptly. "11 nines" presumes a healthy, monitored cluster — a neglected one with silent drive death and no healer running loses the durability guarantee. Durability is a practice, not a number on a slide.
5. Single Binary vs Distributed Mode
MinIO offers two deployment shapes:
- Single node, single drive (or single node, multi-drive): one binary, one host. Great for dev, a home lab, or a small backup target. No HA — the host is the failure domain.
- Distributed: multiple nodes, each contributing drives to a shared erasure-coded pool. This is where MinIO scales to exabytes and survives node loss. It requires an even number of drives per node and a consistent topology.
The operational trap is treating a single-node instance as production. It is not resilient; a dead disk or host is data loss unless you have backups elsewhere. MinIO's own docs are clear that distributed is the production path. If you want "S3 at home for backups," single-node is fine. If you want "our ML training data lives only here," you need distributed plus monitoring plus off-cluster backup, because erasure coding protects against drive loss, not against a deleted bucket or a ransomware event.
6. Encryption at Rest and in Transit
MinIO encrypts objects at rest (server-side encryption) and supports TLS in transit. You can use MinIO's internal key encryption server (KES) backed by your KMS (HashiCorp Vault, AWS KMS, etc.) so keys live outside the object store — a proper separation of duties. Client-side encryption is also possible if you want objects opaque even to the server.
The honest note: encryption at rest protects a stolen disk, not a compromised credential. If an attacker has valid S3 credentials, server-side encryption does not help — they read decrypted objects. Key management via KES + external KMS is the mature pattern; rely on it for anything sensitive rather than letting MinIO hold keys locally. Our
2026-09-12-github-keycloak piece is about auth, but the principle — secrets in a dedicated system, not co-located with the data — applies here too.
7. The Licence: AGPL-3.0, and Why 2021 Matters
This is the section commercial builders must read. MinIO was Apache-2.0 until 2021, when it moved to
GNU AGPL v3.0. The difference is not academic:
- Apache-2.0 is permissive: use it, modify it, embed it in a closed product, no source-disclosure obligation.
- AGPL-3.0 is strong copyleft with a network clause: if you modify MinIO and let users interact with it over a network (i.e., you run a service built on modified MinIO), you must release your modifications to the community under AGPL. Internal use — storing your own company's data — is unrestricted and free. Distributing a product that embeds modified MinIO, or offering a service built on modified MinIO, triggers the obligation.
The practical split:
internal infrastructure use is free regardless of company size under AGPL. A bank running MinIO for its own backups owes nothing. A vendor who forks MinIO, changes it, and ships it inside a closed appliance or as a hosted service owes the source of their changes. The 2021 shift surprised commercial users who had built on the Apache assumption; if you are one, re-read your obligations against the current licence before you ship.
8. The Commercial Licence and AIStor
MinIO offers a commercial licence (via AIStor, its product line) for workloads that need proprietary or commercial usage without AGPL obligations, plus production-level SLA/SLO-backed support. AIStor comes in a Free community edition and an Enterprise edition with commercial support. The community edition remains AGPL-3.0; the enterprise relationship is support and a licence that removes the copyleft friction for embedding.
The pricing for support tiers cited in reviews runs around $10/TB/month (Standard) and $20/TB/month (Enterprise) for SLA and dedicated support — not the software itself, which stays free under AGPL for internal use. So MinIO's cost model is: free to operate internally, paid only if you want vendor support or a proprietary-embedding licence. That is a clean, defensible model; the confusion comes only from teams that assumed Apache and got AGPL.
9. The Source-Only Community Distribution Change
A quieter but real operational shift:
the MinIO community edition is now distributed as source code only. Pre-compiled binary releases for the community version are no longer provided; the maintained path is to build from source (
go install github.com/minio/minio@latest or build a Docker image from the provided Dockerfile). Legacy binaries remain available for reference but are unmaintained and receive no updates.
Why this matters to you: "download the binary and run it" is no longer the supported community workflow. You compile it (needs Go 1.24+) or build a container image. For a Kubernetes shop running the Operator or building images in CI, this is a non-event. For a casual self-hoster who wanted a one-line binary install, it is a step up in effort and a reason to standardize on building your own image and pinning it. Treat your MinIO image as something you build and version, not something you
curl and run.
10. No Built-In CDN: Serve Public Assets Elsewhere
MinIO has no built-in CDN or edge distribution. If you want to serve objects publicly — a website's images, a video, a downloadable artifact — at low latency to a global audience, you put a reverse proxy or a separate CDN layer in front of MinIO. The object store answers S3 requests; it does not cache or edge-deliver them.
The honest implication: MinIO is excellent as the origin/storage layer and poor as a public delivery layer on its own. Pair it with your reverse proxy (our
2026-08-25-github-traefik guide covers the proxy) or a CDN for public serving. For private, internal object access, the missing CDN is irrelevant. For public, high-concurrency serving, budget the delivery tier separately.
11. The Web Console: Functional, Not Pretty
MinIO ships an embedded web console for browsing buckets, uploading objects, and basic admin. It is functional — you can create buckets, inspect contents, and generate presigned URLs from a browser — but it is not a polished product UI. For day-to-day admin, the
mc (MinIO Client) CLI is the real tool: Unix-like commands (
mc ls,
mc cp,
mc mirror,
mc admin info) that feel natural to operators and script cleanly.
The honest take: manage MinIO with
mc and automation, not the console. The console is for quick looks and onboarding; production object-store operations belong in scripts and CI, not a clicking UI. If your plan is "click around the console," you are not yet operating MinIO at the level its durability promises.
12. Lifecycle, Versioning, and Eventing
MinIO supports bucket versioning (keep N versions, protect against accidental deletes), lifecycle policies (transition or expire objects by age), and event notifications (fire a webhook, queue message, or function on object create/delete). These are the features that make it a real S3 substitute rather than a dumb blob bucket. Lifecycle expiry is how you keep a backup bucket from growing forever; versioning is how you survive a
rm -rf via the API; eventing is how you trigger a pipeline when a file lands.
The caveat: lifecycle and versioning are operational disciplines, not defaults. A versioned bucket with no expiry becomes an ever-growing bucket; an unversioned one offers no undo. Configure both deliberately per bucket's purpose. MinIO gives you the levers; the retention policy is a decision you make, not a setting it infers.
13. Kubernetes Native: The Operator
MinIO is "native to Kubernetes" and ships an Operator for cluster deployment, plus a DirectPV CSI driver for direct-attached storage. For a K8s shop, the Operator handles tenant creation, scaling, and upgrades; DirectPV gives you a CSI that maps pods to local disks for performance. This is why MinIO dominates the cloud-native object-storage conversation — it is not bolted onto Kubernetes, it is built for it.
The honest note: running MinIO well on Kubernetes still means understanding erasure-coding topology, drive provisioning, and the failure domains of your nodes. The Operator automates the cluster lifecycle; it does not automate the storage architecture decisions. A badly-designed tenant topology is a badly-designed tenant topology whether the Operator deployed it or not.
14. What It Costs: The Total Picture
Numbers:
- Software (internal use): $0 under AGPL-3.0. No per-TB, no per-seat fee for storing your own data.
- Support (optional): ~$10/TB/month Standard, ~$20/TB/month Enterprise for SLA and dedicated support, or a commercial licence for proprietary embedding.
- Infrastructure: the dominant cost. Drives, nodes, network. A single-node backup target is cheap; a distributed exabyte-class cluster is real capital and power.
- Your time: building from source (post-2021), operating the cluster, monitoring drives, running healers, backing up off-cluster.
- Vs cloud S3: the win is egress and per-GB savings at scale, plus no vendor lock-in. The cost is you own the hardware and the ops.
The business case: at scale, cloud S3 egress and request costs dominate; MinIO on owned hardware removes egress and gives you the same API. For a data-intensive shop, that math is decisive. For a team storing a few gigabytes, cloud S3's free tier is less work.
15. Where Your Data Goes
Data sovereignty is central to MinIO's pitch, so be precise:
- Objects and metadata: stored on your drives, in your cluster, on your hardware. Self-hosted, this is fully your infrastructure. No data leaves unless you replicate it off-cluster.
- Encryption keys: with KES + external KMS, keys live outside the object store (proper separation). Without it, keys are local — weaker.
- Telemetry: MinIO collects some usage telemetry; review and disable what you do not want in a sovereignty deployment.
- No third-party relay: unlike a chat push gateway, object storage has no default external path. A self-hosted MinIO with no off-cluster replication keeps objects entirely on your network.
- Enterprise features: add monitoring but, like the community edition, no data leaves your network by default.
The honest summary: a self-hosted MinIO keeps your objects on your disks, under your encryption if you wire KES, with no mandatory external party. That is the cleanest data-sovereignty story in this batch — cleaner than Rocket.Chat's push relay or any SaaS IdP.
16. Honest Limitations
Direct about where MinIO disappoints:
- AGPL-3.0 means modified-embedding commercially triggers copyleft. Internal use is free; shipping a modified MinIO product is not licence-free.
- Source-only community distribution since the 2021 shift — no pre-built binaries; you build from source or an image.
- No built-in CDN — public serving needs a proxy/CDN layer.
- Single-node is not production — distributed + monitoring + off-cluster backup required for real resilience.
- The console is utilitarian, not polished; real ops happen via
mc and automation.
- Not a filesystem — POSIX-semantics, tiny-file, or lock-heavy workloads are the wrong fit.
- Erasure-coding durability assumes a healthy, monitored cluster — neglect voids the "11 nines."
None are defects in the software. They are the real scope of owning S3-compatible storage. A team that knows them runs MinIO happily; a team that assumes "free Apache binary drop-in" discovers two surprises.
17. MinIO vs the Field
Against
cloud S3 (AWS/GCP/Azure): MinIO wins on egress cost, lock-in, and data residency; loses on managed convenience, global edge, and "someone else runs it." Choose MinIO when egress or residency dominates; choose cloud S3 when convenience and global delivery dominate.
Against
Ceph RADOSGW (also open-source S3): Ceph is a broader storage platform with S3 as one gateway; MinIO is S3-native and simpler to reason about for pure object workloads. Ceph suits teams wanting block+file+object in one; MinIO suits teams wanting fast, focused S3.
Against a permissively-licensed store: if AGPL is a hard blocker for your embedding model, MinIO is not your tool. An internal-only deployment has no such block. License fit is the deciding variable, not features.
18. When to Choose It — and When Not To
Choose MinIO if: you need S3-compatible storage you own; egress or residency makes cloud S3 expensive; you run AI/ML or backup pipelines at scale; you are comfortable building from source and operating a cluster; your use is internal (AGPL-clean).
Do not choose it if: you plan to embed a
modified MinIO in a closed-source product without honoring AGPL (get a commercial licence or pick a permissive alternative); you need a public CDN built in (add a delivery layer); your workload is POSIX filesystems, not objects; you want a one-binary no-build casual install (the source-only shift raised that bar).
19. A Pragmatic Deployment Checklist
For a production self-hosted MinIO:
1. Decide topology: single-node (dev/backup) vs distributed (production). Use an even drive count per node.
2. Build from source or your own pinned image (community binaries are gone); standardize the image in CI.
3. Configure erasure coding for the durability you need; size parity to your failure tolerance.
4. Enable TLS; put it behind a reverse proxy for public serving if needed (see
2026-08-25-github-traefik).
5. Wire KES + external KMS so keys live outside the store.
6. Enable bucket versioning where undo matters; set lifecycle expiry to bound growth.
7. Deploy
mc; script admin and backups rather than using the console.
8. Monitor drive health and run healers; alert on degraded stripes (wire into
2026-08-27-github-grafana).
9. Back up off-cluster — erasure coding is not a backup; a deleted bucket is gone without one.
10. Review and disable unwanted telemetry; document for audits.
11. If embedding in a product, confirm AGPL obligations or obtain a commercial licence.
20. The Verdict
MinIO is the obvious choice when you need S3 compatibility on your own hardware. It is fast enough to saturate networks, S3-compatible enough that AWS SDK code just works, and free under AGPL for any internal use regardless of scale. For data-intensive and AI/ML workloads, removing cloud egress and lock-in is transformative, and the durability model is sound when the cluster is healthy and monitored.
The sharp edges are the licence and the distribution model, not the software. AGPL-3.0 means modified commercial embedding carries copyleft obligations — fine for internal infrastructure, a real consideration for product builders. The source-only community distribution means you build rather than download. Neither is a flaw; both are facts you must plan around. If you store your own data and operate a cluster competently, MinIO is the most straightforward S3-compatible option available, and your objects stay on your disks under your encryption. If you ship a modified MinIO inside a closed product, read the licence and get the commercial licence first.
21. Migrating From AWS S3 (or Any S3)
Teams move to MinIO to kill egress or meet residency, so S3 migration is common. The good news is the API: tools like
aws s3 sync,
rclone, or MinIO's own
mc mirror copy data between an S3 source and MinIO with credentials swapped and endpoints changed — no application rewrite. Point your app's S3 client at the MinIO endpoint; if you used the common S3 subset, it works.
The honest friction is in the exceptions: object-lock legal-hold semantics, bucket inventory/reporting formats, and any AWS-specific extension your pipeline assumed. Audit your actual S3 API usage before cutover; mirror a sample bucket, run your pipeline against MinIO in staging, and only then flip production. Egress from the source cloud during migration is a real cost — do the bulk copy during off-peak or over a peering link if available. The migration is mostly mechanical; the exceptions are where you test.
22. Backup Strategy: Erasure Coding Is Not a Backup
The single most misunderstood point about MinIO: erasure coding protects against
drive failure, not against
data loss from actions. A deleted bucket, a ransomware-encrypted object set, or a bad lifecycle policy that expires everything is not a drive failure — erasure coding cheerfully keeps the deleted or encrypted version durable. You still need a backup.
Follow 3-2-1 thinking adapted to objects: keep three copies (primary, erasure-coded pool, off-cluster replica), on two media, with one off-site. Use
mc mirror to a second MinIO or to cold storage on a schedule; version buckets so a bad write is recoverable; test restores quarterly. A MinIO cluster that is "durable" but has no off-cluster copy is one misconfigured lifecycle rule away from total loss. Durability and backup are different guarantees; MinIO gives you the first and assumes you build the second.
23. Security Hardening
Because an open S3 endpoint is a data-leak machine, hardening is mandatory:
- Terminate TLS; never serve plaintext. Put MinIO behind your reverse proxy with valid certs.
- Use distinct access/secret keys per application; never a shared root key in app code.
- Apply bucket policies and IAM-style policies to restrict who can read/write what; default to least privilege.
- Enable server-side encryption; wire KES + external KMS so keys are outside the store.
- Disable the console or restrict it by network for admin; script with
mc.
- Gate access behind identity — our 2026-09-12-github-keycloak piece covers the IdP you should be using instead of an open endpoint.
- Monitor access logs; alert on anomalous listing or bulk downloads.
- Review telemetry; disable what you do not want phoned home.
An unhardened MinIO is a public bucket waiting to happen. Treat it like the critical data store it is.
24. Performance Tuning for Throughput
To actually hit line-rate:
- Use distributed mode with enough nodes that aggregate bandwidth exceeds your network — single-node never saturates 25GbE.
- Match drive count per node to the erasure scheme; uneven topologies waste capacity or parity.
- Use multipart upload for large objects; it parallelizes and survives interruptions.
- Co-locate compute with storage for ML training (same zone/rack) to avoid network hops on every read.
- Tune the client concurrency —
mc and SDKs honor parallel flags; raise them on fast links.
- Benchmark with
warp (MinIO's own S3 benchmarking tool) before promising a number to a workload owner.
The trap is over-provisioning nodes but under-provisioning the network or the client concurrency, then blaming MinIO for "slow" reads that are actually a 1GbE link or a single-threaded client. Measure the link and the client before the store.
25. The AGPL Compliance Checklist (For Product Builders)
If you build a product around MinIO, do this before shipping:
1. Are you using MinIO
unmodified, internally? You owe nothing beyond AGPL's usual terms; internal use is free.
2. Are you
modifying MinIO and offering it as a network service or inside a distributed product? AGPL requires you release your modifications under AGPL to the users interacting with that service.
3. Do you need
proprietary embedding without copyleft? Obtain a commercial licence from MinIO (AIStor) — do not assume Apache.
4. Are you
redistributing a modified MinIO binary? Same AGPL source-disclosure obligation attaches.
5. Did you
build from source (required now for community) and pin the commit for reproducibility?
The licence is not a trap if you read it; it is a trap if you inherited an "it's open source, ship it" assumption from the Apache era. Re-verify against the current AGPL-3.0 text and, for anything commercial, get the commercial licence in writing.
26. Multi-Tenancy and the Tenant Model
On Kubernetes, MinIO models isolation via
tenants — each tenant is its own pool with its own drives, credentials, and encryption. That is the clean multi-tenant boundary: a tenant breach does not expose another tenant's objects. The Operator manages tenant lifecycle, so a SaaS can spin a tenant per customer at signup.
The trade is operational surface: more tenants mean more pools to monitor, heal, and back up. A single giant shared pool with bucket-level isolation is simpler but a weaker security boundary — a misconfigured policy leaks across customers. For anything multi-customer, per-tenant pools are the right call; automate them and accept the monitoring overhead. Decide this before onboarding customers; migrating objects between tenants later is a project.
27. Frequently Asked Questions
Is MinIO free? For internal use, yes — AGPL-3.0, no per-TB or per-seat fee. Modified commercial embedding requires honoring AGPL or a commercial licence.
Do I download a binary? Not for the community edition anymore — it is source-only since the 2021 shift. Build from source (
go install) or your own image.
Is erasure coding a backup? No. It survives drive failure, not deletion or ransomware. Keep an off-cluster copy.
Does it have a CDN? No. Put a proxy/CDN in front for public serving.
Can I replace AWS S3? For the common S3 subset, yes — same API,
mc mirror migrates data. Test exotic features first.
Where do my objects go? On your drives, in your cluster. With KES + external KMS, keys live outside the store. No mandatory external party.
28. Sizing by Scale
- Home lab / small backup (< 10 TB): single node, multi-drive, erasure-coded. Cheap, no HA; back it up off-cluster. Perfect for "my own S3 for backups and media."
- Team / department (10–100 TB): distributed, 4+ nodes, monitored drives, versioning + lifecycle, off-cluster mirror. One operator can run it.
- Data-intensive / ML (100 TB – PB): distributed at scale, KES + external KMS,
warp-benchmarked, Grafana-monitored, tenant model if multi-customer. A platform team owns it.
- Exabyte-class: the documented top end — large distributed pools, careful topology, dedicated storage engineering. MinIO's marketing ceiling; few reach it.
Note the licence stays $0 at every tier for internal use. Only hardware and ops grow. That flat curve is why data-heavy shops pick MinIO over per-GB cloud S3.
29. The 2021 Licence Shift in Retrospect
Worth a clear-eyed look, because it shaped the project's relationship with commercial users. MinIO moved from Apache-2.0 to AGPL-3.0 in 2021. The stated intent: protect the project from cloud providers repackaging it as a managed service without contributing back, while keeping internal use free. The effect: teams that had built products on the Apache assumption had to re-evaluate. Some migrated to permissively-licensed alternatives; some obtained a commercial licence; most internal users noticed nothing because internal use was always AGPL-clean.
The lesson for you: licence is a strategic variable, not a footnote. A project can change it. If your business depends on a specific licence, either isolate your dependency so a shift does not sink you, or get a commercial relationship that insulates you. MinIO's shift was a feature for sovereignty-minded self-hosters and a cost for embedders — know which camp you are in before you commit.
30. A 30-Day Evaluation Plan
- Week 1: Build MinIO from source (or your pinned image); stand up a single-node erasure-coded instance; create a bucket;
mc it from your laptop.
- Week 2: Mirror a sample dataset from an S3 source with
mc mirror; run your real pipeline against MinIO in staging; verify the API subset you use.
- Week 3: Deploy distributed (4 nodes); wire TLS + reverse proxy; enable KES + external KMS; set versioning + lifecycle;
warp-benchmark throughput.
- Week 4: Implement off-cluster backup; monitor drive health in Grafana; review AGPL obligations against your use; if embedding in a product, secure the commercial licence. Decide with numbers and a tested restore.
A pilot this disciplined turns "run our own S3" from a hope into a defensible decision — with a benchmark for the workload owner and a restore test for the risk team.
31. The Bottom Line for Different Teams
- Home lab / solo: single-node MinIO is the easiest "my own S3" you will run. Back it up off-cluster; ignore the HA talk.
- Data-intensive startup / ML shop: this is MinIO's home turf. Kill egress, keep the S3 API your pipelines expect, own the hardware. The licence is free; the cluster is the work.
- Product builder embedding storage: read the AGPL. Internal use is clean; modified-embedding or proprietary shipping needs the commercial licence. Do not inherit an Apache assumption.
- Team wanting a public CDN: MinIO is the origin, not the edge. Pair it with a delivery layer and stop expecting built-in global serving.
MinIO is fast, S3-compatible, and free for internal use — and it asks exactly two things of you: respect the AGPL if you ship it modified, and build from source since the binaries left. Honor both and it is the most straightforward object store you can own.
Related
For the rest of a sovereign, self-hosted data stack, these pieces from our series travel with MinIO:
Comments (0)
No comments yet. Be the first to comment!