Finding a New Home for Local S3: Evaluating MinIO Alternatives After Its Commercial Pivot
#DevOps

Finding a New Home for Local S3: Evaluating MinIO Alternatives After Its Commercial Pivot

Tech Essays Reporter
6 min read

When MinIO shifted its focus away from open-source development, it left a gap for developers needing simple, local S3 emulation for demos and testing. This analysis explores lightweight alternatives, weighing their ease of use, S3 compatibility, and long-term viability.

The open-source landscape is never static, but the recent decision by MinIO's creators to pivot toward commercial interests sent ripples through the developer community. For years, MinIO served as a de facto standard for local S3 emulation, a critical component in countless Docker Compose stacks, CI/CD pipelines, and development environments. Its departure from the open-source model wasn't just a licensing change; it was a disruption to the practical workflow of anyone building demos that needed to validate S3 compatibility without touching the actual cloud service.

This analysis stems from a personal need to update a demo stack. The original setup was elegantly simple: DuckDB reading and writing Iceberg data tables, an Iceberg REST Catalog for metadata, and MinIO providing the local S3-compatible storage layer. When MinIO's future became uncertain, the question became urgent: what is the simplest, most reliable replacement that maintains this local S3 functionality without adding complexity? The goal is a drop-in replacement for single-node local use, not a production-grade distributed storage solution.

The criteria for evaluation are straightforward and pragmatic. Any candidate must have a readily available Docker image, as nearly all modern demos are containerized. It must provide robust S3 API compatibility—the entire point of the exercise. It should be free to use, with a strong preference for an OSI-approved open-source license like Apache 2.0. It needs to be simple to deploy on a single node, and it should have a clear path forward, backed by an active community or commercial entity to avoid repeating this scenario in six months. Developer experience, including documentation and configuration clarity, is a significant bonus.

What follows is not a comprehensive feature comparison of all object storage systems. Instead, it's a focused examination of tools that can slot into a local development environment with minimal friction. Multi-node deployments, production support costs, and advanced GUI features are outside the scope. The baseline is the original MinIO-powered Docker Compose stack, where inserting data into DuckDB results in Parquet and Avro files appearing in a MinIO bucket. The test is whether a replacement can achieve the same outcome with comparable ease.

S3Proxy

S3Proxy is one of the more established options, with over 5 million Docker pulls indicating widespread use. Licensed under Apache 2.0, it presents a lightweight, straightforward solution. The configuration is remarkably simple, making it an excellent candidate for a quick replacement. It uses the jclouds library, which was recently moved to the Apache Attic (a repository for retired projects). For local storage purposes, this is likely inconsequential, but it's a data point worth noting for those concerned about the long-term health of its dependencies.

RustFS

RustFS is a newer project, with its first commit in 2024. It boasts a modern interface and includes a GUI, which could be appealing for some use cases. It uses the Apache 2.0 license and has a respectable 100,000+ Docker pulls. However, its alpha status and a recently disclosed security vulnerability give pause. While the vulnerability was patched, the project's youth and the security incident highlight the trade-off between adopting new, potentially innovative tools and relying on more mature, battle-tested ones. For a demo where stability is paramount, this might be a risk.

SeaweedFS

SeaweedFS has been around since 2012, with S3 support added in 2018. It's a mature project with a massive community (29.5k GitHub stars) and over 5 million Docker pulls. Licensed under Apache 2.0, it's a formidable contender. The initial configuration required an external auth file, but the project team responded quickly to feedback, indicating an active and responsive community. This kind of engagement is a strong positive signal. While its website has an enterprise-focused veneer, the project itself is solid open-source software.

Zenko CloudServer

Formerly known as S3 Server, Zenko CloudServer is part of the Zenko toolset from Scality. It's a mature project (first commit in 2015) with Apache 2.0 licensing and a significant number of Docker pulls. It drops in to replace MinIO with relative ease. The main hurdle is the slightly confusing ecosystem of names (CloudServer, Zenko, Scality) and documentation that sometimes links to outdated Docker images. However, for the core task of providing S3-compatible storage, it works well and is backed by a commercial company.

Garage

Garage presents a more complex picture. It's an AGPL-licensed project focused on distributed, S3-compatible storage. While it meets the technical requirements, its configuration is notably more involved than the others. It requires a TOML configuration file and a separate initialization process, which adds steps and complexity to a Docker Compose setup. For a production system needing robust distributed storage, this overhead is justified. For a simple local demo, it's a significant barrier. The project is funded by grants, which is a positive for sustainability, but the configuration complexity makes it a poor fit for the "simple drop-in replacement" criterion.

Apache Ozone

Apache Ozone, spun out of the Hadoop project, is a heavyweight. Licensed under Apache 2.0 and backed by the Apache Software Foundation, it is undoubtedly robust and scalable. However, its architecture is designed for distributed, multi-node deployments. Attempting to run it in a single-node container for local development is not straightforward and feels like using a sledgehammer to crack a nut. It carries the weight and complexity of the Hadoop ecosystem, which is far beyond what is needed for local S3 emulation.

Comparison and Verdict

minio01.excalidraw

When evaluating these options, several factors emerge beyond the initial feature checklist. Governance is critical. While all projects are open-source, only Apache Ozone is under the stewardship of a foundation (the ASF). Others, like MinIO before its change, are controlled by individual contributors or companies who could alter the license at any time. Community health is equally important. Projects with a long history but a single maintainer carry a high "bus factor" risk. If that person steps away, will the community fork and continue development?

For the specific use case of a simple, single-node local S3 for demos, the choices become clearer.

SeaweedFS is a top contender. It's mature, widely used, has a responsive community, and its configuration is straightforward. The recent update to simplify auth configuration is a testament to its active development.

S3Proxy is another excellent choice. It's lightweight, has been around for a decade, and its configuration is arguably the simplest of the bunch. Its dependency on a retired library is a minor concern for local use.

RustFS is intriguing but carries risk due to its alpha status and recent security issue. It might be worth a look for those prioritizing a modern interface, but stability is not guaranteed.

Zenko CloudServer works well but feels slightly more complex to disentangle from its commercial ecosystem. It's a viable option, though perhaps not as immediately straightforward as SeaweedFS or S3Proxy.

Garage and Apache Ozone are ruled out for this specific purpose. Garage's configuration complexity is a hindrance for simple demos, and Ozone is simply too heavy.

The choice ultimately depends on the specific needs of the demo. For maximum simplicity and a proven track record, S3Proxy is hard to beat. For a balance of maturity and active community engagement, SeaweedFS is an outstanding choice. The MinIO situation serves as a reminder that in the open-source world, the stability of a tool is not just about its code, but also about its governance and community. When selecting a replacement, it's wise to look beyond the immediate feature set and consider the project's long-term trajectory.

Robin Moffatt works on the DevRel team at Confluent. He likes writing about himself in the third person, eating good breakfasts, and drinking good beer.

Comments

Loading comments...