Not every project can send data to a third-party cloud provider. Compliance requirements, data sovereignty laws, bandwidth costs, or plain stubbornness all point to the same answer: run your own S3-compatible storage.
The good news is the tooling has matured. The bad news is the landscape shifted in 2025 when MinIO effectively discontinued its open-source Community Edition. This guide compares the self-hosted solutions that matter in 2026, including what replaces MinIO.
Quick Comparison
| RustFS | SeaweedFS | Garage | Ceph RGW | MinIO CE | |
|---|---|---|---|---|---|
| Status | Active | Active | Active | Active | ⚠️ Archived (Feb 2026) |
| License | Apache 2.0 | Apache 2.0 | AGPLv3 | LGPL 2.1/3 | AGPLv3 |
| Language | Rust | Go | Rust | C++ | Go |
| Min RAM | ~2 GB | ~512 MB | 1 GB | 16+ GB | 4 GB |
| Min Nodes | 1 (single) | 1 master + 1 volume | 1 (single), 3+ (replicated) | 3 nodes minimum | 1 (single) |
| S3 API Coverage | Good (core ops) | Good | Core operations | Excellent | Excellent (~99%) |
| Web GUI | Included | Included | None (CLI/API) | Ceph Dashboard | Object browser only |
| Erasure Coding | Planned | Yes (warm data) | No (replication only) | Yes | Yes |
| Geo-Distribution | Not yet | Supported | Built-in | Multi-site replication | Manual/custom |
| Setup Complexity | Very Low | Low-Medium | Very Low | High | Low (source build) |
| Commercial Support | RustFS Inc. (early) | SeaweedFS Inc. | None (community-funded) | Red Hat, IBM, SUSE | AIStor (paid, commercial license) |
| Best For | MinIO replacement, dev/prod | High file counts, mixed workloads | Home labs, edge, small clusters | Enterprise, petabyte-scale | Legacy deployments |
Licensing: Read This Before You Deploy
Licensing is the single most consequential decision factor for production use, and the one most people skip.
| License | What it means for you |
|---|---|
| Apache 2.0 (RustFS, SeaweedFS) | Use it however you want. Modify it, embed it in proprietary products, sell it. Keep the copyright notice. That's it. |
| LGPL 2.1/3 (Ceph) | Similar freedom for self-hosting. Obligations kick in only if you modify and distribute LGPL components. Internal use is unrestricted. |
| AGPLv3 (Garage, MinIO CE) | If you run a modified version and expose it over a network, you must release your source code under AGPL. This applies even without distributing binaries. For internal, unmodified deployments this is fine. For SaaS products or managed services, consult a lawyer or buy a commercial license. |
| Commercial (MinIO AIStor) | Proprietary license. Capacity-based pricing (~$0.02/GB/month). License expiration renders the deployment inaccessible. |
The practical takeaway: If you're building a product or managed service that wraps S3 storage, RustFS or SeaweedFS with Apache 2.0 give you the most freedom. If you're running it internally and never modifying the source, any of the open-source options work.
Provider Breakdowns
MinIO: The Elephant in the Room
MinIO was the default answer for self-hosted S3 storage for years. That changed.
In early 2025, MinIO removed the full admin GUI from the Community Edition, leaving only a basic object browser. Then they went further: the Community Edition is now source-only with no pre-compiled binaries or official Docker images. And as of February 14, 2026, the GitHub repository was archived entirely. It's read-only. No new commits, no PRs, no issues. The project is frozen.
All active development, features, and support have moved to MinIO AIStor, a commercial product under a proprietary license. AIStor pricing is capacity-based (approximately $0.02/GB/month), and an expired license will eventually make the deployment inaccessible.
The community attempted a fork (OpenMaxIO) to preserve the full GUI. It stalled within months.
Should you still use MinIO Community Edition?
For local development and quick testing, you can still build from the archived source. The S3 API coverage remains the best of any open-source option. But the code is frozen. No security patches. No bug fixes. No updates.
If you're evaluating MinIO today, you're really evaluating AIStor. And if AIStor's pricing and license terms don't work for you, look at RustFS (its spiritual successor) or SeaweedFS.
RustFS: The MinIO Successor
RustFS exists because MinIO left a gap. It's a high-performance, S3-compatible object storage system built in Rust, released under Apache 2.0, with an included web GUI. If that sounds like "MinIO but without the license drama," that's the pitch.
The project explicitly positions itself as a migration path from MinIO, claiming 2.3x faster performance than MinIO for 4KB object payloads. It supports coexistence with existing MinIO and Ceph deployments, so migration can be incremental.
RustFS includes a web console for managing buckets and objects out of the box. No separate commercial product needed. You get the GUI that MinIO took away.
Hardware requirements:
- Single node: ~2 GB RAM
- Docker, binary, or source install options all available
- Supports Linux, macOS, and Windows
Where RustFS fits:
- Teams migrating away from MinIO Community Edition
- Dev/test environments that need a quick local S3 endpoint with a GUI
- Projects that need Apache 2.0 licensing (no AGPL restrictions)
- Single-node deployments for small to medium workloads
Where it doesn't: RustFS is still in alpha (v1.0.0-alpha as of early 2026). Distributed mode hasn't been officially released. The project has 104 contributors and active development, but it's not battle-tested at scale. Don't put your production petabyte archive on it yet. For production distributed workloads, SeaweedFS or Ceph are safer bets today.
SeaweedFS: The Permissive Powerhouse
SeaweedFS doesn't get the marketing budget that MinIO does, but it solves a problem MinIO handles poorly: storing billions of small files efficiently.
SeaweedFS uses a master-volume architecture. The master server manages metadata, and volume servers store the actual data. Small files are packed into larger volumes, which means you get O(1) disk reads regardless of file count. For workloads with millions of thumbnails, logs, or IoT payloads, this architecture is significantly faster than traditional object stores.
The S3 gateway sits on top of this and exposes a standard S3 API. It supports authentication, server-side encryption, versioning, and most operations you'd expect. The coverage isn't as complete as MinIO's, but it covers the operations that matter for 95% of real workloads.
Hardware requirements:
- Extremely efficient with memory. ~24 bytes per file in the index.
- 1 master server + 1 volume server minimum (can run on the same machine)
- Scales horizontally by adding volume servers
Where SeaweedFS fits:
- High file-count workloads (millions to billions of objects)
- Mixed storage needs (file system + S3 + FUSE mount)
- Teams that need Apache 2.0 licensing for commercial products
- Resource-constrained environments where every MB of RAM counts
Where it doesn't: If you need every obscure S3 API feature (object lock, advanced lifecycle rules), Ceph's coverage is broader. SeaweedFS is catching up with planned SSE-KMS, IAM, and lifecycle features in 2025, but edge cases exist.
Garage: The Lightweight Contender
Garage is what happens when you build an object store for the world that exists outside data centers.
Built in Rust by the Deuxfleurs association (a French non-profit), Garage is designed for geo-distributed deployments on modest hardware. It runs on Raspberry Pis. It tolerates 200ms network latency between nodes. It ships as a single binary with zero external dependencies. No ZooKeeper. No etcd. No separate metadata database.
The S3 implementation covers core operations: GET, PUT, DELETE, multipart uploads, listing, and pre-signed URLs. It doesn't support object locking, versioning, or lifecycle rules. For many use cases, that's enough.
Hardware requirements:
- Minimum: 1 GB RAM, any x86_64 or ARM CPU, 16 GB storage
- Runs on a single node or across 3+ nodes for replication
- Metadata benefits from SSD; bulk data works fine on HDD
Where Garage fits:
- Home labs and self-hosted infrastructure on constrained hardware
- Edge deployments across multiple physical locations
- Small teams or associations that want S3 storage without running enterprise infrastructure
- Projects where simplicity and operational stability matter more than feature completeness
Where it doesn't: Garage uses replication (typically 3 copies) instead of erasure coding. That means 3x storage overhead for redundancy. For large datasets, this gets expensive fast. There's no commercial support, and the development team is small (1.5 FTEs funded for 2025). If you need enterprise SLAs, look elsewhere.
Ceph RGW: The Enterprise Heavyweight
Ceph is not a product you install on a Saturday afternoon. It's a distributed storage platform that provides object, block, and file storage through a unified system. The RADOS Gateway (RGW) component exposes an S3-compatible API on top of the Ceph cluster.
The S3 API coverage is excellent. Bucket policies, lifecycle management, multi-site replication, IAM, versioning, object lock: it's all there. Ceph is what powers many cloud providers' own object storage offerings behind the scenes.
The trade-off is complexity. A minimum Ceph cluster requires three nodes, each running monitor, manager, and OSD daemons. Each OSD wants 16+ GB of RAM on its host, plus dedicated storage devices. You need 10 GbE networking at minimum. You need someone on your team who understands CRUSH maps, placement groups, and BlueStore tuning.
Hardware requirements:
- Minimum 3 nodes
- 16+ GB RAM per OSD host (plus 5 GB per OSD daemon)
- 10 GbE networking
- 0.5 CPU cores per HDD, 10 cores per NVMe SSD
- SSD recommended for monitor and metadata
Where Ceph fits:
- Petabyte-scale deployments where you need unified block + object + file storage
- Organizations with dedicated storage engineering teams
- Regulated industries that need commercial support (Red Hat, IBM, SUSE all offer Ceph support contracts)
- Multi-site, multi-region deployments with sophisticated data placement requirements
Where it doesn't: If you just need an S3 endpoint and you have fewer than 3 servers, Ceph is overkill by an order of magnitude. The operational overhead is real and ongoing.
Decision Matrix
I just need a local S3 bucket for development
RustFS. Docker or binary install, web GUI included, Apache 2.0 licensed. The fastest path from zero to a working S3 endpoint with a management console.
I'm running a small production service (1-3 servers)
SeaweedFS if you value licensing freedom and have lots of small files. Garage if you want the absolute simplest operations and your nodes are geographically distributed.
I'm building a product that includes S3 storage
SeaweedFS or RustFS. Apache 2.0 means no license headaches. AGPL (Garage) creates obligations the moment your users interact with the storage over a network. MinIO AIStor requires a commercial license.
I need enterprise-grade, petabyte-scale storage
Ceph. Nothing else on this list is designed for that scale. Budget for the ops team to match.
I'm running on a Raspberry Pi or ARM device
Garage. Built for it. 1 GB RAM, ARM CPU, single binary. It works where nothing else will.
I'm migrating off MinIO
RustFS for a like-for-like replacement with a GUI and Apache 2.0 license. SeaweedFS if you need a production-proven distributed system today.
How These Work With Rilavek
Every solution listed here works as an S3-compatible data store in Rilavek. Point your FTP camera, SFTP server, or HTTP upload form at Rilavek, and we stream the data directly to your self-hosted bucket, whether that's RustFS on your desk or a Ceph cluster in your data center.
The combination gives you a professional ingestion pipeline (multiple protocols, multi-data store fan-out, webhook notifications) backed by storage you fully control. No data leaves your infrastructure if you don't want it to.