RustFS Lands as an Apache 2.0 S3-Compatible Object Store, Targeting MinIO's AGPL Gap

If you've been tinkering with self-hosted object storage in the past couple of years, you've probably been bouncing between MinIO, Ceph, and SeaweedFS. One day, someone in a tech group dropped the line, "Tried RustFS, 4KB small object throughput is more than twice as fast as MinIO." Your first reaction was likely: What is RustFS? Is it just another MinIO clone?

This article is for those who have never heard of it, laying out the whole story: what it is, what it can do, what the numbers look like, its highlights and shortcomings, how to get started, and why everyone in the community is suddenly talking about it.

1. What Exactly Is RustFS

First, let's clarify the premise of "object storage." Unlike block storage (which provides raw disk volumes) and file storage (a directory tree + files), object storage saves data as "objects": each object has a globally unique key, a piece of binary data, and a set of key-value metadata. You read and write by key via an HTTP API, without mounting a filesystem or managing block devices. Amazon S3 made this model the de facto standard, so "S3 API compatibility" is equivalent to "works directly with aws-cli, rclone, various SDKs, and backup tools."

RustFS is an open-source, S3 API-compatible object storage service implemented in Rust, under the Apache 2.0 license, delivered as a single statically linked binary. Its positioning almost completely overlaps with MinIO: both are lightweight contenders for "running an S3-like service at home or in your own data center," rather than a distributed all-in-one suite like Ceph that requires a dedicated ops team.

In other words, if you are already familiar with how MinIO works, the migration cost to RustFS is near zero—one of its selling points is that "your S3 toolchain continues to work as usual."

2. What It Can Do: Core Capability List

Whether an object store is worth using depends first on its API surface coverage. RustFS currently covers S3's data-plane and some control-plane capabilities:

• Basic Read/Write: PUT / GET / DELETE / HEAD, addressed by bucket + key.
• Large File Multipart Upload: Multipart upload allows a single object to exceed the limit of a single request, suitable for GB-level backups and images.
• Presigned URLs: presigned URL allows you to send temporarily readable or writable links to external parties without exposing your secret key, handy for temporary downloads and upload callbacks.
• Versioning and Lifecycle: Object versioning, expiration by prefix or days, necessary for backup retention policies and data lake tiering.
• Erasure Coding: Data is split into N pieces, and M parity pieces are calculated, distributed across different disks or nodes. If a few disks fail, data can still be reconstructed; this is the underlying mechanism for object storage to withstand disk failures.
• Distributed Mode: Add nodes to horizontally scale capacity and throughput without tearing down the architecture to rebuild.

In terms of scenarios, it is used as: a backup target, the storage base for data lakes/lakehouses, a dataset repository for AI training, a container image or Helm chart repository, static website hosting, and log archiving. The common thread in these scenarios is "massive objects + HTTP access," which hits the sweet spot of object storage.

3. How It Performs: Numbers and Boundaries

Capabilities alone are useless without benchmarks. Below are some publicly available, bounded explanations—don't take them as blind conclusions:

Small Object Throughput. In the vendor's own same-machine comparison (same machine, 4KB objects, consistent concurrency), RustFS's PUT throughput is about 2.3 times that of MinIO.

Deployment Size and Resident Memory. The single binary is about 93 MB (a comparable Go implementation is about 320 MB). Idle memory is stably under 100 MB, with no JVM heap to tune and no etcd to keep alive. For edge nodes and lightweight VMs, "drag a 90-megabyte file over and it runs" is a tangible difference.

Shortcomings Must Also Be Stated. For GET requests in the 100 KiB–1 MiB range, RustFS currently still lags behind MinIO, a fact the project's own reports do not shy away from.

4. A Few Things That Make Ops Easier

Putting benchmarks aside, the structural reasons that actually get a team to put it on the shortlist are often these:

License. RustFS uses Apache 2.0—no copyleft, no source code disclosure obligation. You can embed it in closed-source products, do secondary development, and deploy it closed-source, with no protocol-level commercial risk. The contrast is MinIO's switch from Apache 2.0 to AGPLv3 in 2021: if you modify the code and provide it as a network service externally, you must disclose the source code. For companies with private integrations or building proprietary storage products, this is a real legal friction.

Memory Safety and No GC Brought by Rust. Object storage is a long-running process, and two of the most insidious failure sources are memory errors and GC pauses. C/C++ has a historical burden of memory safety issues, and Go has unpredictable GC pauses under high load. Rust plugs a large class of memory safety problems at compile time, meaning "buffer overflow-type CVEs" are reduced at the language level; for ops, memory jitter is smaller under the same load, the probability of OOM kills is lower, and late-night alerts are fewer.

Single Binary, Few Dependencies. No JVM, no external metadata database, no bunch of sidecars. Copy it over, start the process, and you're done. The list of "what else does it depend on" in deployment scripts and CI is much shorter.

5. Where It Stands Compared to a Few Familiar Faces

Lay out a few options often compared together, each suitable for different people:

• vs MinIO: The biggest fork is the license (Apache 2.0 vs AGPLv3). Performance-wise, RustFS is stronger for small objects, but MinIO still leads in the 100KiB–1MiB range; both are lightweight to deploy, with extremely low migration costs.
• vs Ceph: Ceph is a full suite, broad in capability and high in ceiling, but requires a dedicated team and an ops system. RustFS is a "good enough" lightweight alternative, not suitable for ecosystems already heavily reliant on RADOS / RBD.
• vs AWS S3 (Managed): Managed services are worry-free, with 24/7 SLAs, at the cost of pay-per-use and lock-in. RustFS is suitable for teams that want to control their own data, are cost-sensitive, and have the capability to operate it.

6. Getting Started: Four Steps to Run It

Don't just look at comparisons; hands-on is fastest. A minimal viable path:

# 1) Start a single-node RustFS instance
docker run -d --name rustfs \
  -p 9000:9000 -p 9001:9001 \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=changeme \
  rustfs/rustfs

# 2) Point your existing rclone remote directly at it, with zero config changes
rclone lsd rustfs: --dump headers

# 3) Use s3-tests to verify real S3 compatibility (don't just look at the 100% on the marketing page)
S3_ENDPOINT=http://localhost:9000 \
S3_ACCESS_KEY=admin S3_SECRET_KEY=changeme \
python s3tests/s3tests.py

Proceed in this order: first docker run to start a single node, use rclone to migrate a small bucket over; then run the data-plane test cases of s3-tests, record the real pass rate; then switch read traffic over and observe latency for a week, switch writes after it stabilizes; when you really need to scale up, refer to the official documentation to add nodes for horizontal scaling, don't pile on machines from the start.

7. Industry Attention: Signals Beyond Stars

RustFS has surpassed 30,000 stars on GitHub, in less than 400 days since going open source. The star count itself is not a reason for adoption, but there are a few signals worth reading behind it: first, the demand for "lightweight self-hosted S3" has never been well met—after MinIO switched to AGPL, many enterprises suddenly started looking for a commercially licensable, closed-source alternative; second, the wave of rewriting infrastructure in Rust is indeed persuasive for this type of long-running, high-concurrency service; third, third-party tech blogs and community discussions have started comparing it side-by-side with MinIO, indicating it has entered the "candidate list" rather than being a "toy."

A dose of cold water is needed: stars do not equal production adoption. What truly measures whether it works is the benchmarks on your own workloads, whether you can find answers when you hit snags, and whether someone responds when problems arise. These need to be verified using the aforementioned s3-tests and real traffic canary deployments, not by looking at trend charts.

Closing: A Decision Checklist for You

If you are currently evaluating options, self-check in this order:

1. Do you need self-hosting, data control, and are you cost-sensitive? No → Look directly at managed S3.
2. Are you worried about the commercial risks brought by AGPL? Yes → Apache 2.0 licensed RustFS saves a layer of legal hassle compared to MinIO.
3. Is your main workload large batches of small object writes, data lakes, or backups? Yes → It's worth testing a version.

The repository is here: https://github.com/rustfs/rustfs. Do the docker run from Section 6 first; it's more practical than reading ten comparison articles.