RustFS is an S3 server still proving its distributed path
RustFS stores objects behind an S3-compatible API and includes a browser console, bucket versioning, replication, notifications, bitrot protection, and OpenStack Swift access. The code is Apache 2.0, which is a concrete reason to consider it if MinIO's AGPL terms do not suit your distribution or hosting model. RustFS also documents Keystone authentication and optional OIDC role claims for organizations already invested in those identity systems.
The status table deserves more attention than the feature list. Single-node mode, core S3 operations, versioning, and replication are marked available. Distributed mode, lifecycle management, and KMS are marked under testing, while some Swift metadata operations are partial. That is an unusually useful admission for a storage project. It also means the safest first deployment is a disposable or replicated workload, not the only copy of business data.
Docker starts quickly if UID 10001 owns every mount
The shortest path maps ports 9000 and 9001, plus data and log directories, into the official container. RustFS runs there as non-root UID and GID 10001. Host bind mounts must be writable by that account. TLS certificate directories need the same treatment. Podman users can apply its relabel and ownership flags, while the simple Compose file includes a helper for named volumes.
That setup detail is easy to miss and likely to produce a permission error before the server opens a port. The README repeats the warning for data, logs, and TLS, which is good documentation. Default console credentials are rustfsadmin for both user and password, so changing them and putting TLS in front of the service belong in the first serious deployment, not a later hardening pass.
The larger Compose definition is a platform bundle. It can include Grafana, Prometheus, Jaeger, Redis, and Nginx through services or profiles. Kubernetes users get Helm charts, while Nix and a one-line installation script cover other routes. Those choices still leave operators responsible for drives, erasure sets, scanner behavior, health endpoints, outbound notification policy, and persistent configuration.
What happened when we ran it
Our run installed 1,222 packages in 43 seconds on a fresh container with 3 CPUs and 12 GB of RAM. RustFS is a very large workspace: the checked-out repository contained 2,385 files and about 1,221,515 lines of source. It included 28 CI workflow files, a Dockerfile, and a Compose file. The installation step was quick for that scale.
Compilation was another matter. The build command reached our 900-second limit and timed out. The test command also timed out after 900 seconds. Its final output was still compiling dependencies and project crates, including rustfs, rustfs-log-analyzer, rustfs-scanner, rustfs-s3select-query, rustfs-rio-v2, and e2e_test, followed by tokio-test. We saw no assertion failure or compiler error in the supplied tail. The suite simply did not reach execution before the cutoff.
That result does not prove the project cannot build. It says a clean build and test cycle exceeded 15 minutes each on our constrained machine, which is material for contributor setup and CI sizing. The repository had no top-level tests directory, though test-related crates and extensive workflows were present. Use binary images for evaluation, and budget a much larger runner or cached Rust build for source work.
Open reports hit the failure modes storage buyers care about
Issue #6218 describes 16 keys on a versioned, object-locked bucket that appeared through list operations but returned 404 to HEAD and GET. The reporter saw some of them during normal operation on release candidates rc.1 and rc.2, and background healing did not restore them. This evidence comes from one user's environment rather than our lab. The list-versus-read disagreement is serious enough to add an automated consistency scan to any trial.
Issue #6286 covers a 4-node Kubernetes deployment where powering off one host slowed readiness on the surviving nodes beyond a 3-second probe timeout. Kubernetes then removed all 4 endpoints and S3 traffic returned 503, even though the erasure set retained quorum. Stopping only the peer process did not cause the same result. That specificity makes node and network failure drills mandatory before accepting the distributed mode claim.
Encryption operations need the same skepticism. Issue #6574 reports that KMS configured through the admin API worked and persisted to storage, then came back as unconfigured after a restart on 1.0.0-rc.3. The report includes a startup warning showing that configuration loading occurred before storage initialization. RustFS already labels KMS under testing, so encrypted buckets should remain out of scope until restart recovery passes in your environment.
The August 26 push is fresh, while GitHub has no release object
The repository was pushed on August 26, 2026, and current issues and pull requests were moving on August 25 and 26. GitHub reported 31 open issues and pull requests. There was no object returned by the latest-release API, although repository tags included 1.0.0-rc.3 and the README's Docker example used that tag. Operators should pin an image digest or explicit tag rather than rely on latest.
RustFS is worth testing for teams that want an Apache-licensed S3 server and can keep an established store as the source of truth during evaluation. The console, container, observability pieces, and detailed runbooks show real operational intent. The current status table and issue evidence point to the same conclusion: single-node trials are reasonable, while distributed durability claims still need independent proof with your data shape, clients, upgrades, and failure schedule.