Garage

What is Garage?

Garage is a small S3-compatible object store designed for clusters spread across unreliable or low-bandwidth machines. It needs far less memory than MinIO and tolerates nodes coming and going.

Best for

Object storage across a distributed or low-power cluster

Why choose Garage

Garage is an S3-compatible object store built for the case MinIO does not handle well: a cluster spread across machines that are not in a datacenter, connected by links that are slow, asymmetric or unreliable. It uses far less memory per node, tolerates nodes disappearing and rejoining, and is designed so a geographically distributed deployment keeps working when a site is offline. For someone running object storage across a couple of homes, a set of cheap VPS instances or a low-power cluster, that is a materially different set of assumptions than a datacenter-grade system. It also supports the S3 API and static website serving, so most applications written against object storage work unchanged.

Replaces

• AWS S3
• MinIO
• Ceph

Key features

• S3-compatible with a lightweight footprint
• Multi-node replication and topology control
• Works on heterogeneous, low-power hardware
• Single Rust binary per node

What to watch out for

It is a smaller project with a correspondingly smaller community, so unusual problems have fewer documented answers than the mainstream alternatives. Capacity planning and redundancy work differently than in a datacenter store — the replication model assumes nodes that fail and return, and misjudging it can leave you with less durability than you expected. Its performance profile favors throughput and resilience over the raw small-object speed that a single fast machine can offer. Some S3 features are implemented in a subset, so verify the specific operations your application needs rather than assuming full compatibility.

How to deploy

• Install the binary on each node
• Configure a shared layout and cluster membership
• S3 endpoint and keys per bucket

Getting started

Start with the documented layout for a three-node cluster even in testing, because the failure behavior is what you are adopting it for and it does not show up on one node. Set up node identities and keys deliberately, and keep the configuration in a repository since a node rebuilt from memory can corrupt cluster assumptions. Verify the durability you actually configured by removing a node and confirming the cluster behaves as expected. Put the S3 credentials to work from an application that needs them rather than only testing with a client. Include the configuration and, where relevant, the data layout in your documentation so a rebuild is possible.

Typical setup

A cluster laid out with separate node identities and keys across at least three machines, with the configuration kept in a repository so a rebuilt node rejoins correctly instead of corrupting assumptions. Replication is set per bucket based on the durability actually intended. Durability is verified by removing a node and confirming that the cluster serves data as expected. The S3 credentials are used by a real application rather than a test client, and the topology is documented, because recovery depends entirely on it being known.

Who should look elsewhere

Choose MinIO or a filesystem-based store if all your machines are in one place with a reliable network, because Garage's advantages do not apply and its smaller ecosystem becomes a cost. Avoid it if you need comprehensive S3 feature coverage, since compatibility is good but not complete. And do not adopt a distributed store for a single machine — the complexity buys nothing until there is more than one failure domain.

Project health

• GitHub stars: 4,625
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.