RustFS

RustFS is a high-performance, distributed object storage system written entirely in Rust. It targets the same territory as MinIO and Ceph — S3-compatible storage for data lakes, AI/ML pipelines, and big data workloads — but leans on Rust’s memory safety and zero-cost abstractions instead of Go’s garbage collector to avoid GC pauses under sustained load. The project ships broad S3 API compatibility (tracked in an explicit compatibility matrix), along with native OpenStack Swift and Keystone support, making it a drop-in target for tooling built against either ecosystem.

What sets RustFS apart from most self-hosted storage projects is its licensing stance: it is released under Apache 2.0, explicitly positioned as an alternative to AGPL-licensed competitors that carry copyleft obligations for downstream commercial use. The workspace is organized into more than 50 focused crates covering erasure coding, distributed locking, identity and access management, key management (with Vault and AWS KMS backends), lifecycle and tiering, replication, and protocol adapters for FTPS, SFTP, and WebDAV — giving it a modular architecture that mirrors MinIO’s feature set without inheriting its Go runtime characteristics.

The project is under very active development, with thousands of commits and a dense CI matrix covering fault tolerance, pool expansion, healing, replication, tiering, security, and MinIO interoperability testing. It also ships an Iceberg REST Catalog (S3 Tables) as a preview feature for querying object storage directly with engines like PyIceberg and DuckDB, positioning RustFS as infrastructure for AI-native and analytical workloads rather than just a plain S3 bucket replacement.

What You Get

• A single static binary (or Docker image) that runs as either a single-node/single-drive deployment or a distributed, erasure-coded multi-node cluster
• Broad S3 API compatibility tracked in an explicit compatibility matrix, plus native OpenStack Swift and Keystone authentication support
• Built-in bucket replication, site replication, versioning, object lock (WORM), lifecycle management (ILM) with remote-S3 tiering, and bucket quotas
• A KMS subsystem with Vault (KV2/Transit) and AWS KMS backends for server-side encryption key management in production deployments
• A web console, IAM/policy engine, OIDC/SSO integration, audit logging, and event notifications for operating the cluster day to day
• Preview support for S3 Tables via an Iceberg REST Catalog, queryable from engines like PyIceberg and DuckDB, plus S3 Select for in-place query pushdown

Common Use Cases

• Replacing a MinIO or Ceph deployment with a Rust-based storage layer that avoids GC-pause latency spikes under heavy I/O
• Backing AI/ML training and inference pipelines with an S3-compatible data lake that supports high-throughput, high-concurrency access
• Running self-hosted, multi-tenant object storage behind existing S3 tooling (backup software, CI artifact stores, static asset hosting) without code changes
• Standing up storage for edge or IoT deployments where a lightweight, memory-safe binary is preferable to a heavier Go or Java-based system
• Serving as the storage layer under an Iceberg-based analytical stack, querying data in place with PyIceberg or DuckDB instead of exporting it first

Under The Hood

Architecture RustFS is organized as a Cargo workspace of more than 50 crates rather than a monolithic binary, with the top-level rustfs crate wiring together startup sequencing (a long chain of startup_* modules for storage, IAM, TLS, background jobs, observability, and protocol servers), an admin API, and protocol front-ends. Core storage logic lives in crates/ecstore (erasure-coded storage engine, disk/pool/set management, object API), with adjacent crates handling distributed locking (crates/lock), healing and scanning (crates/heal, crates/scanner), replication (crates/replication), and identity/policy (crates/iam, crates/policy). This separation lets the erasure-coding and pool-topology internals evolve independently of the S3/Swift protocol surface, and the explicit heal-contracts and storage-api-contracts crates suggest the team treats cross-crate interfaces as versioned contracts rather than incidental coupling — changing the core storage-api would ripple through every protocol adapter and admin handler that depends on it.

Tech Stack The server is built on Tokio for async I/O, Axum for HTTP handling, and Tonic for gRPC-based internal cluster RPC, with hyper/hyper-rustls underpinning the HTTP stack and TLS. AWS SDK crates (aws-sdk-kms, aws-sdk-s3, aws-sdk-sts) back the KMS and S3-tiering integrations, and DataFusion powers S3 Select and the Iceberg-backed S3 Tables query path. Protocol crates add optional FTPS, SFTP, Swift, and WebDAV support behind Cargo feature flags (ftps, sftp, swift, webdav), and the project builds against a pinned Rust toolchain (1.98.1, edition 2024) with a rio-v2 feature gating experimental MinIO on-disk format interoperability.

Code Quality The repository carries an unusually large CI surface for an open-source infrastructure project: dozens of GitHub Actions workflows cover unit tests, fault-tolerance drills, pool expansion, healing, replication, tiering, KMS, security, S3-compatibility (mint, MinIO interop), and upgrade paths, alongside fuzzing and nightly builds. There are roughly 389 Rust files containing tests across the workspace, workspace-wide Clippy lints are enabled with unsafe_code = "deny" at the workspace level (unsafe blocks that do exist, e.g. in the custom allocator wiring, carry explicit // SAFETY: justification comments), and errors are modeled with thiserror throughout rather than stringly-typed failures. A deny.toml also gates dependency licensing and security advisories in CI.

What Makes It Unique RustFS’s differentiation is less about a single novel algorithm and more about combining a mature MinIO-equivalent feature set (erasure coding, site replication, ILM tiering, multi-tenancy) with a memory-safe Rust runtime and a permissive Apache 2.0 license — directly contrasting itself against AGPL-licensed alternatives in its own documentation. Its Iceberg REST Catalog / S3 Tables support is a forward-looking bet on object storage as a first-class analytical substrate, and an entitlement/licensing crate (crates/license, gated behind an opt-in, non-default license Cargo feature) exists as infrastructure for optional commercial builds without affecting the open-source default build.

Self-Hosting

Licensing Model RustFS is released under the Apache 2.0 license. The default build (what you get from source, Docker, or the installer script) has no license key requirement and no gated features — the license Cargo feature that enables entitlement checking is not included in the default or full feature sets and must be explicitly opted into at build time.

Self-Hosting Restrictions

• None identified in the default build. All S3, IAM, replication, tiering, and console features shown in the README’s feature table are available without a license key.
• Two features are marked “Preview” rather than restricted: S3 Tables (Iceberg REST Catalog) and MinIO on-disk format compatibility, both opt-in via Cargo feature flags rather than gated by licensing.

Enterprise Features No separate paid tier or enterprise edition is documented in the README or repository. The crates/license crate defines provider-neutral entitlement contracts (e.g. a rustfs.server entitlement) that a custom or OEM build could use to gate functionality, but this exists as an opt-in extension point, not an active restriction on the open-source distribution.

Cloud vs Self-Hosted Not applicable — RustFS does not currently offer a hosted cloud version; deployment is via binary install, Docker, Helm charts, or building from source.

License Key Required No, for the standard open-source build. A license key is only relevant if a downstream distributor compiles with the non-default license feature enabled.