Evaluate RustFS as the default Apache-2.0 S3 backend for self-hosted deployments

Summary

Buzz currently ships MinIO in docker-compose.yml as the local S3-compatible backend for media/object storage.

I would like to suggest evaluating RustFS as either:

the default object-storage service for local and self-hosted deployments, or
a first-class supported alternative through a Docker Compose profile.

RustFS is an S3-compatible object store written in Rust and released under the Apache-2.0 license.

Why this may be a good fit for Buzz

License alignment: Buzz and RustFS are both Apache-2.0 projects, which gives self-hosters, downstream distributors, and commercial users a straightforward permissive licensing model.
Rust-based implementation: RustFS fits naturally with Buzz's Rust-heavy architecture and memory-safety goals.
S3-compatible interface: Buzz already uses a configurable S3 endpoint and path-style access through rust-s3, so the application-level integration should remain storage-vendor-neutral.
Operational simplicity: RustFS uses the familiar S3 API and the standard 9000/9001 API and console ports, making it relatively easy to evaluate in the existing Compose setup.
Backend diversity: Supporting RustFS would reduce reliance on a single local S3 implementation while preserving compatibility with AWS S3 and other S3-compatible services.

Relevant Buzz files:

Our experience with RustFS

At Kubedo.io, we currently use RustFS as the default S3-compatible backend in two Apache-2.0 Rust projects:

RustChat

Repository: https://github.com/kubedoio/rustchat

RustChat uses RustFS for uploaded files and media through a normal S3-compatible endpoint. The default Docker Compose deployment starts RustFS alongside PostgreSQL, Redis, and the Rust backend:

https://github.com/kubedoio/rustchat/blob/main/docker-compose.yml

RustShare

Repository: https://github.com/kubedoio/rustshare

RustShare uses RustFS for durable file content and S3-based storage workflows, including uploads, downloads, versioned content, sharing flows, integrity-oriented object layouts, and backup/restore tooling:

Our experience so far has been positive in development and pilot-oriented environments. Standard S3 operations have worked reliably for our use cases, integration with Rust services has been straightforward, and the deployment model has been easy to operate.

To be precise, this is not a claim that we have validated every RustFS feature at internet scale. It is practical experience from two actively developed self-hosted applications using RustFS for real file and object-storage workflows.

Suggested implementation approach

I would suggest introducing RustFS incrementally:

Add a rustfs Docker Compose service or profile using a pinned RustFS version or image digest.
Keep Buzz's existing BUZZ_S3_* configuration and storage abstraction unchanged.
Configure the bucket, credentials, persistent volume, and health check for RustFS.
Use an S3-neutral bootstrap method for bucket creation, or retain minio/mc if it passes compatibility testing against RustFS.
Run Buzz's object-store conformance tests against RustFS before making it the default.
Keep MinIO available as an optional profile until compatibility is fully demonstrated.

The validation should cover at least:

bucket creation and startup bootstrap
PUT, GET, HEAD, and DELETE
streaming uploads and downloads
byte-range GETs used for media
multipart uploads
paginated object listing
object tags and metadata
conditional requests such as If-Match / If-None-Match
restart and volume-persistence behavior
existing media and git/object-store conformance tests

Acceptance criteria

docker compose up can start Buzz with RustFS and create the required bucket automatically.
Existing Buzz object-storage and media tests pass without MinIO-specific assumptions.
The deployment documentation explains how to select RustFS, MinIO, or an external S3-compatible endpoint.
RustFS can become the default only after the existing conformance suite passes consistently.

I would be happy to help prepare or test a proof-of-concept Compose change if the maintainers are interested.

This just became a hard blocker, not a nice-to-have

Confirmed today: quay.io/minio/minio and quay.io/minio/mc reject anonymous pulls entirely, not just on stale digests.

$ curl -sS -o /dev/null -w "%{http_code}\n" \
    "https://quay.io/v2/minio/minio/manifests/RELEASE.2025-09-07T16-13-09Z" \
    -H "Accept: application/vnd.docker.distribution.manifest.v2+json"
401

$ curl -sS "https://quay.io/api/v1/repository/minio/minio/tag/?limit=5" 2>&1
{"detail":"Requires authentication","error_type":"invalid_token","status":401}

Same 401 on quay.io/minio/mc. Docker Hub mirrors (minio/minio, bitnami/minio) return "object not found" — gone, not just rate-limited.

Net effect: just setup fails at the minio image pull step for anyone cloning today, with no workaround short of an authenticated MinIO account (if that's even offered for the OSS images anymore).

RustFS drop-in, tried it against this exact compose file

Swapped minio → rustfs/rustfs:latest (confirmed pullable, 186 active tags on Docker Hub incl. arm64) and minio-init's mc → amazon/aws-cli:latest (also quay.io-free, 988 tags) for the bucket-creation step. Kept the container name, ports, and buzz_dev/buzz_dev_secret credentials identical, so .env and buzz-media needed zero changes.

minio:
  image: rustfs/rustfs:latest
  environment:
    RUSTFS_ADDRESS: "0.0.0.0:9000"
    RUSTFS_CONSOLE_ADDRESS: "0.0.0.0:9001"
    RUSTFS_VOLUMES: "/data"
    RUSTFS_ACCESS_KEY: buzz_dev
    RUSTFS_SECRET_KEY: buzz_dev_secret
    RUSTFS_UNSAFE_BYPASS_DISK_CHECK: "true"  # single bind mount, not RustFS's usual multi-disk layout
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:9000/health"]  # RustFS's health path, not /minio/health/live

minio-init:
  image: amazon/aws-cli:latest
  entrypoint: >
    /bin/sh -c "aws --endpoint-url http://minio:9000 s3 mb s3://buzz-media || true"

What I verified: docker compose up — buzz-minio (RustFS) reaches Up (healthy) on the S3 API healthcheck. Confirmed via docker ps.

What I have not verified: the full buzz-media upload/download path against RustFS specifically (media tests, git CAS blob storage) — only that the container starts healthy and speaks the S3 API surface mc/aws s3 mb expects. RUSTFS_UNSAFE_BYPASS_DISK_CHECK is exactly what the name says — fine for a single-node dev compose, not how RustFS wants to run in general.

Not opening a PR per the "dependency swap needs a prior agreed direction" note in CONTRIBUTING — this comment is diagnostic + a working starting point if the direction here is RustFS specifically. Happy to open one once there's a nod on approach, with actual media-path test coverage added first.

we never used minio since 3 months of our implementation of buzz, so I am confident it can be easily replaced.

I opened a focused upstream PR: #7875

It replaces the default/local/CI/production Compose MinIO runtime with RustFS 1.0.0, pinned by digest, and replaces mc bootstrap with the pinned RustFS rc client. Buzz keeps the existing BUZZ_S3_* contract and rust-s3 storage path unchanged.

Validation against fresh RustFS Compose projects is green:

media static-credential round-trip: 1 passed;
Git/CAS probe: 4 passed, including conditional-write/412 behavior, full round-trip, ETag exposure, and the concurrent probe;
root, CI override, harness, and production Compose bootstrap/config checks: passed;
format, media clippy, and 127 media unit tests: passed.

The Helm quickstart MinIO topology is intentionally left for a separate migration because its chart templates and CI fixtures use MinIO-specific service/client assumptions.

@tlongwell-block

@tlongwell-block — I noticed #7869/#7870 have now solved the MinIO image-availability problem with the Block-maintained buzz-minio image.

That changes the original motivation for #7875, so rather than fight the new upstream direction I’d like to rebase and narrow it.

Would you be open to RustFS being supported as an optional S3-compatible Compose backend/profile, while keeping the current MinIO path as the default?

The existing #7875 work already validates RustFS against Buzz media and Git/CAS behavior, including conditional writes, versioned-object behavior, bootstrap, restart, and the existing BUZZ_S3_* contract.

If that direction makes sense, I’ll preserve #7869/#7870, rebase #7875 onto current main, reduce the diff to the RustFS-specific pieces, and request review on that version.

Navigation Menu

Repository navigation

Evaluate RustFS as the default Apache-2.0 S3 backend for self-hosted deployments #2618

Summary

Why this may be a good fit for Buzz

Our experience with RustFS

RustChat

RustShare

Suggested implementation approach

Acceptance criteria

This just became a hard blocker, not a nice-to-have

RustFS drop-in, tried it against this exact compose file

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Evaluate RustFS as the default Apache-2.0 S3 backend for self-hosted deployments #2618

Description

Summary

Why this may be a good fit for Buzz

Our experience with RustFS

RustChat

RustShare

Suggested implementation approach

Acceptance criteria

Activity

myshag commented on Sep 24, 2026

This just became a hard blocker, not a nice-to-have

RustFS drop-in, tried it against this exact compose file

senolcolak commented on Sep 24, 2026

zoorpha commented on Sep 24, 2026

zoorpha commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions