RustFS: Apache 2.0 over AGPL, a status table that grades itself, and a MinIO flag that is off by default

The three newest releases are 1.0.1 previews, three days apart

Look at the release list before anything else. The three most recent releases are 1.0.4 published on 2026-10-25, 1.0.3 on 2026-10-17 and 1.0.2 on 2026-10-16. Three releases in under ten days.

The last push to the repository was 2026-10-31, so this is current work rather than a stalled project. The release cadence is the thing to plan around.

For an evaluation that is fine, and the project publishes a stress test and a feature matrix to support one. For a production dependency it means your upgrade policy has to be built around frequent releases, and what changed between them is not something the tag tells you. Read the changelog in the repository.

The feature table grades itself, and two rows are still on preview

The status table comes with a legend, and the legend is the most useful thing in the README. A check mark means available, shipped and covered by CI gates. A flask means preview, shipped behind an opt-in flag or with a bounded compatibility claim.

That is an unusual thing for a project to publish about itself, and it changes how you should read everything around it. The twenty-nine rows marked available include the S3 core features, upload and download, versioning, object lock for WORM, server-side encryption, the KMS, lifecycle management, S3 Select, IAM and policies, OIDC and SSO, multi-tenancy, distributed mode, single node mode, bitrot protection, healing and the scanner, bucket and site replication, bucket quota, event notifications, audit logging, a web console, Kubernetes Helm charts, FTPS and WebDAV, and SFTP.

Two rows are not. S3 Tables, described as an Iceberg REST catalog, is preview, and so is MinIO on-disk compatibility. The notes explain what preview means in each case: S3 Tables has automated PyIceberg and DuckDB coverage while other engines and vendor profiles carry bounded claims in a support matrix, and MinIO on-disk compatibility is gated behind the rio-v2 cargo feature and is not part of the default build. So the two things most likely to matter to you, a lakehouse catalog and a MinIO migration, are the two the project itself has not claimed as finished.

MinIO encrypted objects are not readable, which is the migration catch

That second preview row carries the sentence that decides the migration question. MinIO on-disk compatibility is gated behind the rio-v2 feature, it is not part of the default build, and objects that MinIO encrypted are not readable by RustFS. The project links a document on MinIO file-format interoperability for the detail.

Read that as three separate constraints rather than one. You have to turn on a non-default feature to read MinIO's format at all. And even then, anything MinIO encrypted is out of reach, which in practice means a MinIO deployment with server-side encryption enabled cannot be picked up file by file no matter what you build.

The project description does say RustFS supports migration and coexistence with other S3-compatible platforms such as MinIO and Ceph, and the KMS row is marked available with Vault in KV2 and Transit flavours plus AWS KMS for production. Migration by reading the existing disk is the path that is behind a flag and has a stated hole in it, so test it before you promise it.

The shipped compose file ships well-known credentials and a comment saying so

The compose file in the repository is a development file, and it is honest about that in a way worth quoting. The service sets no-new-privileges, exposes two ports, 9000 for the S3 API and 9001 for the console, and defines four storage volumes with a brace expansion. The console is enabled, the address is bound to all interfaces, and the CORS allowed origins are set to a wildcard.

Then the credentials, with a comment above them that says the defaults are public and well-known and should be overridden before exposing the listener beyond localhost:

- RUSTFS_ACCESS_KEY=${RUSTFS_ACCESS_KEY:-rustfsadmin}
- RUSTFS_SECRET_KEY=${RUSTFS_SECRET_KEY:-rustfsadmin}

The same block also sets a log level, a TLS path under /opt/tls, and an OpenTelemetry endpoint pointing at an otel collector, so the observability path is there to be configured rather than bolted on later.

The consequence is straightforward. This file will give you a working store in a minute, and if you take it to a machine other than your laptop with those two variables unset, you have published root-equivalent credentials for your object store on a wildcard CORS listener. Everything else about the deployment is ordinary; this one block is where the reading has to happen.

The licence is the pitch, and AGPL is the competitor it names

The README spends a sentence on licensing that no other part of the project would need, and it is the reason to look at RustFS at all. It states that unlike other storage systems, RustFS is released under the permissible Apache 2.0 license, avoiding the restrictions of AGPL. The feature table repeats it as a headline: licensed under Apache 2.0, encouraging unrestricted community contributions and commercial usage.

That is a direct comparison, aimed at a specific objection. If your organisation has a policy on strong copyleft, or your legal team has already ruled on an AGPL dependency, this is the fact that gets the project past the gate. Apache 2.0 is permissive, carries no network use condition, and does not require you to publish anything you build on top of it.

The other half of the same argument is the implementation language. The project describes itself as combining the simplicity of MinIO with the memory safety and raw performance of Rust, and it is written in Rust with a workspace that includes a dedicated erasure coding crate, a healing crate, a distributed lock crate and a crypto crate. An S3 store is a large amount of systems code handling untrusted input, which is a reasonable place for a memory-safe language to be an argument rather than a preference.

2.3x is measured on two cores, four drives and 4KB payloads

The performance claim in the repository description is 2.3x faster than MinIO for 4KB object payloads, and the README sets out the environment it was measured in. Two cores, an Intel Xeon Platinum 8475B on Sapphire Rapids at 2.7 and 3.2 GHz, 4GB of memory, a 15Gbps network, and four 40GB drives at 3800 IOPS each. The README gives the result as a linked attachment rather than as a table of numbers in the text.

So read the claim with its conditions attached. This is a small-object workload on modest hardware, which is a realistic shape for a lot of workloads and an unrealistic one for large sequential throughput or for erasure-coded writes on spinning disks. The 4GB of memory is particularly worth noticing, since a distributed store is exactly the kind of program where memory headroom tends to matter.

If the decision rests on throughput rather than on the licence, the number to reproduce is yours to run on your own box.

The workspace manifest documents the architecture in its own comments

The Cargo.toml is unusually readable because every workspace member carries a comment explaining what it is. The core file system implementation is the rustfs member, and the crates around it are named for their job: crates/ecstore is the erasure coding storage implementation, crates/heal handles erasure set and object healing with a separate crate for the heal request and response contracts, crates/lock is distributed locking, crates/crypto is cryptography and security, crates/kms is key management, crates/iam is identity and access management, crates/keystone is the OpenStack Keystone integration, crates/audit fans out to multiple targets, and crates/connect-symbol-catalog is a release-only CPU profile symbol catalog generator.

The rest of the tree describes a release process rather than a demo. There are four Dockerfiles, the production one, a glibc variant, a source variant and a decommission-local variant, plus docker-compose files for the simple, full and decommission cases, a docker-buildx script, a Justfile, a Makefile, a Rust spec file for RPM packaging, a Helm chart directory, a Nix flake, a fuzz directory, deny.toml for dependency policy, and a rust-toolchain.toml.

Two build details will save you time. The production Dockerfile builds on Alpine 3.24.2 and resolves the release tag at build time through the GitHub API, and it supports only amd64 and arm64, erroring out on any other target architecture. And the Makefile sets its shell to bash with strict flags, then routes its Python helper calls through a resolver script because those scripts import tomllib, which needs Python 3.11, while macOS still ships a 3.9 interpreter, with a fallback to uv.

Editorial conclusion

Use RustFS if your objection to an S3-compatible store is its licence, if you want a Rust codebase you can read, or if you are starting fresh and can live inside the features the status table marks as shipped. Do not plan a straight migration of an existing MinIO deployment on the strength of the interoperability claims, because MinIO on-disk compatibility is gated behind the rio-v2 feature, is not in the default build, and objects that MinIO encrypted are not readable by RustFS at all. Before you deploy: read the status legend and the two preview rows, not the prose; change the default access and secret keys, which the shipped compose file itself flags as public and well-known; check the S3 compatibility matrix for the specific calls your application makes; and pin a tag rather than latest, since the last three releases are 1.0.2, 1.0.3 and 1.0.4.

Frequently asked questions

Official sources

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