RustFS: Distributed S3-Compatible Object Storage in Rust

What RustFS is

RustFS is a self-hosted, distributed object storage server written in Rust. It speaks the S3 API, so applications, SDKs and command-line tools that already talk to Amazon S3 or another S3-compatible store can point at a RustFS endpoint instead. The README describes the goal plainly: combine the operational simplicity of MinIO with the memory safety and performance characteristics of Rust, and ship it under the Apache 2.0 license rather than AGPL.

That licensing point is a large part of the project's pitch. Teams that want to embed object storage in a commercial product, or that have legal policies against AGPL software, have had fewer options since MinIO moved to AGPL v3. RustFS positions itself directly in that gap, and the README is explicit that it is aimed at data lakes, AI pipelines and big data workloads where large volumes of objects are written and read at high throughput.

The intended audience is platform and infrastructure engineers who run their own storage, whether on a handful of VMs, bare metal, Kubernetes or edge hardware, and who want an S3 endpoint they fully control.

How it works

RustFS runs as a single server binary (or container) that exposes two things: an S3-compatible API on port 9000 and a web console on port 9001 in the default Docker setup. Data lives on one or more drives, and the system can run in single-node mode or distributed mode across multiple nodes.

Storage is organised into pools made of drives grouped into erasure sets. Erasure coding spreads object data and parity across drives so the cluster can tolerate drive loss, and a background healing and scanner subsystem checks for bitrot and repairs damaged data. The README documents topology rules that mirror MinIO's: you grow a deployment by appending a new pool rather than changing the endpoints or erasure set width of an existing one, and every pool argument in ellipsis-based expansion must expand to at least two drive endpoints. A single-node single-drive deployment is treated as a standalone local path that cannot be expanded in place; moving to a multi-drive layout means creating a new deployment and migrating data through S3.

The README also notes that automatic parity selection differs from MinIO even though the topology rules follow it, and links to pool layout compatibility tests that should be read before expanding a cluster.

Beyond the S3 surface, RustFS includes an IAM and policy engine using AWS-style JSON policy documents, OIDC single sign-on (including mapping a roles claim from Microsoft Entra ID into policy conditions), a KMS layer for server-side encryption, and an event notification system that can deliver bucket events to webhooks.

Key features

The README tracks feature status with two labels: Available (shipped and covered by CI gates) and Preview (opt-in flag or bounded compatibility claim). Highlights include:

• S3 core API: upload, download, versioning, Object Lock (WORM), S3 Select and bucket quotas are marked available, with coverage tracked in a published S3 compatibility matrix.
• Distributed and single-node modes: both are available, with pool expansion and decommissioning supported.
• Data protection: bitrot protection plus a healing and scanner subsystem with documented runtime controls for pacing and CPU usage.
• Replication: both bucket replication and site replication are listed as available.
• Lifecycle management: ILM rules and ILM tiering to a remote S3 target.
• Encryption and KMS: server-side encryption backed by RustFS KMS, with Vault (KV2 / Transit) and AWS KMS as the production backends; the Local and Static backends are for development and testing only.
• Identity: IAM policies, multi-tenancy, OIDC / SSO and OpenStack Keystone authentication with X-Auth-Token headers.
• Other protocols: OpenStack Swift API and SFTP as opt-in cargo features (--features swift, --features sftp, or full); FTPS and WebDAV in the default build.
• S3 Tables (Preview): an Iceberg REST Catalog with automated PyIceberg and DuckDB coverage.
• MinIO on-disk compatibility (Preview): gated behind the rio-v2 feature and not in the default build.
• Operations: audit logging, event notifications, observability tooling, a web console and Kubernetes Helm charts.

Getting started

The README offers several install paths. The one-line installer:

curl -O https://rustfs.com/install_rustfs.sh && bash install_rustfs.sh

The Docker route. The container runs as a non-root rustfs user with UID/GID 10001:10001, so bind-mounted directories must be writable by that user:

# Create data and logs directories
mkdir -p data logs

# Change the owner of these directories
chown -R 10001:10001 data logs

# Using latest version
docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

With Docker Compose, using the file in the repository root:

docker compose -f docker-compose-simple.yml up -d

Nix users can run it straight from the flake:

# Run directly without installing
nix run github:rustfs/rustfs

The flake also exports a NixOS module and an S3-compatible client named rc. A Helm chart is available for Kubernetes, and a docker-buildx.sh script builds multi-architecture images for linux/amd64 and linux/arm64 from source.

Once running, the console is at http://localhost:9001. The default credentials are rustfsadmin / rustfsadmin, which should be changed before the instance is exposed anywhere. From there you can create buckets and upload objects through the console or any S3 client.

Use cases

• Self-hosted S3 for applications: give internal services an S3 endpoint for uploads, backups and static assets without depending on a public cloud.
• Data lake storage: store Parquet or Iceberg data behind an S3 API, with the preview S3 Tables catalog for PyIceberg and DuckDB workflows.
• AI and ML datasets: hold training data, checkpoints and model artifacts close to GPU infrastructure.
• Compliance-sensitive storage: Object Lock (WORM), audit logging, server-side encryption with Vault or AWS KMS, and the README's statement that RustFS has no telemetry.
• Edge deployments: the README highlights edge and IoT support as a design target, and single-node mode suits small footprints.
• OpenStack environments: native Swift API and Keystone authentication let RustFS slot into existing OpenStack identity setups.
• Event-driven pipelines: bucket event notifications to webhooks can trigger downstream processing when objects land.

How it compares

The obvious comparison, and the one the README makes itself, is MinIO. RustFS follows MinIO's pool and erasure set topology rules, offers a preview mode for reading MinIO's on-disk format, and frames its Apache 2.0 license as the main differentiator against MinIO's AGPL v3. The README notes that objects encrypted by MinIO are not readable by RustFS, so on-disk compatibility does not cover encrypted data. It also includes a performance comparison against MinIO on a small 2-core, 4 GB test machine with four 40 GB drives, presented as a video; treat that as the project's own benchmark rather than an independent result.

The README's comparison table against other object storage is written from the project's perspective (for example, contrasting Rust's memory safety with Go- or C-based systems). Other self-hosted S3-compatible stores such as Ceph RGW, SeaweedFS or Garage occupy the same category; which fits best depends on the S3 features you need, operational familiarity, and how much weight you put on licensing.

Things to know before adopting

• Check the compatibility matrix: S3 compatibility is described as broad for supported features, not complete. Verify the specific APIs your applications use against the published matrix.
• Plan topology up front: single-node single-drive deployments cannot be expanded in place, and existing pools should not have their endpoints or erasure set width changed.
• Some features are opt-in builds: Swift, SFTP and MinIO on-disk compatibility require cargo features that are not in the default build.
• Preview features: S3 Tables and MinIO on-disk compatibility carry bounded claims; test before relying on them.
• Container permissions: bind mounts must be owned by UID/GID 10001, including TLS certificate directories.
• Outbound connections: since 1.0.0-beta.11, webhook endpoints on private or container networks are blocked unless their exact origin is listed in RUSTFS_OUTBOUND_ALLOW_ORIGINS.
• Default credentials: change rustfsadmin / rustfsadmin immediately.
• Trademark: RustFS is a trademark of RustFS, Inc., which also provides a business contact, so there is a company behind the project.

Project activity

As of October 2026 the repository has roughly 34,300 stars on GitHub. It was created in November 2023, is written in Rust, and is licensed under Apache-2.0. CI and Docker image builds run on GitHub Actions, and the README links a changelog through GitHub Releases, GitHub Discussions and a Discord server for support. The source is at github.com/rustfs/rustfs, documentation lives at docs.rustfs.com, and downloads are available from rustfs.com.