An S3-compatible object store written in Rust for small, self-hosted, geographically spread clusters running on ordinary machines and home connections. It gives backup tools, static sites and applications an S3 endpoint you own instead of a bucket you rent.
Our verdict on Garage#
Garage is AGPLv3, built and run in production by Deuxfleurs since 2020, and it is what most people leaving MinIO should look at first. Version 2.4.0 landed 6 September 2026, following 2.0.0 in June 2025, so the release cadence is real. The scope limits are deliberate and you should read them before committing: no object versioning, no object lock, no bucket policies or ACLs (it uses its own per-access-key-per-bucket permissions instead), no server-side encryption, and no bucket notifications. It also replicates in full rather than erasure coding, so a three-node cluster gives you one third of your raw disk as usable capacity, where MinIO's erasure coding was far more efficient. What you get in exchange is a system designed for nodes on separate sites and consumer uplinks, with an actual maintainer and an actual upgrade path. For a restic or Kopia target, none of the missing features matter.
Who Garage is for#
Choose it if
- Anyone who needs an S3 endpoint for restic, Kopia or an application, and does not need the exotic parts of the S3 API.
- Three friends or three sites with a spare machine each, wanting real geographic redundancy without renting cloud storage.
- Operators leaving MinIO who want a maintained AGPL project rather than an archived repository.
- Small hardware: a Rust binary with no JVM, no database service and no operator, running fine on ARM boards.
Look elsewhere if
- You need S3 object versioning or object lock, for example to make a backup bucket immutable against a compromised client. Garage supports neither.
- You depend on bucket policies, ACLs, server-side encryption or bucket notifications, because Garage substitutes its own simpler permission model for the first two and does not implement the rest.
- Raw capacity efficiency is the priority. Three-way replication costs two thirds of your disk where erasure coding would have cost far less.
What running it actually looks like#
One process per node. The container is dxflrs/garage and it listens on 3900 for the S3 API, 3901 for inter-node RPC, 3902 for the static website endpoint and 3903 for the admin API. Before the first start you generate an rpc_secret shared by all nodes and choose replication_factor, and for a single machine that must be 1 because the default 3 will not place data on one node. Mount two paths: metadata (SSD, LMDB) and data blocks (bulk disk). After the daemons are up, the cluster does nothing until you assign a layout: garage layout assign stages changes and garage layout apply --version N commits them, and forgetting the second command is the classic first-hour mistake. Buckets and access keys are created with the garage CLI, not through a web console; there is no bundled UI.
Resource profile#
- Memory
- 150 MB idle, around 500 MB in ordinary use. Estimates: the project publishes no minimum RAM figure. The metadata engine is memory-mapped LMDB, so resident memory tracks metadata size and object count rather than stored bytes, and a node holding millions of small objects wants meaningfully more than one holding the same terabytes as large files.
- CPU and acceleration
- Modest. Hashing on write and the background resync and scrub workers are the load; there is no erasure coding maths and no server-side encryption to pay for.
- Storage growth
- Full replication, not erasure coding: with `replication_factor = 3` usable capacity is one third of raw. Metadata on SSD is strongly recommended, and metadata snapshots can temporarily need up to four times the size of the metadata database.
- Operational load
- 3 of 5, Moderate. One process per node, but a real distributed system underneath: cluster layout is versioned and applied explicitly, node identity matters, and the 1.0 to 2.0 upgrade required stopping every node at once. Restores need a documented order because metadata and data blocks are separate concerns.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Garage keeps metadata and data separately, and only one of them is regenerable. The data blocks are content-addressed and replicated, and garage repair plus the background scrub verify and re-sync them between nodes. The metadata database is the irreplaceable part: it holds bucket definitions, object names, access keys and the cluster layout, so blocks without metadata are an unreadable pile of hashes. Snapshot it with garage meta snapshot --all rather than copying LMDB files from under a running node, and give the snapshot directory room, because the documentation warns Garage may hold up to three snapshots and need roughly four times the database size. There is no server-side encryption, so anything sensitive should already be encrypted by the client writing it, which is exactly what restic and Kopia do.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
1.0 to 2.0 is not a rolling upgrade
The migration document is explicit: shut down all v1.0 nodes simultaneously and restart them all simultaneously on v2.0, because the internal RPC protocol changed and mixed-version clusters do not work. You also have to edit the configuration first, replacing replication_mode with the new replication_factor and consistency_mode pair. Run repairs and take a metadata snapshot before you start, since there is no partial rollback once nodes have written 2.0 metadata.
The admin API v1 endpoints were removed in 2.0
Garage 2.0 reworked the administration API around /v2/ paths, and most /v1/ endpoints no longer exist. Anything you scripted against the old API, including Terraform providers, dashboards and bucket provisioning jobs, breaks on upgrade rather than degrading. 2.0 also introduced multiple named admin tokens, so the single admin_token in your config is not the whole story any more.
No object versioning and no object lock
Garage does not implement object versioning, and every object lock endpoint is unsupported. That means a bucket cannot be made immutable at the S3 layer, so an attacker holding your access key can delete objects and you have no previous versions to fall back to. If you want ransomware resistance on a Garage target, you need it somewhere else: a separate append-only replica, offline media, or a second cluster that pulls rather than being pushed to.
Layout changes are staged and must be applied by version
garage layout assign only stages a change. Nothing happens until garage layout apply --version N, where N is the next layout version number, and getting that number wrong is refused rather than guessed. New operators repeatedly assign capacity, see garage status unchanged, and conclude the cluster is broken. Applying a layout also starts a rebalance that moves real data between nodes, so do it deliberately and not while the cluster is already saturated.
replication_factor 3 on one node stores nothing
The default three-way replication needs three distinct nodes. Start a single-node Garage with the sample configuration and writes fail or the node reports itself unable to satisfy quorum, which reads like a bug. Single machines must set replication_factor = 1 explicitly, and you cannot casually change the factor later on a cluster holding data, so decide it before you upload anything.
Specifications#
- Category
- Backup and object storage
- Licence
- AGPL-3.0-only (Copyleft)
- Written in
- Rust
- First release
- 2020
- Maturity
- Stable
- Datastore
- LMDB for metadata (SQLite optional), content-addressed data blocks on disk
- Default ports
3900,3901,3902,3903- Ships as
- docker, static binary, nixos module
- arm64 builds
- Yes
- Identity
- Not applicable. No user accounts and no login UI. Access is S3 access keys scoped per bucket, plus separate admin API tokens introduced in 2.0.
- Replaces
- Amazon S3, Backblaze B2, Wasabi, DigitalOcean Spaces
- Project site
- garagehq.deuxfleurs.fr
- Source
- git.deuxfleurs.fr/Deuxfleurs/garage
- Documentation
- garagehq.deuxfleurs.fr/documentation/quick-start
Alternatives to Garage#
Everything else in backup and object storage, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Duplicati | 3, Moderate | 200 MB | MIT |
| BorgBackup | 2, Light | 80 MB | BSD-3-Clause |
| Kopia | 2, Light | 200 MB | Apache-2.0 |
| MinIO | 4, Heavy | 250 MB | AGPL-3.0 (repository archived) |
| rclone | 2, Light | 40 MB | MIT |
| restic | 2, Light | 100 MB | BSD-2-Clause |
Where Garage comes up elsewhere#
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.