RustFS

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

RustFS is S3-compatible object storage written in Rust and released under the Apache-2.0 licence. In TractorStack it gives you an S3 endpoint on your own disks, so backups, build artifacts and files have somewhere to go that isn’t a public cloud.

Why object storage at all

Many tools already speak S3: pgBackRest, CloudNativePG, container registries, log stores and most application libraries. Putting an S3 endpoint in from stage 1 means files and backups never sit on a local disk that a later stage has to dig out. It is one of the Kubernetes-ready rules.

Planned buckets

Bucket	Holds
`backups`	pgBackRest backups and WAL archive for PostgreSQL
`artifacts`	Build outputs, release bundles, application files
`evidence`	Compliance evidence, with object lock Exploring
`mirrors`	Offline copies of packages, images and OpenTofu providers Planned

Role in each stage

Stage 1: a single RustFS instance on the same host, on a separate disk or volume where possible.
Stage 2: RustFS on its own disks, with backups copied off-site, for example to a rack in a Tier III colocation facility.
Stage 3: unchanged, on an Ansible-managed VM outside the cluster.
Stage 4: RustFS as a StatefulSet on dedicated storage nodes. Exploring

Planned configuration

A planned example of how buckets could be declared in the repository for Ansible to create. Illustrative only.

# Planned example only: ansible/group_vars/storage.yml
rustfs_data_dirs:
  - /srv/rustfs/disk1
  - /srv/rustfs/disk2
rustfs_buckets:
  - name: backups
    versioning: true
  - name: artifacts
  - name: evidence
    object_lock: true
offsite_copy:
  bucket: backups
  target: s3://offsite.example.net/backups

Off-site replication

Copies on the same site don’t help in a fire or a flood. From stage 2 the design copies the backups bucket to a second S3 endpoint off-site, either another RustFS instance or any S3-compatible target you already run. The copy job is planned to be one of the routine checks, with its last success shown on the status report. See backups.

Maturity caveat

RustFS is a young project. Before relying on it in production, check its current release status and changelog. TractorStack will only say it is ready for a given use once we have tested it there ourselves.

To keep that risk small, the design uses only the standard S3 API: buckets, objects, versioning, lifecycle and object lock. Nothing in TractorStack is planned to depend on RustFS-specific features, so the storage can be swapped for another S3-compatible server such as MinIO, Garage, SeaweedFS or Ceph RGW. Each has its own trade-offs and licence terms, which are worth checking for your case. Swapping means copying the buckets across and changing an endpoint, not changing applications.

What stays yours

The disks and every object on them
Access keys, generated on your site and kept in your secret store
The choice of off-site location

Limits and caveats

A single-node instance has no redundancy beyond what the disks give it. Off-site copies matter.
Object lock protects evidence from deletion only if the clock and the admin accounts are protected too.
S3 compatibility is never perfect across products. Test the exact features you use before a swap.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com