RustFS offers Apache-licensed S3-compatible object storage in a single self-hosted binary

A dev.to tutorial published on August 27 walks through running S3-compatible object storage on bare metal with RustFS, an open-source server written in Rust and released under the Apache 2.0 license. The software ships as a single binary, installs with a one-line script on x86_64 or aarch64 Linux machines using systemd, and exposes the S3 API on port 9000 alongside a web console on 9001. Per the project's own status documentation cited in the article, single-node operation counts as production-ready today, while multi-node clustering is still being tested.

How the install works

According to the dev.to walkthrough, the installer script downloads the binary to /usr/local/bin/rustfs, registers a systemd service, starts it, and keeps object data under /data/rustfs0 by default. Data paths and ports can be adjusted at install time. The default access and secret keys are both set to rustfsadmin, and the documentation warns they must be replaced — keys live in /etc/default/rustfs and take effect after a service restart.

A container route is also available. The official Docker image maps both ports and persists data and logs through volume mounts; the article cautions that omitting those mounts means a container restart wipes everything under /data and /logs. The author also notes that none of the commands were executed in the sandbox, which lacked a Docker daemon — every command was copied verbatim from the official documentation.

Client compatibility

RustFS ships its own CLI, rc, which registers an endpoint alias, runs health checks, and handles bucket creation along with object upload and listing. Because the server implements the S3 API, AWS SDKs, the aws CLI pointed at the server with --endpoint-url, and MinIO's mc all work against port 9000 with the same credentials and no application changes. The author frames this compatibility as the core appeal: obtaining an S3 endpoint on hardware you control rather than renting one.

What works and what does not

The project's feature status table, as quoted by dev.to, marks these capabilities as available: core S3 operations, upload and download, versioning, logging, event notifications, bucket replication, bitrot protection, single-node mode, multi-tenancy, Keystone authentication, and the Swift API. Distributed mode, lifecycle management, and RustFS KMS remain under testing. The current release also lacks Object Lock, FUSE or POSIX mounting, built-in erasure coding, and any turnkey multi-region configuration.

The bare-metal trade-off

The tutorial is direct about what self-hosting costs. Disks fail, servers reboot, and certificates expire — and those become the operator's incidents rather than a vendor's. The quick-start runs in single-node, single-disk mode with no redundancy, which the author describes as acceptable for evaluation and development but risky for data that matters. Suggested mitigations include attaching a second disk, scheduling backups, or waiting for distributed mode to stabilize before committing important workloads.

Why it matters

S3 has become the default interface for object storage across modern tooling, and per-gigabyte cloud bills scale with every upload. A permissively licensed, single-binary server that speaks that API gives developers and small teams a practical exit from managed storage without rewriting their applications or changing their client stack. The honest caveat is durability: until clustering graduates from testing, a RustFS deployment is one machine, and teams needing cross-node redundancy, automated tiering, or compliance retention should plan around the current gaps rather than assume they exist.