Garage

Garage is an open-source, S3-compatible distributed object storage system designed specifically for self-hosted deployments that span multiple physical locations. Unlike enterprise storage solutions that demand high-bandwidth private networks and uniform hardware, Garage is engineered to work over ordinary internet connections with consumer-grade equipment — making resilient, redundant storage accessible to individuals, small organizations, and privacy-focused hosters.

Built in Rust and distributed as a single static binary, Garage requires no external dependencies or complex orchestration to run. It implements a Dynamo-style consistent hashing ring combined with CRDTs to achieve eventual consistency without any consensus bottleneck like RAFT — which means all storage nodes can handle requests independently, even when inter-node latency is high. This design makes Garage particularly suited for multi-datacenter or home-lab deployments where nodes may be geographically distant.

Garage supports S3-compatible object storage, a unique Key-to-Value (K2V) API for small-item workloads, and direct static website serving from buckets. All stored data is chunked, deduplicated at the block level, and optionally compressed with Zstd. The cluster layout is managed through a versioned CRDT-based system, allowing topology changes to be staged and applied with full audit history.

In production at Deuxfleurs, Triplebit, and other organizations, Garage has proven reliable for use cases ranging from Matrix media backends and Mastodon attachment storage to Nix binary caches and PowerDNS zone backends — all using standard S3-compatible tooling with no client modifications.

What You Get

• S3 API Compatibility - Implements the Amazon S3 REST API including multipart uploads, presigned URLs, bucket policies, CORS, and versioning, so existing tools like rclone, restic, and MinIO clients work without modification.
• Geo-Distributed Replication - Automatically replicates data chunks across configurable zones (physical locations), ensuring objects remain available even when entire datacenters lose connectivity or power.
• Single Static Binary - Ships as a self-contained binary with no external runtime dependencies, running on x86_64, ARMv7, and ARMv8 Linux systems with as little as 1 GB RAM and 16 GB disk.
• No-RAFT Consistency - Uses a Dynamo-style consistent hashing ring combined with CRDTs for eventual consistency — allowing all nodes to serve requests simultaneously without a leader bottleneck, even over high-latency internet links.
• Block-Level Deduplication and Compression - Objects are chunked into fixed-size blocks that are content-addressed, deduplicated across all uploads, and optionally compressed with Zstd before storage.
• Static Website Hosting - Any bucket can be configured as a static website served directly by Garage, with domain names mapping to bucket names — a feature absent from most open-source S3-compatible alternatives.
• K2V API for Small Items - Provides an optional Key-to-Value API alongside S3 for efficient storage of small structured items with vector-clock-based causality tracking, suitable for metadata-heavy workloads.
• Pluggable Storage Backends - Supports LMDB, SQLite, and Fjall as embedded storage engines for metadata, selectable at compile time to match hardware and workload characteristics.
• Prometheus Metrics and OpenTelemetry Tracing - Exposes operational metrics in Prometheus format and supports distributed tracing via OpenTelemetry, enabling full observability of cluster health.
• Versioned Cluster Layout - Cluster topology is managed through a CRDT-based staging system that records the full history of layout changes, enabling safe incremental topology updates with audit trails.

Common Use Cases

• Self-hosted media backend for federated services - An organization runs Mastodon, Matrix, or PeerTube across multiple servers and uses Garage as the S3 media backend, with data replicated across three physical sites for resilience.
• Distributed backup target - A sysadmin configures rclone or restic to write backups to a Garage cluster spanning home servers in different cities, ensuring backups survive any single site failure.
• Static website and asset hosting - A developer hosts static websites and frontend assets directly from Garage buckets, leveraging S3 compatibility for CDN integration and Garage’s built-in web server for direct delivery.
• Nix binary cache - A team maintains a private Nix binary cache on a Garage cluster, serving derivations to build machines across different datacenters using standard S3 cache configuration.
• Privacy-first S3 replacement - A privacy-focused organization replaces AWS S3 or Google Cloud Storage with a self-hosted Garage cluster to eliminate third-party data exposure while keeping full compatibility with existing application code.
• PowerDNS authoritative zone backend - An ISP uses Garage with Lightning Stream to replicate PowerDNS LMDB zone data across geographically distributed authoritative DNS servers.

Under The Hood

Architecture Garage is structured as a multi-crate Rust workspace with strict layered dependencies: a networking foundation in garage_net feeds an RPC layer in garage_rpc, which supports a distributed table engine in garage_table, on top of which domain models and API servers are built. The central Arc<Garage> struct provides dependency injection throughout, giving every subsystem consistent access to configuration, storage, and the cluster layout. Consistency is achieved without RAFT: instead, a Dynamo-style consistent hashing ring assigns partitions to nodes, and CRDTs handle concurrent updates to cluster metadata. A Merkle tree per partition enables efficient anti-entropy synchronization between nodes, letting Garage detect and repair divergence without full scans.

Tech Stack Garage is written in Rust using Tokio for async I/O and Hyper for HTTP. Three embedded storage backends are supported for metadata: LMDB via the heed crate, SQLite via rusqlite with r2d2 connection pooling, and the Fjall LSM-tree engine — each selectable at compile time. RPC between nodes uses MessagePack serialization via rmp-serde, with cryptographic authentication via libsodium (kuska-sodiumoxide). Observability is built in via OpenTelemetry and Prometheus. Optional Kubernetes service discovery is provided through the kube-rs client. Zstd compression is applied to stored blocks via the async-compression crate.

Code Quality Garage has an extensive test suite of over 70 unit test functions spread across 30 test modules covering data structures, CRDT logic, S3 XML serialization, encryption, and database adapters. Integration testing is handled through shell scripts in script/ that spin up multi-node dev clusters and exercise the full S3 API against real AWS SDK clients. Rustfmt and Clippy are configured at the workspace level with pedantic lints enabled. Thiserror is used for typed error enums throughout. However, unwrap calls remain widespread across production code paths — a known risk in a storage system — and the project explicitly restricts AI-assisted contributions to preserve human understanding of the codebase.

What Makes It Unique Garage’s most distinctive property is achieving geo-distributed object storage without any consensus protocol: requests proceed independently on every node, and the Dynamo-style ring combined with quorum reads ensures consistency without a leader bottleneck. This directly enables operation over commodity internet links with hundreds of milliseconds of inter-node latency — a scenario where RAFT-based systems degrade severely. The optional K2V API is a purpose-built small-item store with vector-clock causality tracking, unique among S3-compatible OSS solutions. Static website serving from buckets — absent in Minio and Ceph — is fully implemented. Block-level deduplication ensures that identical file content, even across different objects and users, is stored only once on disk.

Self-Hosting

Garage is released under the GNU Affero General Public License v3.0 (AGPLv3). This means you are free to run, study, modify, and redistribute Garage without paying any licensing fees. The key practical implication of the AGPL is the network copyleft clause: if you modify Garage and make it available to users over a network, you must make the modified source code available under the same license. For most self-hosters running Garage for internal use — backups, media storage, static websites — this clause does not apply. Organizations building a commercial storage service on top of Garage, however, need to be aware of this requirement. There is no commercial license exception available from the developers.

Running Garage yourself requires deploying and managing a cluster of at least three nodes in distinct physical zones for full geo-redundancy. Each node needs a Linux machine (physical or virtual) with at least 1 GB RAM, 16 GB disk, and a stable internet connection with around 50 Mbps bandwidth. You are responsible for provisioning storage, ensuring network connectivity between sites, managing TLS (if desired, via a reverse proxy), and handling upgrades — Garage’s docs cover rolling upgrades but the process is manual. Backup of the embedded metadata database (LMDB/SQLite/Fjall) is your responsibility, though Garage’s replication means data loss requires simultaneous failures across the majority of your replication zones. Operational burden is modest for a static cluster but grows with frequent topology changes.

Garage has no hosted cloud tier or commercial managed offering from the developers. This is intentional — the project is built specifically to avoid dependence on any commercial service. Compared to AWS S3 or Google Cloud Storage, you give up automatic scaling, managed SLAs, 24/7 vendor support, built-in CDN integration, and the breadth of AWS ecosystem integrations. Community support is available through the Matrix channel #garage:deuxfleurs.fr and the public issue tracker. Organizations needing deeper support can contact the developers via email, though no SLA is guaranteed. If your primary concern is operational simplicity over data sovereignty, a managed S3-compatible service will have lower overhead.