Garage is an S3-compatible object storage service built for self-hosting at small-to-medium scale, designed on the assumption that your machines are not all in the same rack. It comes from Deuxfleurs, a small self-hosted hosting collective in France that has run it in production since its first release in 2020. Instead of one storage server with replicas bolted on, Garage treats a set of nodes in different locations as the normal case and spreads copies of your data across them, so the cluster survives a node, a disk or a whole site going away.

Written for nodes in different places

Garage knows the capacity and the physical location of every node and builds a storage plan from that, so the copies you ask for are satisfied across locations rather than on one machine. Everything stored is cut into fixed-size blocks, and the block hashes decide both where a block lives and whether it already exists somewhere in the cluster.

• Storage nodes can be added or removed at any time; Garage rebalances data in the background to keep the requested number of copies.
• Replication is configurable: the number of copies and the consistency level are chosen per bucket, from fast and optimistic to stricter read-after-write.
• There is no consensus algorithm such as Raft in the request path, so any node can serve a request without a leader. When nodes are far apart and connected by ordinary internet links, that removes the central bottleneck.

Light on moving parts

Garage is a single Rust binary with a TOML configuration file, and it needs no external service to run: no database, no coordination service, no metadata server. Blocks are deduplicated automatically and optionally compressed with Zstd. Each node can use several data directories spread over several disks, and the project ships Linux builds for amd64, arm64, arm and 386.

What it exposes

• The S3 API, aimed at strict compatibility with the semantics used by AWS and other S3 implementations, so the usual client libraries and tools work unchanged.
• A bucket can be published as a static website, with domain names mapping directly to bucket names, which is something AWS S3 does and most self-hosted S3 clones do not.
• Bucket aliases, including aliases local to a single user, let a bucket be renamed without copying its data, or let different applications use the same bucket name without colliding.
• A REST administration API covering nodes, credentials, buckets and aliases, plus Prometheus metrics for monitoring.

What to expect when running it

Deployment is deliberately plain: write a config file naming the node’s metadata and data directories, start the daemon, then join nodes to the cluster and assign them roles with the garage command-line tool or the administration API. Docker images and systemd units are provided, and there are guides for Kubernetes and Ansible. S3 coverage is not complete, though: some AWS endpoints are unimplemented and listed on the project’s S3 compatibility page, so check that list against the application you intend to point at it. Geo-distributed replication only pays off from several nodes outwards. A single node works fine as plain object storage, but the point of the design is the second location.

Fit in the directory

If you want a lighter store on a single server, SeaweedFS is an S3-compatible alternative with its own file-system ancestry. If the object store is there to back a collaboration suite rather than an application, Nextcloud can use Garage as its storage backend.