A look at MinIO alternatives: Ceph and Garage

MinIO is a popular object-storage server that offered compatibility with the Amazon Simple Storage Service (S3) API. In December 2025, the company behind the project (also named MinIO) announced that the project was in maintenance mode and would not accept new changes; it was archived completely in February 2026. MinIO users have been hunting for alternatives since then, but the array of choices can be baffling. While many other projects aim to fill the space, their strengths and areas of focus tend to vary. Two of the alternatives—Ceph and Garage—are particularly compelling, and both offer solid S3 compatibility.

MinIO did not state its reasons for retiring the project, but it has a proprietary project with similar features that it recommended in place of the now-defunct project. The company has continued to publish vulnerability information that details security problems that affect the last version of MinIO, at least through April of this year, but it is no longer supplying updates to the open-source project.

Most users of MinIO have moved on to other projects that remain on open-source licenses. Ruohang Feng is maintaining a MinIO fork called Silo, but he has indicated that his plans are limited to bugs and security fixes; new feature development is not in scope. Its most recent release was on June 18, 2026.

Core Requirements

Object-store applications like MinIO offer a way to provide S3 capabilities while self-hosting the underlying infrastructure. That is a must for air-gapped systems which cannot rely on external hardware and management, but it is also beneficial for users who want to avoid proprietary services. However, without the global infrastructure that backs most commercial services, high availability can be difficult to achieve in smaller environments. Fortunately, many projects, such as MinIO, have built fault tolerance into their design from the start.

Ease of setup, modest hardware requirements, and S3 API support are fundamental requirements. MinIO became a popular way to provide object storage for environments that operate independently of cloud services but still rely on object-storage availability, often appearing as an add-on service in Kubernetes distributions like MicroK8s.

The S3 API enjoys widespread adoption due to its object-storage capabilities across a variety of use cases. S3 facilitates file-based use cases across many services via HTTP by implementing filesystem reads with GetObject calls and writes with PutObject calls.

For example, S3 storage is used with many Kubernetes environments to provide container image storage and shared storage for container volumes. Its usefulness isn't limited to container workloads, of course: object storage is often used for static web site hosting, backing storage for caching strategies, and more.

The distributed nature of MinIO servers helped lend it resilience in the case of disk or host failures. Fault tolerance is provided by either replication-based strategies across deployments (in which multiple copies of data are retained in separate clusters) or more advanced capabilities based on erasure encoding to more optimally use available space with parity checking within a cluster to reconstruct missing data.

MinIO's untimely retirement means that users need a new alternative, but what to choose? Resilience is often just as important as S3-compatibility to safeguard against data loss. However, solutions that are prohibitively complex or difficult to operate while meeting these requirements can be self-defeating for administrators looking for self-hosted options. Ensuring that deployments remain manageable is therefore important.

The quality of a project's S3 API implementation is one of the most important features to evaluate, but it is not the only consideration. Implementations must also support compatible authentication via a recognized signing method. The current standard is AWS Signature Version 4; Version 2 is deprecated, but some older clients may rely on it. Version 3 was never widely used or supported.

While nearly all object-storage solutions support basic operations like GetObject and PutObject, other features are worth evaluating in the context of individual needs. For example, object lifecycle rules that control whether an object may be deleted after a period of time may not be supported by every S3 alternative. Similarly, server-side object encryption (SSE) might be supported, but there are a number of different modes for SSE, such as user-provided keys included with each request versus server-managed keys.

While the S3 API tends to slowly add features over time, existing endpoints seldom change. Clients can usually rely on established APIs working indefinitely and new APIs appearing rarely. The S3 API user guide describes ongoing changes. Downstream projects like Ceph or Garage most often work by broadening compatibility with new capabilities as endpoints are added. Most libraries and command-line utilities that interact with S3 can accept other object-store endpoints with minimal configuration changes.

Ceph

Ceph is a stable and long-lived project with healthy governance. It is now stewarded by the Ceph Foundation, which is under the Linux Foundation. Its source is hosted on GitHub under a mix of open-source licenses, the most common being LGPL 2.1. Ceph is also one of the most longstanding S3-compatible solutions with many years of development history and stable financial support on record.

Support for Ceph was merged into the mainline Linux kernel back in 2010. Development remains steady with the latest release, 20.2.1, announced in April 2026. Ceph's distinguishing characteristic, in contrast to MinIO or Garage, is its capability for massive scale rather than smaller deployments.

The S3 object-storage API is only one interface to Ceph's storage capabilities: the Ceph Object Gateway built on top of librados provides the S3-compatibility layer, but Ceph's storage abstractions are exposed through other methods as well: Ceph has a POSIX-compliant filesystem (CephFS), and its block devices are used by other open-source projects like QEMU and libvirt to provide backing storage for virtual machines.

Distributed operation is native to Ceph's architecture to offer better fault tolerance and scalability. Ceph clusters operations into small, logical components that can be scaled independently depending on architectural needs. This lends Ceph significant flexibility at the cost of some operational complexity: ceph-osd daemons manage actual storage operations, ceph-mgr daemons coordinate cluster operations and management, ceph-rgw (the RADOS Gateway) provides the actual S3 API, and so on. For large deployments with dedicated teams, these tradeoffs may make sense: if a bottleneck arises in a subsystem's critical path, it can be scaled independently without impacting other systems.

Multiple Ceph monitors form a Paxos quorum, or majority consensus, to ensure consistency and coordinate cluster activity. The ceph-mon utility helps to manage the provisioning process with a reliance on knowledge of initial bootstrapping membership that is typical during initial setup for algorithms like Paxos. Tooling like ceph-deploy can help simplify the initial provisioning process.

As with other clustered services that rely on quorum-based reconciliation, Ceph monitors should run with an odd number of voting members to avoid split-brain situations. Three ceph-mon instances permit the loss of one member without degraded operations, while five allow two members to go offline, and so on. One ceph-mgr is active at any given time, and general guidance is to run one instance per ceph-mon daemon to accept potential failover duties. Other daemons are scaled alongside hardware: ceph-osd usually corresponds to one hardware storage device. Although Ceph can run as a single node, its default mode of operation is better suited for multiple hosts.

System hardware requirements are nuanced: because Ceph supports clusters of potentially large scale, requisite resources are a function of the overall amount of desired effective storage. Components like ceph-mds (metadata servers) can function with as little as 1GB of memory but nodes that function with ceph-mon and ceph-mgr roles may perform well with 64GB but requirements move upward to 128G when ceph-osd (storage daemon) count begins to exceed hundreds of instances. While some of these numbers may seem daunting, Ceph is designed to function capably at these sorts of scales.

Ceph's RADOS Gateway provides a mature S3-compatible API: it supports bucket lifecycles, encryption, and other concepts native to the S3 ecosystem. Administrators reliant on the most S3-like API available will likely find its implementation appealing, especially when coupled with operational tools like access-control lists for buckets (to fine-tune permissions) and bucket notifications (to react to bucket object activity). The project maintains a list that outlines compatibility with the S3 API, including support for both version 4 and version 2 signing.

Garage

At the other end of the longevity spectrum, Garage is a comparatively young AGPL-licensed project; it was started in 2020 by Deuxfleurs, a non-profit hosting company. The project is hosted on independent Forgejo infrastructure.

Written in Rust, Garage foregoes a large feature catalog in favor of a focused goal: distributed, fault-tolerant object storage (without any traditional filesystem or block device drivers.) The latest stable release at the time of writing was version 2.3.0 in April 2026. While relatively new, Garage is positioned as a middle ground between Ceph's non-trivial deployment architecture and simpler projects that lack distributed fault tolerance.

Garage runs homogeneous services and relies on concepts like conflict-free replicated data types (CRDTs) to reconcile consistency drift in the case of events like network partitions. Like delegating consensus to an external protocol such as Paxos, the primitives in play are often sound, but implementations may lack the operational track record drawn from years of practical use. For smaller environments or home labs with one administrator, radically simple configurations that still offer reliability guarantees are attractive.

Forming a Garage cluster is less involved than configuring Ceph Monitors: running nodes yield their identifiers and addresses with the "garage node id" command, after which peers negotiate connections with "garage node connect $node_id" given the target node ID. This allows for a degree of elasticity to Garage deployments, although operators should bear in mind that internal quorums are still consulted for some operations (its design documents refer to Amazon's Dynamo paper). Keeping a majority of Garage nodes online therefore remains important for overall cluster stability.

Garage encapsulates all of its functionality in a single daemon, making it well-suited for smaller or resource-constrained environments. Deployment topology usually follows one daemon that is capable of managing multiple physical disks to present to the overall cluster, per host. However, for large networks with frequent disk maintenance, singular ceph-osd daemons may be a more logical choice that does not require interrupting a singular process managing both cluster membership and storage devices. System requirements are notably minimal with support targeted at CPUs released within the past 10 years and a minimum of 1GB of memory.

The Garage S3-compatibility page is straightforward and maintains comparison tables against other S3 API implementations. While the project is evolving quickly, Garage's API support remains a smaller subset of the overall S3 API. In particular, some missing capabilities such as object versioning (e.g. PutBucketVersioning to implicitly create backup copies of objects) may be baseline requirements, and only version 4 authentication signatures are supported. Ceph offers broader S3 API support, but the operational cost may be worth simplicity tradeoffs that Garage can provide with more manageable requirements.

Despite MinIO's departure from the open-source landscape, alternatives offer mature implementations that can provide significant features without sacrificing many of S3's native capabilities. Ceph and Garage are capable replacements for in-house, self-hosted environments.

Development practices, particularly as they relate to use of large language models (LLMs), have also become a prominent question when considering project maintenance. The Ceph project is still debating its policy with regard to LLMs, but seems to be converging on something similar to the Linux kernel AI contribution policy. Garage recently merged a policy on contributions authored by LLMs and other coding assistants; it allows LLM-usage for "some tedious code generation tasks", but largely forbids their usage for documentation, writing bug reports, or writing most code to be submitted to the project. While the Garage repository has no commits on record either authored or co-authored by LLMs, Ceph's commit history includes code increasingly co-authored by Claude, ChatGPT, and Gemini.

Anecdotally, my experience moving from MinIO to Garage has been positive and without negative surprises. Cluster formation is easy, recovering from hardware failures is reliable, and its API has been compatible with all of my use cases. Garage is well-suited for my home lab, and other small-scale operators can likely benefit from multiple servers for failover without the mental burden of orchestrating relatively more complex deployments. In the case of both MinIO and Garage, my clusters have undergone rolling updates and the occasional dead disk while remaining operational.

Real-world experience

Total usable storage is a relatively simple calculation in the case of both Ceph and Garage. Without any replication configuration, either solution presents one logical view into all pooled devices: for example, three 1TB disks appear as 3TB of usable space. Replicating with a factor of two reserves one copy of managed data, which halves available space to 1.5TB. Ceph's ability to erasure code volumes offers even better capacity through the use of parity calculation and would offer roughly 2TB of usable space this in this imaginary scenario. My own Garage infrastructure spans six hosts across ten total physical disks.

Garage has yet to fail catastrophically, while I had been forced to rebuild my MinIO cluster on at least one occasion due to irreconcilable cluster problems. Overall I would characterize Garage as simpler to operate and easier to use than MinIO. Use cases differ, though, and large-but-capable solutions like Ceph are almost certainly better suited for environments with stricter needs, closer S3 API parity, or stronger stability guarantees.