DEV Community

Cover image for Garage vs RustFS: Running S3 on a Single Node
Ethan Carter
Ethan Carter

Posted on

Garage vs RustFS: Running S3 on a Single Node

#garage #rustfs #s3 #objectstorage

Garage vs RustFS: Running S3 on a Single Node

Garage and RustFS are both Rust-written, single-binary S3-compatible stores you can run on one node. The decisive split is the license and the S3 feature set: Garage is AGPL-3.0 and skips versioning, Object Lock, and server-side encryption; RustFS is Apache 2.0 and ships all of them. Run Garage when you want a tiny, geo-distributed store on secondhand hardware and AGPL is fine; run RustFS when your app needs versioning, immutability, IAM, and a MinIO-compatible dialect on the simplest possible operational surface.

Key stats

Garage RustFS
License AGPL-3.0 (network copyleft) Apache 2.0 (permissive)
Implementation Rust Rust
Single-node start garage server --single-node one docker run
S3 object versioning ❌ Missing ✅ Available
Object Lock (WORM) ❌ Missing ✅ Available
Server-side encryption ❌ Missing ✅ Available
Bucket / site replication (S3 API) ❌ Missing ✅ Available
ACL / bucket policies ❌ (own permission model) ✅ (IAM / Policies)
Default S3 API port 3900 9000
Documented minimum RAM 1 GB not published

Garage's "missing" rows are not bugs — they are its own S3-compatibility page stating the feature is not implemented. RustFS rows are its README Feature & Status table (re-checked 2026-09-21). We cite the docs, not benchmarks.

What is the real difference between Garage and RustFS?

Garage is an S3-compatible distributed object store designed for self-hosting at a small-to-medium scale, built by the French non-profit Deuxfleurs. Its own docs describe it as a service that "replicates data 3x over distant servers" and is "not as latency sensitive" because it avoids consensus algorithms like Paxos or Raft. You run one garage binary per node, point nodes at each other, and assign a cluster layout. The design center is geo-distributed clusters of cheap, mismatched machines across physical locations.

RustFS is narrower by design: a purpose-built, MinIO-compatible S3 object store written in Rust under the Apache 2.0 license. Its README Feature & Status table marks S3 Core, Versioning, Object Lock (WORM), Lifecycle Management, Bucket and Site Replication, IAM/Policies, Server-Side Encryption, and Distributed Mode as available, with S3 Tables (Iceberg REST) and MinIO On-Disk Compatibility in preview. There is no POSIX layer and no FUSE mount. Both are single Rust binaries, but Garage optimizes for resilient distribution across locations; RustFS optimizes for S3 correctness and the smallest operational surface.

How do the licenses actually differ?

Garage's source code is released under the AGPL v3 license. The project states it plainly: "if you patch Garage and then use it to provide any service over a network, you must share your code." That is network copyleft — stronger than the ordinary GPL. If you modify Garage and expose it as a service, you must publish your modified source. For a homelab or an internal-only deployment that never serves third parties, AGPL is usually a non-event. The moment you ship a modified Garage as a product or a hosted service, the obligation attaches.

RustFS is released under the permissive Apache 2.0 license. The README notes it is "released under the permissible Apache 2.0 license," with no copyleft. You can run, modify, and embed it in a closed-source product or a commercial service without a source-disclosure obligation. For most companies evaluating storage, this is the practical differentiator: RustFS imposes no network-copyleft tax, while Garage's AGPL-3.0 does. If license friction is a concern, that single line settles the comparison before any feature table does.

What S3 features does Garage leave out?

Garage implements a deliberate subset of the S3 API, and its own compatibility page lists what is missing. Bucket versioning is "Missing." Object Lock — both legal hold and retention — is "Missing" across every lock endpoint. Server-side encryption (PutBucketEncryption and friends) is "Missing"; the project's stance is that you should encrypt at the partition or client side instead. Bucket replication via the S3 API is "Missing." ACLs and bucket policies are "Missing" — Garage has its own per-access-key, per-bucket permission model rather than AWS's ACL-or-policy system.

Lifecycle is only partially implemented: Garage supports AbortIncompleteMultipartUpload and Expiration and nothing that depends on versioning or storage classes. Multipart upload, presigned URLs, CORS, and static-website hosting are implemented. The honest read: Garage is a clean S3-compatible put/get store with replication built in at the cluster level, not a drop-in for apps that assume versioning, WORM immutability, SSE, or IAM policies. If your client needs those, test first or look at RustFS, which lists every one of them as available.

How does each one run on a single node?

Garage's documented single-node path is one command after you generate a config. The quick start generates a garage.toml (metadata_dir, data_dir, replication_factor = 1, ports 3901/3900/3902/3903) and then starts the server:

garage server --single-node --default-bucket
Enter fullscreen mode Exit fullscreen mode

That flag auto-configures a single-node cluster with no replication and creates a default access key and bucket from environment variables. For Docker, the official quick start pins dxflrs/garage:v2.3.0 (newer stable releases exist) and maps the four ports:

docker run \
  -d \
  --name garage-container \
  -p 3900:3900 -p 3901:3901 -p 3902:3902 -p 3903:3903 \
  -v $(pwd)/garage.toml:/etc/garage.toml \
  -e GARAGE_DEFAULT_ACCESS_KEY \
  -e GARAGE_DEFAULT_SECRET_KEY \
  -e GARAGE_DEFAULT_BUCKET \
  dxflrs/garage:v2.3.0 \
  /garage server --single-node --default-bucket
Enter fullscreen mode Exit fullscreen mode

RustFS starts with one docker run (verbatim from its README):

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest
Enter fullscreen mode Exit fullscreen mode

That serves the S3 API on 9000 and a console on 9001. Default credentials are rustfsadmin / rustfsadmin, which you must rotate before any real exposure. RustFS also ships a single binary you can drop on a host.

When should you pick Garage over RustFS?

Pick Garage when the requirement is resilient storage across locations on hardware you already own, and you are comfortable with AGPL-3.0. Its sweet spot is exactly what Deuxfleurs built it for: a few nodes in two or three physical locations replicating data so it stays available through failures and high-latency links. The operational surface is small — one binary, a TOML file, a layout command — and the memory footprint is tiny (the project cites 1 GB RAM and 16 GB disk as minimums). For homelab backups, media, or app assets, self-hosting wins on price the moment the hardware is sunk cost.

Garage also wins if you specifically want its model: CRDT-based federation instead of Raft/Paxos, so it tolerates slow or flaky inter-node links that would stall a consensus-based cluster. If your app only needs put/get/list plus presigned URLs and a static-site endpoint, Garage is lighter than running a full S3 engine. The catch is the missing feature set above — if your app leans on versioning, Object Lock, or IAM, Garage is the wrong tool and you should not try to bolt those on.

Where does RustFS win?

RustFS wins on the axis most S3 teams actually care about: a complete, MinIO-compatible S3 endpoint with the least operational surface. One docker run, no cluster-layout choreography, a web console on 9001. The feature set is broad and marked available in the README — Object Lock (WORM), Lifecycle Management, Bucket and Site Replication, IAM/Policies, Server-Side Encryption, and Distributed Mode are all shipped and covered by CI gates. If your tools already speak MinIO's S3 dialect, RustFS lists MinIO On-Disk Compatibility as a preview feature and targets that dialect as its primary surface.

The Apache 2.0 license is the other win: no network-copyleft obligation, so you can wrap RustFS in a product or a hosted service without source-disclosure strings. For a team whose only contract with storage is the S3 API and whose app assumes versioning, immutability, or IAM policies, RustFS is the closer fit and the shorter path to a working, compliant endpoint. RustFS is younger as an ecosystem, and S3 Tables (Iceberg) plus MinIO on-disk compatibility are still preview — own that if a lakehouse or byte-exact MinIO migration is the requirement.

Feature-by-feature: what the docs say

The table below is a straight read of each project's own documentation as of September 2026. Garage rows come from garagehq.deuxfleurs.fr (quick start and the S3-compatibility page); RustFS rows come from its README Feature & Status table (re-checked 2026-09-21). No benchmarks, no marketing.

Capability Garage RustFS
S3-compatible API ✅ (subset) ✅ (S3 Core)
Object versioning ❌ Missing ✅ Available
Object Lock (WORM) ❌ Missing ✅ Available
Server-side encryption ❌ Missing ✅ Available
Bucket / site replication (S3 API) ❌ Missing ✅ Available
Lifecycle (ILM) ⚠️ Partial (Abort MPU + Expiration) ✅ Available
ACL / bucket policies ❌ (own model) ✅ (IAM / Policies)
Web console / admin API ✅ (admin API) ✅ (Web Console)
Geo-distribution model CRDT federation, no Raft/Paxos Distributed Mode (✅ Available)
Single binary ✅ (garage) ✅
License AGPL-3.0 Apache 2.0
Implementation Rust Rust

Two rows deserve a call-out. RustFS lists S3 Tables (Iceberg REST) as preview, so a mature lakehouse over RustFS data is not a promise the project makes yet. And Garage's missing versioning, Object Lock, SSE, and ACL rows are by design — its strength is resilient distribution, not S3-feature parity.

How do you choose between them?

Use this rule of thumb: if the ticket says "backups across sites on hardware we own, AGPL is fine," start with Garage. If the ticket says "S3 endpoint for an app that needs versioning, immutability, or IAM, and we don't want copyleft," start with RustFS.

A split is legitimate and common. Run Garage for the geo-distributed, secondhand-hardware layer where its CRDT model and tiny footprint pay off, and run RustFS in front of the S3-facing applications where versioning, Object Lock, and a MinIO-compatible dialect are the whole ask. They do not conflict; they occupy different layers. The mistake is forcing one to do the other's job — Garage dragged into an app that assumes Object Lock becomes a missing-feature ticket, and RustFS pushed into a no-copyleft-averse, flaky-link geo cluster carries obligations it was not built to carry.

FAQ

Is Garage a drop-in MinIO replacement?

No. Garage implements a subset of the S3 API — its own compatibility page lists versioning, Object Lock, replication, SSE, and ACL/policy as missing — so most S3 clients work for put/get/list but apps that assume MinIO's full feature set will break. RustFS targets the MinIO S3 dialect as its primary surface and lists MinIO On-Disk Compatibility as a preview feature. If a MinIO-compatible endpoint is the requirement, RustFS is the closer fit.

Does Garage support object versioning?

No. Garage's S3-compatibility page marks bucket versioning as "Missing" and notes it "does not (yet) support object versioning." GetBucketVersioning returns a stub that always reports versioning disabled. If your workload needs versioned objects or point-in-time recovery through S3, Garage cannot provide it today; RustFS lists Versioning as available.

Is RustFS Apache 2.0 like Garage is AGPL?

No. RustFS is released under the permissive Apache 2.0 license with no copyleft, while Garage is AGPL-3.0. The practical difference: if you modify Garage and expose it as a network service, you must publish your modified source; RustFS imposes no such obligation. For a hosted or embedded product, that single license line is often the deciding factor.

Can Garage run on a single node?

Yes. Garage's quick start runs a single node with garage server --single-node --default-bucket, which auto-configures a no-replication cluster and creates a default key and bucket. The docs warn this provides no data redundancy and "should not be used in production." Garage is designed for three nodes across zones; single-node is for evaluation and dev, not for durable storage.

Which one should I run for a homelab backup?

If your backup needs versioning, immutability (Object Lock), or IAM-scoped keys, run RustFS — it ships all three and is Apache 2.0. If you want geo-distributed copies across secondhand machines, accept AGPL-3.0, and only need put/get plus presigned URLs, Garage is lighter and built exactly for that. Match the missing-feature list to your client before committing.

Sources

Top comments (0)