Self-Host RustFS in 2026: Dokploy or Docker Compose Guide

If you self-host RustFS today, you’re deploying one of the fastest-rising S3-compatible object storage servers around — and with MinIO’s repository now archived, RustFS 1.0 (GA September 2026) has become the default MinIO alternative for self-hosters. This guide covers two deployment paths, Dokploy (easiest) or plain Docker Compose, plus the verify, backup, and scaling steps that turn a demo into storage you can actually trust with data.

The December 2025 version of this guide deployed a pre-release build. Everything below was re-checked against the official docs and repositories in September 2026, and several configuration details changed along the way — including two mistakes in my earlier compose files that I’ve fixed here.

What Is RustFS?

RustFS is a high-performance, distributed S3-compatible object storage server written in Rust and released under the Apache 2.0 license. The project open-sourced in July 2025 and moved fast: 10k GitHub stars by October 2025, 20k by January 2026, beta in April 2026, and 1.0.0 GA on September 16, 2026. It now sits at 33k+ stars, 10M+ Docker Hub pulls, and 160+ contributors. (The “2.7M+ instances deployed” figure from the GA announcement is a vendor claim — impressive either way, but attribute it as marketing.)

Three things make it a strong MinIO alternative rather than just another S3 server:

• The MinIO feel. RustFS replicates MinIO’s interface, including a web console for buckets, users, and objects. If you’re migrating from MinIO, you’ll feel at home.
• Rust instead of Go. Memory safety without garbage collection pauses, which matters for small-object workloads.
• Apache 2.0. No AGPL obligations. You can use it in commercial products without source-disclosure requirements.

Key Features of RustFS (1.0 GA)

The 1.0 feature set is a big step up from the alpha builds most early guides (including mine) covered:

RustFS vs MinIO vs Other Object Storage

What’s New Since Our December 2025 Guide

If you read the earlier version of this post, here’s what changed:

Prerequisites

Before you begin, make sure you have:

VPS prices jumped across the board in 2026 — if you’re rethinking a rented box, see what changed and when a mini PC wins.

Understanding RustFS Ports (9000 vs 9001)

RustFS uses two ports:

• Port 9000: the S3 API endpoint. Applications connect here. It also serves the unauthenticated health endpoints (/health, /health/ready) and, in multi-node deployments, the internal node-to-node RPC paths (/rustfs/rpc/, /rustfs/peer/). There is no separate cluster port.
• Port 9001: the web console for buckets, users, and objects, served under the /rustfs/console/ path.

Diagram of RustFS ports: S3 API and node RPC on port 9000, web console on port 9001 behind a reverse proxy

In practice you put a reverse proxy with TLS in front of both and only expose 443. That proxy is also why the console health check lives at https://storage.yourdomain.com/rustfs/console/health rather than at the root.

Option 1: Self-Host RustFS with Dokploy

Dokploy is the fastest path if you already run it — a compose service plus two domains, and Traefik handles TLS. If you’re still choosing a PaaS, see our Coolify vs Dokploy vs Kamal 2 comparison.

Step 1: Install Dokploy

If you don’t have Dokploy yet, follow the Dokploy installation guide, then:

curl -sSL https://dokploy.com/install.sh | sh

Access Dokploy at http://your-vps-ip:3000 and complete setup.

Step 2: Create a New Project

1. Log in to the Dokploy dashboard
2. Click “Create Project” and name it (e.g., “RustFS”)
3. Inside the project, click “Add Service” → “Compose”
4. Select “Docker Compose” type (not Stack)
5. Name it “rustfs-stack”

Step 3: Add the Docker Compose Configuration

Go to the General tab and paste this configuration. If you’re new to the flow, our guide on how to deploy a Docker Compose app in Dokploy walks through the UI in detail.

services:
  rustfs:
    image: rustfs/rustfs:1.0.0 # pin the version; latest = 1.0.0 as of 2026-09-16
    networks:
      - dokploy-network
    volumes:
      - rustfs-data:/data
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      # Logs go to stdout unless this is set — without it, a log volume collects nothing
      - RUSTFS_OBS_LOG_DIRECTORY=/app/logs
      # :? guard = the stack refuses to start on missing/default credentials
      - RUSTFS_ACCESS_KEY=${RUSTFS_ACCESS_KEY:?set_a_non_default_access_key}
      - RUSTFS_SECRET_KEY=${RUSTFS_SECRET_KEY:?set_a_non_default_secret_key}
      # Only if a browser app needs CORS against the S3 API — list explicit origins:
      # - RUSTFS_CORS_ALLOWED_ORIGINS=https://app.yourdomain.com
      # For virtual-hosted style URLs (bucket.s3.yourdomain.com):
      # - RUSTFS_SERVER_DOMAINS=s3.yourdomain.com
    healthcheck:
      test: ["CMD", "sh", "-c", "curl -f http://localhost:9000/health && curl -f http://localhost:9001/rustfs/console/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 4GB

networks:
  dokploy-network:
    external: true

volumes:
  rustfs-data:

Step 4: Configure the Domains

This compose has no Traefik labels and no exposed ports. Route traffic through Dokploy’s Domains tab instead. Make sure DNS points at the server first.

1. After deploying, open the Domains tab for your compose service
2. Click Add Domain for the S3 API:
   • Domain: s3.yourdomain.com
   • Container: select the rustfs service
   • Port: 9000
   • Enable HTTPS for automatic SSL
3. Add a second domain for the console:
   • Domain: storage.yourdomain.com
   • Container: select the rustfs service
   • Port: 9001
   • Enable HTTPS

Step 5: Configure Environment Variables

Open the Environment tab and add your credentials. Generate them on any machine with OpenSSL:

# Access key: uppercase letters and digits only, no slashes (SigV4-safe)
openssl rand -hex 12 | tr 'a-f' 'A-F'

# Secret key: long random string
openssl rand -base64 32

Then set:

RUSTFS_ACCESS_KEY=A3F91C2E8B7D4056A9E1
RUSTFS_SECRET_KEY=<the base64 output from above>

Step 6: Configure DNS

Create two A records pointing at your VPS:

1. s3.yourdomain.com → your VPS IP (S3 API)
2. storage.yourdomain.com → your VPS IP (console)

Step 7: Deploy and Verify

1. Click “Deploy” and wait for the service to start
2. Watch the Logs tab — a healthy start shows the S3 API on 9000 and the console on 9001
3. Add the domains from Step 4 and wait ~30 seconds for Traefik certificates
4. Verify:

curl --fail https://s3.yourdomain.com/health

Expected: an empty 200 response. Then log in at https://storage.yourdomain.com with your access key and secret key. The Dokploy healthcheck turns green within about a minute.

If the stack exits immediately on deploy: the ${VAR:?} guard fired, meaning an env var is missing or you left the old defaults in. Fix the Environment tab and redeploy. If you upgraded from the previous version of this guide, note the old SERVER_DOMAIN variable did nothing — replace it with RUSTFS_SERVER_DOMAINS.

Option 2: Deploy RustFS with Docker Compose

For manual control, or on a server without a PaaS.

Step 1: Prepare Your Server

# Update packages
sudo apt update && sudo apt upgrade -y

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Install Docker Compose plugin
sudo apt install docker-compose-plugin -y

Step 2: Create Directories and Set Permissions

The RustFS container runs as non-root user rustfs with UID 10001. Bind-mounted directories must be owned by that UID:

mkdir -p ~/rustfs
cd ~/rustfs

# Data and logs directories
mkdir -p data logs

# Hand ownership to the container user (UID 10001)
sudo chown -R 10001:10001 data logs

Step 3: Create the Docker Compose File

nano docker-compose.yml

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    container_name: rustfs
    volumes:
      - ./data:/data
      - ./logs:/app/logs
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      # Without this, logs go to stdout and ./logs stays empty
      - RUSTFS_OBS_LOG_DIRECTORY=/app/logs
      - RUSTFS_ACCESS_KEY=${RUSTFS_ACCESS_KEY:?set_a_non_default_access_key}
      - RUSTFS_SECRET_KEY=${RUSTFS_SECRET_KEY:?set_a_non_default_secret_key}
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: ["CMD", "sh", "-c", "curl -f http://localhost:9000/health && curl -f http://localhost:9001/rustfs/console/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 4GB

Two changes from the previous version of this guide, both fixes: RUSTFS_OBS_LOG_DIRECTORY=/app/logs makes the log mount actually receive logs (in the old file the volume collected nothing because the default log destination is stdout), and the :-rustfsadmin fallback is gone — the stack now refuses to start on default credentials.

Step 4: Create the Environment File

Generate credentials (same commands as Option 1):

openssl rand -hex 12 | tr 'a-f' 'A-F'   # access key
openssl rand -base64 32                 # secret key

nano .env

RUSTFS_ACCESS_KEY=A3F91C2E8B7D4056A9E1
RUSTFS_SECRET_KEY=<generated secret>

Step 5: Start RustFS

# Start
docker compose up -d

# Status — wait for "healthy"
docker compose ps

# Logs — make sure there's no credential warning
docker compose logs -f

# Liveness check
curl --fail http://localhost:9000/health

docker compose ps should show (healthy) after roughly a minute. Anything else, check the verification section below.

Step 6: Reverse Proxy with Nginx

For production domains and SSL:

sudo apt install nginx certbot python3-certbot-nginx -y
sudo nano /etc/nginx/sites-available/rustfs

# RustFS S3 API
server {
    listen 80;
    server_name s3.yourdomain.com;

    # Allow large file uploads
    client_max_body_size 0;

    location / {
        proxy_pass http://localhost:9000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;

        # Timeouts for large uploads
        proxy_connect_timeout 300;
        proxy_send_timeout 300;
        proxy_read_timeout 300;
    }
}

# RustFS Console
server {
    listen 80;
    server_name storage.yourdomain.com;

    location / {
        proxy_pass http://localhost:9001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Enable and secure it:

sudo ln -s /etc/nginx/sites-available/rustfs /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

# SSL certificates
sudo certbot --nginx -d s3.yourdomain.com -d storage.yourdomain.com

Verify TLS end to end:

curl -I https://s3.yourdomain.com/health

Expected: HTTP/2 200. A 502 here usually means the container isn’t healthy; client_max_body_size 0 missing means large uploads fail with 413.

Option 3: Quick Test with Docker Run

For a throwaway test drive. Data still lands in $(pwd)/data, so the UID fix applies here too:

mkdir -p data logs
sudo chown -R 10001:10001 data logs

docker run -d \
  --name rustfs \
  -p 9000:9000 \
  -p 9001:9001 \
  -v $(pwd)/data:/data \
  -v $(pwd)/logs:/app/logs \
  -e RUSTFS_VOLUMES=/data \
  -e RUSTFS_ADDRESS=0.0.0.0:9000 \
  -e RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001 \
  -e RUSTFS_CONSOLE_ENABLE=true \
  -e RUSTFS_OBS_LOG_DIRECTORY=/app/logs \
  -e RUSTFS_ACCESS_KEY=testadminkey01 \
  -e RUSTFS_SECRET_KEY=only-for-local-testing-not-prod \
  rustfs/rustfs:1.0.0

Verify:

curl --fail http://localhost:9000/health

Console at http://localhost:9001. Tear it down with docker rm -f rustfs.

If the container crash-loops with a disk-topology error: the strict disk checks don’t like your volume setup. On a lab box you can set RUSTFS_UNSAFE_BYPASS_DISK_CHECK=true — the name says unsafe, treat it as lab-only.

Verify Your RustFS Deployment

RustFS exposes an unauthenticated health endpoint family on port 9000. Learn the difference between liveness and readiness — it saves you from “the container is up but the storage isn’t” confusion:

The /minio/health/* aliases exist for MinIO compatibility, so your existing tooling keeps working. All of these are on by default; disable with RUSTFS_HEALTH_ENDPOINT_ENABLE=false.

Post-deploy checklist:

# Container running and healthy
docker ps --filter name=rustfs

# Liveness
curl --fail http://localhost:9000/health

# Readiness — 200 means fully ready, 503 means still initializing
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:9000/health/ready

Then exercise the S3 path with the rc CLI (installed in the next section):

rc alias set local http://localhost:9000 $RUSTFS_ACCESS_KEY $RUSTFS_SECRET_KEY
rc ping local
rc ready local
rc admin info cluster local

Using RustFS: Web Console, rc CLI, mc and AWS CLI

Access the Web Console and Create a Bucket

Open https://storage.yourdomain.com (or http://localhost:9001 locally) and log in with your access key and secret key.

1. Click “Create Bucket”
2. Name it (e.g., my-first-bucket)
3. Configure versioning and object locking if needed
4. Click “Create Bucket”, then open the bucket and upload or drag-and-drop files

RustFS web console showing buckets and object management after a Docker Compose deployment

The screenshot above predates 1.0.0 — the GA console looks similar but the project now maintains the UI as a separate repository, so expect visual polish changes between versions.

Command-Line Clients: rc, mc, or AWS CLI

Install the first-party rc CLI (v0.1.30 at research time; Homebrew and Scoop packages also exist):

curl -fLO https://github.com/rustfs/cli/releases/download/v0.1.30/rustfs-cli-linux-amd64-v0.1.30.tar.gz
tar -xzf rustfs-cli-linux-amd64-v0.1.30.tar.gz
sudo install -m 0755 rc /usr/local/bin/rc

All three clients work against RustFS — rc is first-party and understands RustFS-specific admin output, mc is the veteran MinIO client that everything supports, and the AWS CLI is what your boto3/SDK habits map to. Pick one for scripts and stick with it.

# Configure an alias
rc alias set local http://localhost:9000 $RUSTFS_ACCESS_KEY $RUSTFS_SECRET_KEY

# Or with your domain
rc alias set rustfs https://s3.yourdomain.com $RUSTFS_ACCESS_KEY $RUSTFS_SECRET_KEY

# Connectivity and readiness
rc ping local
rc ready local

# Cluster and disk status
rc admin info cluster local

# Bucket and object work
rc bucket list local
rc object cp myfile.txt local/my-bucket/

# Install MinIO Client
curl https://dl.min.io/client/mc/release/linux-amd64/mc -o mc
chmod +x mc
sudo mv mc /usr/local/bin/

# Configure alias
mc alias set rustfs http://localhost:9000 $RUSTFS_ACCESS_KEY $RUSTFS_SECRET_KEY

# Create bucket, upload, list, download
mc mb rustfs/my-bucket
mc cp myfile.txt rustfs/my-bucket/
mc ls rustfs/my-bucket
mc cp rustfs/my-bucket/myfile.txt ./downloaded.txt

aws configure
# Access Key ID: your RustFS access key
# Secret Access Key: your RustFS secret key
# Region: us-east-1 (RustFS accepts any; see RUSTFS_REGION)
# Output format: json

aws --endpoint-url http://localhost:9000 s3 ls
aws --endpoint-url http://localhost:9000 s3 mb s3://my-bucket
aws --endpoint-url http://localhost:9000 s3 cp myfile.txt s3://my-bucket/
aws --endpoint-url http://localhost:9000 s3 ls s3://my-bucket/

Verify the read/write path either way: rc ready local returning OK plus a mc ls rustfs that lists your bucket means you have working storage.

One honest note: for scripts that must not break, mc is the safest default because it’s older and battle-tested across S3-compatible stores. rc is where RustFS-specific features (admin info, lifecycle) show up first.

Integrating RustFS with Applications

Most S3-speaking applications just need an endpoint, key, secret, and bucket:

S3_ENDPOINT=http://localhost:9000
S3_ACCESS_KEY=<your access key>
S3_SECRET_KEY=<your secret key>
S3_BUCKET=my-bucket
S3_REGION=us-east-1

Note on URL styles: RustFS supports path-style (http://endpoint/bucket) out of the box, which is what most self-hosted apps use. Virtual-hosted style (bucket.s3.yourdomain.com) requires setting RUSTFS_SERVER_DOMAINS=s3.yourdomain.com. If an app hardcoded MinIO path-style quirks, it should work unchanged.

Backup Tools: Restic

export AWS_ACCESS_KEY_ID=<your access key>
export AWS_SECRET_ACCESS_KEY=<your secret key>
export RESTIC_REPOSITORY=s3:http://localhost:9000/backups

restic init
restic backup /path/to/data

RustFS at 1.0.0 is new enough that I’d run restic init, a real restic backup, and restic check before trusting production data to this pairing. The full workflow lives in our guide to self-hosted backups with Restic and Rclone.

Docker Registry

services:
  registry:
    image: registry:2
    environment:
      REGISTRY_STORAGE: s3
      REGISTRY_STORAGE_S3_ACCESSKEY: <your access key>
      REGISTRY_STORAGE_S3_SECRETKEY: <your secret key>
      REGISTRY_STORAGE_S3_REGION: us-east-1
      REGISTRY_STORAGE_S3_BUCKET: docker-registry
      REGISTRY_STORAGE_S3_REGIONENDPOINT: http://rustfs:9000

AI Workloads

Two additions worth knowing if you lean that way: S3 Tables ships a built-in Apache Iceberg REST catalog (Preview), and RUSTFS_BUFFER_PROFILE=AiTraining tunes I/O buffers for large sequential AI training reads. There’s also an MCP server (rustfs/mcp) that lets AI assistants query buckets directly.

RustFS Configuration: Environment Variables

The table below reflects the official env-var reference as of 2026-09-18. Confirm any variable against that page before relying on it — this surface changed a lot between the alpha builds and 1.0.0.

Two corrections versus the previous version of this article: RUSTFS_CONSOLE_ENABLE defaults to true (I listed false before), and SERVER_DOMAIN is not a real variable — use RUSTFS_SERVER_DOMAINS. RUSTFS_EXTERNAL_ADDRESS also appeared in my old table but no longer shows up in the current reference; verify against the 1.0.0 source before using it.

Command Line Arguments

RustFS also takes CLI flags (--address, --console-address, --console-enable, --access-key, --secret-key, --server-domains), but environment variables are the right choice for Docker — check rustfs --help on your version for the exact set.

TLS Configuration

For native TLS without a reverse proxy, mount a directory with two files: rustfs_cert.pem and rustfs_key.pem. (The cert names in my old guide, public.crt/private.key, are wrong.)

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    volumes:
      - ./data:/data
      - ./certs:/certs
    environment:
      - RUSTFS_TLS_PATH=/certs
      - RUSTFS_TLS_RELOAD_ENABLE=true # swap certs without a restart

Encryption and KMS

GA at 1.0.0: SSE-S3 (AES256), SSE-C (caller-supplied keys), and SSE-KMS with local, vault/vault-kv2, or vault-transit backends (AWS KMS also supported). The README marks Local/Static KMS as development-only — for production, point it at Vault. Details in the official encryption docs. Two operator notes: SSE-C means the client owns the key, lose it and the object is gone; and RustFS-layer encryption doesn’t replace backups.

Event Notifications and the Outbound-Policy Gotcha

Event targets at GA: webhook, Kafka, MQTT, MySQL, Postgres, NATS, Redis, AMQP, Pulsar. Enable with RUSTFS_NOTIFY_ENABLE=true; audit logging is separate (RUSTFS_AUDIT_ENABLE=true).

This is the number-one trap for self-hosters wiring RustFS events into a self-hosted notification stack, so check the logs before assuming your webhook receiver is broken.

Maintenance: Updates, Backups and Monitoring

Updating RustFS

Pin discipline: run rustfs/rustfs:1.0.0 (or newer tagged releases), not :latest, so an upgrade is a decision instead of a surprise.

# Compose path
docker compose pull
docker compose up -d
docker image prune -f

On Dokploy, change the image tag in the compose and redeploy — our guide to updating Docker Compose stacks in Dokploy covers the flow. For distributed clusters, follow the official upgrade procedure: node by node, verifying cluster health between nodes.

image: rustfs/rustfs:1.0.0

Backups and Offsite Copies

Bind mounts (Option 2). Stop the container for a consistent copy, then tar:

docker compose stop rustfs
tar -czvf rustfs-backup-$(date +%Y%m%d).tar.gz ./data
docker compose start rustfs

Named volumes (Option 1 / Dokploy). The tar ./data approach above doesn’t apply — your data lives in a Docker volume. Use a helper container instead:

docker run --rm -v rustfs-data:/data -v $PWD:/backup alpine \
  tar -czf /backup/rustfs-data-$(date +%F).tar.gz -C /data .

Automate it with cron (adjust paths):

# crontab -e
0 2 * * * docker run --rm -v rustfs-data:/data -v /backups:/backup alpine tar -czf /backup/rustfs-data-$(date +\%F).tar.gz -C /data .

Go offsite. A tarball on the same disk is not a backup. Ship copies with restic or rclone — see self-hosted backups with Restic and Rclone for the setup, or offsite Dokploy backups to Cloudflare R2 if you’re on Dokploy. For destination shopping, our cheapest cloud storage for backups comparison covers Bunny vs S3 vs Backblaze; a Bunny Storage Zone or a B2 bucket both work fine as restic/rclone targets. Since replication is now GA, a second RustFS instance as a replication target is the native high-availability path if you’d rather stay in one ecosystem.

Verify it: a backup you haven’t restored is a hope, not a backup. Spin up a scratch RustFS container, restore the tarball into a fresh volume, and read an object back.

Monitoring and Logs

The RustFS repo ships an observability profile with Grafana (3000), Prometheus (9090), and Jaeger (16686):

git clone https://github.com/rustfs/rustfs.git
cd rustfs
docker compose --profile observability up -d

Beyond dashboards: RustFS exports an OTLP/HTTP pipeline (traces, metrics, logs) with a set of RUSTFS_OBS_* knobs if you’d rather feed your own stack. For the simple path, logs go to stdout by default (docker logs -f rustfs), or to RUSTFS_OBS_LOG_DIRECTORY when set, with rotation defaults of hourly files, 30 kept, 2GiB total, zstd-compressed. For host-level alerting on disk and container health, see our guide to monitoring your server with Beszel and Uptime Kuma.

RustFS Security Best Practices

The secrets-in-files pattern, which also keeps credentials out of docker inspect output:

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    environment:
      - RUSTFS_ACCESS_KEY_FILE=/run/secrets/rustfs_access_key
      - RUSTFS_SECRET_KEY_FILE=/run/secrets/rustfs_secret_key
    secrets:
      - rustfs_access_key
      - rustfs_secret_key

secrets:
  rustfs_access_key:
    file: ./secrets/access_key.txt
  rustfs_secret_key:
    file: ./secrets/secret_key.txt

Rules: the file’s first line is the value, empty or unreadable files are a hard startup error, and setting both RUSTFS_ACCESS_KEY and RUSTFS_ACCESS_KEY_FILE at once is also a hard error — pick one. More patterns in our Docker Compose secrets guide.

Scaling Out: Multi-Drive and Multi-Node

RustFS storage topology decision: single-node single-drive vs multi-drive vs multi-node distributed deployment

Multi-drive, single node. Point RUSTFS_VOLUMES at an ellipsis-expanded set of paths, like the official docker-compose-simple.yml:

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    volumes:
      - rustfs-data:/data
    environment:
      - RUSTFS_VOLUMES=/data/rustfs{0...3}

This gives you erasure coding across four drive paths on one server. Disk-topology checks are strict by default — paths must exist and the geometry has to match across the set. If you’re adding physical or virtual drives for this, our guide to adding a second drive with LVM covers the prep work.

Multi-node. Docker bridge networking can’t span hosts, so the official pattern uses host networking per node:

# /etc/hosts on every node:
# 192.168.1.11 node1
# 192.168.1.12 node2
# 192.168.1.13 node3
# 192.168.1.14 node4

docker run -d --name rustfs --network host \
  -v /mnt/rustfs/data:/data \
  -e RUSTFS_ACCESS_KEY=<shared access key> \
  -e RUSTFS_SECRET_KEY=<shared secret key> \
  -e RUSTFS_RPC_SECRET=<shared rpc secret> \
  -e RUSTFS_VOLUMES="http://node{1...4}:9000/data/rustfs{0...3}" \
  rustfs/rustfs:1.0.0

Key constraints: RPC rides port 9000 (no separate cluster port), so every node must reach every other node on 9000; all nodes use the same credentials; and RUSTFS_RPC_SECRET is mandatory here. This is a teaser, not a full walkthrough — the high-availability docs cover site replication, node healing, and pool decommission, and the scaling docs cover pool expansion.

Cost reality check: a 4-node, 4-drives-per-node erasure-coded cluster means at least four servers. For most solo operators that’s overkill; one node with tested offsite backups is a legitimate production choice.

Migrating from MinIO to RustFS

Two routes, and the right one depends on where your data lives.

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    volumes:
      # The existing MinIO data directory, untouched
      - /srv/minio/data:/data
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ACCESS_KEY=<same as MinIO>
      - RUSTFS_SECRET_KEY=<same as MinIO>
    ports:
      - "9000:9000"
      - "9001:9001"

# Export from MinIO
mc mirror minio/my-bucket ./backup/

# Import to RustFS
mc mirror ./backup/ rustfs/my-bucket/

After either route: mc ls both sides and diff the object counts, download one large object end to end and checksum it, and confirm buckets and users look right in the console. If you hit unreadable encrypted objects, the path is decrypt under MinIO first, then mirror across.

Conclusion: A Production-Ready MinIO Alternative

RustFS went from a promising alpha to 1.0 GA in fourteen months, and the timing worked out: MinIO archived its repository just as RustFS matured. For self-hosters, this is now the obvious default — Apache 2.0 license, S3 compatibility with a built-in console, GA distributed mode and encryption, and single-container ops that stay boring.

Key Takeaways

Next Steps

Frequently Asked Questions