RustFS: an Apache-2.0 S3-compatible object store in Rust, tested against MinIO on 4KB objects

What RustFS replaces, and who is actually in the market for it

RustFS targets the same slot as MinIO and Ceph: an S3-compatible endpoint you put behind applications that already speak the S3 API. The README frames the project as combining "the simplicity of MinIO with the memory safety and raw performance of Rust," and it names data lakes, AI, and big data workloads as the intended use. The distinguishing claim is licensing. RustFS is Apache-2.0, and the README contrasts that directly with AGPL v3, describing the latter as carrying "license traps and intellectual property pollution." For a company that wants to embed an object store inside a product without publishing source, that difference is the whole argument.

Who is this for, concretely? Teams already running MinIO or Ceph who want a drop-in S3 endpoint, and teams whose legal review rejected AGPL. The README also lists OpenStack Swift API support and Keystone authentication with X-Auth-Token headers, which points at private-cloud operators rather than pure AWS-style deployments. If you do not already have S3 clients and you are not constrained by licence, the case is weaker: you are adopting a release candidate to solve a problem you may not have.

How the storage layer is put together

The Cargo workspace is the clearest map of the architecture. It splits into a core `rustfs` crate described as the "Core file system implementation," plus `crates/ecstore` for erasure coding storage, `crates/filemeta` for file metadata, `crates/heal` for erasure set and object healing, `crates/lock` for distributed locking, `crates/iam` for identity and access management, and `crates/kms` for key management. There is also `crates/keystone` for the OpenStack integration and `crates/audit` for multi-target audit fan-out.

That layout tells you the data path: objects are written through the core crate, erasure coded in `ecstore`, described by metadata in `filemeta`, and repaired by `heal` when a set or object needs reconstruction. Distributed coordination sits in `lock`, not in the storage crates, which is a common split but also means correctness under partition depends on that crate behaving. The README's feature table marks bitrot protection, versioning, bucket replication, event notifications, multi-tenancy, and Keystone auth as available, while lifecycle management, distributed mode, RustFS KMS, and Swift metadata operations are marked as under testing or partial. Read that table as the real scope boundary, not the feature list above it.

Installing RustFS with Docker Compose and making a first request

The repository ships `docker-compose.yml` at the top level, and the README points to https://docs.rustfs.com/en/installation for getting started. The compose file defines a single `rustfs` service built from `Dockerfile.source`, exposing port 9000 for the S3 API and 9001 for the console.

The environment block is where the deployment is actually configured. Note that the access and secret keys default to `rustfsadmin`, and the compose file itself warns that "these defaults are public and well-known" and should be overridden before exposing the listener beyond localhost. The volume list uses brace expansion to define four storage paths.

services:
  rustfs:
    image: rustfs/rustfs:latest
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      - RUSTFS_VOLUMES=/data/rustfs{0..3}
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=${RUSTFS_ACCESS_KEY:-rustfsadmin}
      - RUSTFS_SECRET_KEY=${RUSTFS_SECRET_KEY:-rustfsadmin}

Start it with the standard compose command, then point any S3 client at the endpoint. The README does not document a RustFS-specific CLI for creating buckets, so the S3 API on port 9000 is the interface to use.

docker compose up -d

After the container is up, the console should be reachable on port 9001 because `RUSTFS_CONSOLE_ENABLE` is set to true. The compose file also sets `RUSTFS_TLS_PATH=/opt/tls` and `RUSTFS_OBS_ENDPOINT=http://otel-collector:4318`, which means the default configuration expects a TLS directory and an OpenTelemetry collector to exist. Neither is created for you, so a bare `docker compose up` will leave those paths empty.

The release candidate problem, and where the README goes quiet

The most recent releases are 1.0.0-rc.4, 1.0.0-rc.3, and 1.0.0-rc.2-preview.1. The last push to the repository was on 2026-08-28, and the newest tag is an rc. Whatever the performance claims, you are being asked to evaluate software that has not shipped a stable 1.0.

The feature table reinforces that. Distributed mode is marked "Under Testing," as are lifecycle management and RustFS KMS. The README's own feature list calls the distributed architecture "scalable and fault-tolerant design suitable for large-scale deployments," while the status table one screen later says distributed mode is not yet confirmed. Those two statements cannot both be load-bearing. If your plan is a multi-node cluster, the documentation does not currently support it.

The README is also silent on several things an operator needs. There is no documented rollback procedure, no upgrade path between release candidates, and no stated data format compatibility guarantee across versions. The compose file references `Dockerfile.decommission-local` and `docker-compose.decommission.yml`, which suggests a decommission workflow exists, but the README does not explain it. Treat the docs/ directory and the compatibility matrix as the authoritative source, not the marketing table.

RustFS versus MinIO, Ceph, and Garage: the real differences

Against MinIO, the difference is licence and language, not API surface. Both present an S3 endpoint. MinIO is AGPL v3, which triggers source-disclosure obligations for network services in many readings; RustFS is Apache-2.0, which does not. The README's comparison table also claims RustFS avoids "memory GC pauses or leaks" because it is not Go-based. That is an architectural argument, not a measured one, and the README's only published benchmark environment is a 2-core, 4GB, 15Gbps machine with four 40GB drives. The 2.3x figure for 4KB payloads comes from that setup, and the README does not publish the MinIO version, the configuration, or the raw results.

Against Ceph, the difference is scope. Ceph provides block, file, and object storage with a long operational history; RustFS provides object storage only. If you need RBD or CephFS, RustFS is not a substitute.

Garage is the closer comparison in spirit: a Rust object store with an S3 gateway and a smaller operational surface. The distinction is that Garage is designed around geo-distributed clusters on heterogeneous hardware, while RustFS's README emphasises S3 API breadth, an OpenStack Swift and Keystone story, and a management console. If your requirement is a multi-region cluster on mixed disks, Garage's design brief matches that problem more directly. If your requirement is an S3 endpoint with OpenStack integration and a permissive licence, RustFS is aimed at you.

Licence, maintenance, and what an upgrade actually costs

The licence is Apache-2.0, stated in the README and present as a LICENSE file at the repository root. There is also a CLA.md, which means contributions require a contributor licence agreement. For adopters, Apache-2.0 removes the network-service disclosure question that AGPL raises, but it does not remove the CLA question if you intend to contribute back. None of this is legal advice; if the licence choice is the reason you are evaluating RustFS, have counsel read the LICENSE and CLA files rather than the comparison table.

On maintenance, the last push was 2026-08-28 and the newest release is a release candidate. That is recent activity, but the release cadence is rc-to-rc, and the README does not describe a support window, a long-term release branch, or a deprecation policy. Upgrading between candidates means reading CHANGELOG.md yourself, because no upgrade guide is referenced. The repository does carry a `crates/e2e_test` suite and a `fuzz/` directory, which is a better signal of engineering practice than any benchmark table, but neither tells you what happens to on-disk data when you move from rc.3 to rc.4.

Editorial conclusion

RustFS is worth a single-node evaluation if you want an Apache-2.0 S3 endpoint and you are willing to run a release candidate. Teams that need distributed mode, KMS, or lifecycle rules in production should wait, because the README marks those as under testing. Before adopting it, read docs/architecture/s3-compatibility-matrix.md and confirm the exact operations your client calls, then check whether the release you pin is tagged rc or preview.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes