#6827·rustfs

Feature request: inbound / pull replication from a generic S3 source

Author: jesseryangrahamCreated Aug 28, 2026Updated Sep 1, 2026
Labelsenhancementpriority-highfeature

This issue asks whether generic-S3 inbound replication is planned, or whether an external copier is the intended architecture.

Describe the request

RustFS bucket replication is outbound only (RustFS pushes to a remote S3 endpoint). There is no native pull: RustFS does not watch or scan a remote generic S3 bucket and import objects.

Site replication is RustFS-to-RustFS and uses a RustFS-only admin join that a generic S3 service does not implement.

Discussion #2649 is about copying to other object stores. Merged #6172 proxies GET/HEAD to outbound replication targets, which is not inbound hydrate from an external source of truth.

Environment

Live tests used a locally compiled binary, not a container image.

  • Commit: b15928220f53818164c2cd4e2c236d5c1f5aada6 (1.0.0-rc.3)

  • Binary reports: rustfs @b15928220

  • Build: debug, linux-x86_64

  • Rust compiler: 1.98.0

  • Binary SHA-256: 224b8141b9151db698831adf35b3e47581f8325b932565b2b10499fee437efe2

  • Destination: Wasabi generic S3

  • Wasabi region: us-west-1

  • Wasabi endpoint: https://s3.us-west-1.wasabisys.com

  • Docs: bucket replication (outbound), site replication (RustFS-to-RustFS)

Why it matters

A deployment that treats an external S3 store as authoritative cannot turn on RustFS replication to fill a local RustFS bucket. Hydrate has to be a separate client. A roadmap clarification would establish whether native inbound pull or an external copier is the supported design.

Ask

Is inbound / pull replication from a generic S3 source planned, or is an external copier the intended architecture?