What RustFS actually replaces
RustFS is an object store, not a normal shared filesystem. Applications create buckets and address objects through S3-compatible HTTP calls, while RustFS manages data across one or more disks. The common use cases are application uploads, backups, build artifacts, analytics files, and large AI datasets. A web console handles basic administration, and OpenStack users also get Swift API and Keystone authentication work.
Its immediate pitch is familiar to anyone following MinIO: a self-hosted service with a straightforward container, broad S3 client support, and distributed storage. The important difference is an Apache-2.0 license and a Rust implementation. That permissive license is attractive to companies embedding or modifying a server that do not want AGPL obligations. Rust's memory safety is a useful engineering property, but it does not by itself prove correct persistence, recovery, authorization, or protocol behavior.
The README includes performance comparisons with MinIO from a stated two-core, four-drive environment. Treat those as project-produced measurements, not a purchasing benchmark. Storage results depend on object size, concurrency, checksums, encryption, drive latency, network topology, and durability settings. Reproduce the workload and include failures, healing, and tail latency before drawing a conclusion.
Compatibility is broad, not complete
RustFS uses careful wording: broad S3 API compatibility for supported features. Its compatibility matrix is one of the best parts of the project because it makes that scope inspectable. It lists 452 standard Ceph S3 tests expected to pass in the default run, five separate lifecycle behavior tests, 17 unimplemented tests, and 273 excluded tests. Exclusions include vendor-specific behavior and intentional choices such as unsupported ACL authorization.
Core bucket and object operations, multipart uploads, policies, public-access blocking, presigned reads and writes, ranges, tags, metadata, and selected versioning, object lock, checksum, conditional-write, and server-side encryption cases are covered. Planned areas include bucket access logging, ownership controls, parts of form-upload checksums, and some account or storage-class dependent cases. Applications should compare their exact API calls with the matrix and run their own SDK suite. A successful aws s3 cp is only a smoke test.
Migration has an especially sharp edge. The matrix says RustFS can encrypt and decrypt objects it writes, but cannot currently read objects MinIO wrote with SSE-S3, SSE-KMS, or SSE-C. S3 API compatibility does not imply disk-format interoperability. Moving encrypted data requires reading it through the old server and writing it through RustFS, followed by checksum verification, rather than attaching existing MinIO drives.
A simple trial, then serious storage work
The Docker path is clear. Create data and log directories, make them writable by UID and GID 10001, publish API port 9000 and console port 9001, and mount the directories. Podman can apply ownership mapping automatically. Compose, Helm, Nix, an installation script, and source builds are also documented. The container runs as a non-root user, which is a sensible default.
The console documentation gives rustfsadmin as both default username and password. Change credentials before exposing either port, add TLS, and restrict administrative access. Webhook calls to private addresses are blocked unless their exact origins are allowed, and skipping webhook certificate verification is explicitly warned as vulnerable to interception. These details show useful security attention.
Real operation starts after the first upload. Decide erasure and server-pool layout, reserve failure domains, monitor disk and scanner behavior, document replacement steps, test bitrot detection, and prove restoration while a node is unavailable. The README links guides for scanner pacing, scanner pressure, and slow-drive timeouts. Those knobs exist because background maintenance and large listings can compete with foreground traffic.
The release candidate is not finished storage
The feature table marks single-node mode, versioning, replication, bitrot protection, notifications, and multi-tenancy available. It marks distributed architecture, lifecycle management, and RustFS KMS under testing, with Swift metadata operations partial. Those labels should outweigh the broad marketing copy when deciding where to place data.
Issue 6001 provides a concrete distributed warning. On a two-node 1.0.0-rc.1 Kubernetes deployment using hostPath volumes, the reporter added a second disk per node and found existing data invisible, with the new pool stuck without a completed status. The objects were reported hidden rather than proven destroyed, but invisibility during expansion is already unacceptable without a tested recovery path. Do not experiment with pool topology on the only copy of a dataset.
Lifecycle behavior is also moving. Issue 5951 reports expired noncurrent objects remaining visible as delete markers in version listings even after direct access returns not found. Issue 5957 says compression environment variables affected HTTP responses rather than compressing stored objects, contrary to the reporter's MinIO-based expectation. These are reports against 1.0.0-rc.1, not independently confirmed findings, yet both concern behaviors operators use for capacity planning and retention.
The open issue list also includes automated tickets for failed nightly replication and security-audit jobs. Automated failure tracking is healthy practice, but a prospective operator should inspect whether the relevant runs are green on the exact commit selected.
Health and the sensible verdict
RustFS had 30,983 stars, 66 open issues and pull requests, and an Apache-2.0 license when researched. The last push was August 12, 2026, and code, tests, fixes, and issue discussion were moving throughout that day. Community momentum is excellent. GitHub's latest-release endpoint returned no release, while the README's pinned container example uses 1.0.0-rc.1. That combination describes a highly active release candidate, not settled infrastructure.
RustFS deserves a test if permissive licensing, Rust, OpenStack support, or a MinIO alternative matters. Begin with disposable objects on one node, validate every S3 call, and rehearse export and restore. Then test a multi-node copy under disk loss, network partition, upgrades, and expansion. Keep the source data elsewhere. MinIO is the safer direct comparison today, while Ceph suits organizations needing proven object, block, and file storage and willing to operate a much larger system. RustFS can earn production trust, but a storage system earns it through recovery evidence over time.