Cloud Parts

Garage

A lightweight S3 object store that keeps copies of your data in several sites linked by ordinary Internet connections.

What it is
Object storage
Type
Open source
Made by
Deuxfleurs (French non-profit)
License
AGPLv3
Facts checked
5 October 2026
Website Source code

What it is

Garage is a single Rust binary that runs on every node. It keeps full copies instead of erasure coding: each object is cut into blocks (1 MiB by default), and each block, named by its hash, is stored on as many nodes as the replication factor says, usually three. The cluster layout tells Garage how much capacity each node has and which zone (a site such as a house, an office or a data centre) it sits in, and Garage puts the copies of every block in different zones. Because blocks are addressed by their hash, identical blocks are stored once, and they can be compressed with zstd.

Metadata (buckets, access keys, object lists) lives in tables that each responsible node keeps in a local LMDB or SQLite database. The tables are CRDTs, data types that merge without conflicts, so Garage has no Raft leader: a request succeeds once a quorum of the nodes holding that item answers (two out of three), and nodes reconcile in the background. That keeps it usable over slow links between sites. Besides the S3 API, Garage can serve buckets as static websites, and an admin API and the garage CLI manage nodes, buckets and keys. Access is granted per key and per bucket (read, write, owner) instead of through S3 policies.

Why teams pick it

  • Made for geo-distribution: copies land in different zones, and the stated network requirement is only 200 ms or less latency and 50 Mbps or more
  • Light: one dependency-free binary that runs with 1 GB of RAM on any recent x86_64 or ARM machine, and one cluster can mix whatever hardware you have
  • Easy to grow or shrink: change the layout and Garage moves copies itself to keep the replication factor
  • Serves static websites straight from buckets, and bucket aliases let you rename a bucket without copying it
  • Community-run, stable since v1.0 (2024), with development paid for by European NGI grants through NLnet

Watch out for

  • Much of the S3 API is missing: no versioning, Object Lock, bucket replication, bucket notifications or object tagging, and lifecycle rules support only expiry and cleaning up unfinished uploads
  • No S3 bucket policies or ACLs: you grant each key read, write or owner rights on each bucket with Garage’s own CLI or admin API
  • No server-side encryption except SSE-C; the docs suggest encrypting disks or encrypting on the client
  • Full copies cost more disk than erasure coding: three replicas need three times the raw space, and high performance and feature breadth are stated non-goals
  • AGPLv3, like MinIO’s community edition: if you modify it and offer it over a network, you must publish your changes

Alternatives

What all object storage have in common →
Amazon S3AWSAWS’s object storage, and the de facto API most object stores copy.Apache OpenDALOpen sourceA Rust library, with bindings for Python, Java, Node.js, Go and more, that gives one API (read, write, stat, list, delete) over 50-plus storage backends: S3 and other object stores, local and HDFS file systems, Google Drive and Dropbox, and key-value stores.Apache OzoneOpen sourceA Hadoop-born object store that serves the same buckets over S3 and as a Hadoop file system.Azure Blob StorageAzureAzure’s object storage, with three blob types and an optional real directory tree for analytics.Backblaze B2 Cloud StorageCommercialLow-cost object storage on Backblaze’s own hardware, with its own API and an S3-compatible one.CephOpen sourceA distributed storage cluster that serves S3 buckets, block devices and a file system from the same pool of disks.Cloudflare R2CommercialS3-compatible object storage from Cloudflare that charges nothing for data going out.Google Cloud StorageGoogle CloudGoogle Cloud’s object storage, where even the archive class answers in milliseconds.MinIOArchivedOpen sourceA self-hosted object store that speaks the S3 API. The open-source edition is archived and its images are gone from Docker Hub; MinIO now sells AIStor.PGSTY SiloOpen sourceA community-maintained fork of the open-source MinIO server, with builds, images, security fixes and the full web console.RustFSOpen sourceA young Rust reimplementation of MinIO’s design: S3-compatible, erasure-coded, Apache 2.0, and generally available since September 2026.SeaweedFSOpen sourceA distributed blob store with an S3 gateway and a file system layer, built to store and serve billions of small files.TigrisCommercialGlobally distributed S3-compatible object storage that moves data to where it’s read, with no egress fees.Versity S3 GatewayOpen sourceA stateless S3 server that exposes an existing file system, or another object store, through the S3 API.Wasabi Hot Cloud StorageCommercialS3-compatible object storage sold at one flat price per TB, with no egress or request fees.Zenko CloudServerOpen sourceScality’s open-source Node.js S3 server: a light S3 endpoint for development and tests, and a front end that can store objects in other clouds.

How it fits with other technologies

Run a single Garage node in Docker, create a bucket and key, then use the aws CLI · bash

cat > garage.toml <<EOF
metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "lmdb"
replication_factor = 1   # use 3 once you have nodes in three zones
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "127.0.0.1:3901"
rpc_secret = "$(openssl rand -hex 32)"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
EOF

docker run -d --name garage -p 3900:3900 -p 3901:3901 \
  -v "$PWD/garage.toml:/etc/garage.toml" \
  -v garage-meta:/var/lib/garage/meta -v garage-data:/var/lib/garage/data \
  dxflrs/garage:v2.4.1
alias garage="docker exec garage /garage"

garage status                                  # shows the node ID
garage layout assign -z home -c 1T 563e        # zone and capacity for that node
garage layout apply --version 1

garage bucket create backups
garage key create backups-app                  # prints the key ID and secret
garage bucket allow --read --write backups --key backups-app

export AWS_ACCESS_KEY_ID=GK... AWS_SECRET_ACCESS_KEY=... AWS_DEFAULT_REGION=garage
aws s3 cp --recursive ./exports/ s3://backups/2026-10-05/ --endpoint-url http://localhost:3900

Moving from MinIO#

Garage fits MinIO users who used buckets as plain storage: app media (Nextcloud, Matrix, Mastodon, PeerTube), backups with restic or rclone, static sites and build caches. Check the S3 compatibility page before you move anything that depends on versioning, Object Lock retention, bucket policies, notifications or replication rules: Garage returns 501 Not Implemented for endpoints it lacks. The durability model also differs: MinIO erasure-codes across the drives of one site, while Garage keeps whole copies in different zones, so size your disks for the replication factor.

To copy data, create a key and buckets in Garage, then run rclone sync minio:bucket garage:bucket with Garage set up as an S3 remote with provider = Other, force_path_style = true and the region from garage.toml, as the Garage docs show. The MinIO client mc also works with Garage if you still have it. Repeat the sync just before switching endpoints, and recreate access keys as Garage keys, since MinIO users and policies have no Garage equivalent.

See it in a real stack

No architecture uses Garage yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2025

Garage comes from Deuxfleurs, a French non-profit that runs services for its members on machines kept in members’ homes rather than in data centres. Homes lose power and Internet connections, so Deuxfleurs wanted storage that keeps working when one site goes dark. The existing options didn’t fit: MinIO had no notion of sites and was sensitive to latency, Ceph was too heavy for a few small machines, and OpenStack Swift needed around 8 GB of RAM just to start.

Alex Auvolat made the first commit in April 2020, and version 0.1 followed that July. The design borrowed from research: Amazon’s Dynamo for spreading data over nodes, and CRDTs for metadata that merges without a leader. European Next Generation Internet (NGI) money paid for three full-time developers in 2021 and 2022, then further work through NLnet’s NGI0 Entrust (2023 to 2024) and NGI0 Commons funds (2025).

Garage 1.0 came out in April 2024 and 2.0, with a reworked admin API, in June 2025. Deuxfleurs runs it on nine nodes in three locations, and other small hosts such as Triplebit use it for Mastodon, PeerTube and Matrix media.

Why it’s built this way

Whole copies instead of erasure coding
The design goals call erasure coding a non-goal because it makes placing and synchronising data harder. Plain copies keep the system simple, and any zone can serve a complete object on its own.
CRDTs and quorums instead of Raft
Without a leader to go through, a request only needs answers from the nodes holding its data, so slow home Internet links between sites don’t stall the whole cluster.
Zones as a first-class idea
The layout records which site each node is in, and Garage places each block’s copies in different zones, so one house or data centre can go offline without losing data.
Speak S3 and nothing more
Feature breadth is an explicit non-goal. Implementing S3 lets Garage back Nextcloud, Matrix, Mastodon, PeerTube, restic and rclone without custom clients.

Timeline

  1. 2020

    First commit in April; version 0.1 in July

  2. 2021

    NGI POINTER grant funds three full-time developers for a year

  3. 2022

    Public introduction on the Garage blog and a FOSDEM talk (February)

  4. 2023

    NLnet’s NGI0 Entrust fund pays for a developer for a year

  5. 2024

    Garage 1.0 released (April)

  6. 2025

    Garage 2.0 with a new admin API (June); NGI0 Commons Fund grant

Sources14 · facts checked 5 October 2026

Improve this page on GitHub