Self-Hosted S3 Alternatives in 2026 (RustFS, Garage, SeaweedFS, Ceph)
Choosing self-hosted S3 after MinIO
Amazon S3 has become the de facto API for object storage. After the open source MinIO repository was archived in April 2026, seven credible self-hosted alternatives remain.
These options are not interchangeable. Some are full object-storage engines that own their data layout; others are thin gateways that expose files you already have. That split — native store versus filesystem-backed gateway — decides more about backups, recovery, and migrations than any feature list does.
This article compares RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy, and rclone. Each section covers the storage model, the S3 feature coverage, where the project fits, and the limitation that usually decides the choice. A decision guide for single-server and multi-server deployments closes the article.
For the broader picture — object storage, databases, search, and AI-native data layers — see the Data Infrastructure for AI Systems.
Self-Hosted S3 Storage Comparison
The most important question is whether you need a distributed object store or an S3 interface in front of storage that already exists.
| Software | Storage model | Distributed | S3 compatibility | Plain files on disk | Complexity | Best use |
|---|---|---|---|---|---|---|
| RustFS | Native object store | Yes | High, tested subset | No | Low to medium | General MinIO replacement |
| Garage | Native object store | Yes | Good, narrower API | No | Low to medium | Small distributed clusters |
| SeaweedFS | Distributed blob and file store | Yes | High | No | Medium | Huge file counts and mixed storage |
| Ceph RGW | Ceph object gateway | Yes | High | No | High | Large storage infrastructure |
| VersityGW | S3 gateway over POSIX | Backend dependent | Good | Yes | Low | S3 over normal files |
| S3Proxy | S3 translation layer | Backend dependent | Moderate | Yes with filesystem-nio2 | Medium | Gateway and protocol translation |
| rclone serve s3 | S3 gateway | Backend dependent | Basic, experimental | Yes with local backend | Very low | Simple and lightweight deployments |
RustFS is the closest direct replacement for a conventional MinIO deployment. Garage fits small distributed clusters. SeaweedFS and Ceph solve broader storage problems. VersityGW can expose an existing POSIX filesystem through S3 while leaving the object payloads as ordinary files. For a feature-by-feature matrix of Garage, MinIO, and AWS S3, see Garage vs MinIO vs AWS S3.
Two Different Types of S3 Storage
A native object store owns its storage layout:
RustFS, Garage, Ceph RGW, and SeaweedFS belong to this family. The files visible on the underlying disks are implementation details, and applications should not manipulate them directly.
A filesystem-backed S3 gateway has a different relationship with storage:
With software such as VersityGW, the filesystem can remain the authoritative representation. An object such as:
s3://archive/documents/2026/report.pdf
can correspond directly to:
/storage/archive/documents/2026/report.pdf
RustFS: The Closest MinIO Replacement
RustFS is a distributed object storage system written in Rust and released under the Apache-2.0 license. It provides an S3-oriented operating model familiar to MinIO users, which makes it the first project to evaluate when replacing MinIO.
Its current S3 implementation covers the operations most applications expect: buckets, objects, multipart uploads, conditional requests, object metadata, tags, versioning, lifecycle management, object lock, presigned URLs, bucket policies, CORS, notifications, replication configuration, and server-side encryption.
RustFS publishes an S3 compatibility matrix that is a tested subset, not a claim of complete Amazon S3 coverage. The snapshot verified against commit 1e6f5f1e on 9 August 2026 lists 455 implemented standard tests, 5 lifecycle-behavior tests, 17 unimplemented standard tests, and 270 excluded cases that do not block the compatibility gate. The executable lists under scripts/s3-tests are the source of truth when those counts move.
Where RustFS fits
RustFS is a candidate when an application expects a proper S3 object store.
Typical uses include application object storage, backup repositories, media storage, AI and data-pipeline artifacts, internal S3 infrastructure, Kubernetes workloads, and replacement of existing MinIO endpoints.
It works with AWS SDKs and common S3 clients. Applications normally need a custom endpoint, credentials, region settings where required, and path-style addressing.
The important limitation
RustFS owns the storage representation. The files below its data directory are RustFS internals.
That makes RustFS the wrong answer when the requirement is that every S3 object remain an ordinary file you can inspect, copy, rsync, or recover without the object-storage software. That requirement selects a filesystem-backed gateway.
Garage: Distributed S3 Without Ceph-Scale Complexity
Garage is an S3-compatible distributed object store for small and medium self-hosted installations. Deuxfleurs develops it under the AGPL v3 licence and has run it in production since the project’s initial releases in 2020.
Garage is built to run across several ordinary servers, including servers in different physical locations. Replication is part of the design.
Garage is attractive when you have three small servers rather than a rack of dedicated storage hardware. A working setup path, from Docker through cluster layout, replication, and TLS via a reverse proxy, is in the Garage quickstart.
Where Garage fits
Garage makes sense for homelabs, small hosting platforms, geographically distributed servers, replicated backups, and clusters where Ceph would be excessive.
Its scope is narrower than AWS S3. Garage’s compatibility table leaves out bucket policies, ACLs, and bucket versioning. Choose Garage over RustFS when lightweight multi-node replication is the primary requirement. Choose RustFS when broader S3 behavior and MinIO-like application compatibility matter more.
SeaweedFS: More Than an Object Store
SeaweedFS started by storing enormous numbers of files efficiently. It is now a distributed storage platform exposing S3, a FUSE filesystem, WebDAV, SFTP, and HDFS. SeaweedFS 4.48 was released on 28 September 2026.
Volume servers pack blobs into append-only volume files. Masters track volumes rather than individual files. A filer provides hierarchical filesystem semantics. The design targets workloads with millions or billions of relatively small objects.
S3 support
SeaweedFS documents versioning, object lock, lifecycle rules, tagging, CORS, checksums, presigned URLs, multipart uploads, bucket policies, IAM, STS, and several server-side encryption modes.
The same cluster can serve S3 table buckets and a built-in Iceberg REST catalog, so Spark, Trino, DuckDB, and similar engines can use Iceberg tables without a separate Hive Metastore or Glue. The project’s one-command S3 example listens on port 8333.
Where SeaweedFS fits
Consider SeaweedFS for web crawlers and archives, image and document repositories, billions of small objects, data lakes, mixed S3 and filesystem workloads, and storage that grows by adding volume servers.
There are more components to understand than in a straightforward RustFS installation. SeaweedFS can provide filesystem semantics through its filer and FUSE mount, but objects are stored inside its volume format. It does not satisfy the requirement that every S3 object remain an independent ordinary file on the host filesystem.
Ceph RGW: The Infrastructure-Scale Option
Ceph is broader than S3 storage. A cluster can provide block devices through RBD, a filesystem through CephFS, and object storage through RADOS Gateway (RGW). RGW presents an S3-compatible API backed by RADOS.
Ceph supports replication, erasure coding, failure domains, multiple gateways, multisite deployments, access policies, and cluster management tooling.
Where Ceph fits
Ceph makes sense when object storage is one part of a larger storage platform: Kubernetes persistent volumes, virtual-machine disks, shared filesystems, large S3 repositories, and clusters that need explicit failure domains.
For a single server with several terabytes, installing Ceph only to obtain an S3 endpoint is difficult to justify. If you already operate Ceph, RGW is the obvious S3 choice. If you do not, RustFS or Garage reaches useful object storage with less machinery.
VersityGW: S3 Over Ordinary Files
VersityGW is the option to evaluate when the filesystem itself matters. It is an Apache-2.0 licensed S3 gateway that can expose POSIX filesystems, ScoutFS, Azure Blob Storage, other S3 services, and custom backends.
Its POSIX backend maps S3 buckets and objects onto directories and files. For example:
s3://website-assets/images/logo.png
maps to a path such as:
/storage/website-assets/images/logo.png
The logo.png payload remains a normal file.
Why plain files are useful
You can inspect storage with ordinary Unix tools:
find /storage -type f
du -sh /storage/*
You can read an object without the S3 server:
cat /storage/archive/2026/source.html
Conventional filesystem backup tools apply directly: rsync, restic, borg, tar, and zfs send. If the gateway software disappears, the payloads are still files in a directory tree.
S3 metadata on a POSIX backend
S3 metadata does not fit in a POSIX file by itself. VersityGW stores it in extended attributes by default. Since March 2026, object metadata is a single user.metadata xattr holding JSON, because one xattr per key hit filesystem key-length limits. A versitygw utils convert-xattr-metadata command rewrites older per-key attributes. Reads still fall back to the old layout when user.metadata is absent.
Filesystems without xattrs can use --sidecar (or VGW_META_SIDECAR) to keep metadata in a separate directory tree. The project marks sidecar and --nometa as less tested than xattrs. --nometa disables metadata storage and is aimed at read-only hosting of a dataset that already exists; bucket policies and ACLs are metadata, so they are unavailable in that mode.
Object versions can live in a separate directory. The project’s POSIX example passes --versioning-dir for older versions while the current payload stays at its natural path.
Changing a file behind the gateway can leave S3 metadata, including ETags, inconsistent with the new bytes. A workable operating model is:
Application access:
Read through S3
Write through S3
Administrator access:
Read the filesystem directly
Inspect the filesystem directly
Back up the filesystem directly
Avoid modifying objects behind the gateway
VersityGW 1.8.0, already the version a September 2026 COSI driver release targeted, adds a standalone IAM service (versitygw iam), STS AssumeRoleWithWebIdentity, and IAM policy conditions.
S3Proxy: A General Translation Layer
S3Proxy implements the S3 API and translates requests onto several backends: local files, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP, and other S3 services. It requires Java 17 or newer.
The recommended on-disk provider is filesystem-nio2. The older filesystem provider is deprecated. Object keys become filesystem paths, and metadata uses user extended attributes, so the payloads stay ordinary files.
The filesystem backend refuses object versioning and server-side encryption. Versioning stays unsupported (supportsVersioning() is false, and those requests remain HTTP 501) because a version layout written to a real disk would become a format the project would have to keep. Server-side encryption is refused for the same class of reason: reporting AES256 over a plaintext file someone can read would be a false claim. The in-memory transient-nio2 backend implements both, and the data dies with the process. The project README also lists bucket policies, object tagging, and ACLs other than private and public-read as unsupported.
S3Proxy is the tool when you need that translation across backends. For a straightforward S3-to-POSIX gateway, VersityGW is the smaller surface.
rclone serve s3: Lightweight but Experimental
rclone serve s3 exposes an rclone backend through an S3-compatible API. The documentation still labels the command experimental.
For a local filesystem:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Without --addr, the server binds 127.0.0.1:8080. --auth-key enables Signature Version 4. Multipart uploads are written in part-number order to a temporary object and renamed into place on completion, so a failed upload does not replace an existing object.
Objects written through a local backend become files under that path. The same command can sit in front of other rclone remotes. It is a reasonable choice for internal tooling, a lab, or a temporary migration hop. It is a weak permanent S3 layer for many unrelated production applications.
What About MinIO?
The MinIO GitHub repository was archived on 13 February 2026, briefly unarchived, and archived again on 25 April 2026. It is read-only. The repository notice points operators at AIStor, MinIO’s commercial distribution, and states that the community edition is source-only.
An existing MinIO deployment can keep running, particularly when it is isolated and its behavior is already understood. The full timeline, the operational risk, and a phased migration plan are in MinIO CE in 2026.
For the S3 behavior of the system you may be leaving, MinIO as an AWS S3 alternative documents how MinIO maps onto S3. The MinIO command line cheatsheet is the audit companion for a cluster that is still up. For a new installation, an actively maintained alternative is the default.
Plain Files vs Native Object Storage
Use RustFS, Garage, SeaweedFS, or Ceph when the object store should control durability, metadata, distribution, and layout. That buys richer S3 semantics, replication or erasure coding, horizontal scaling, and versioning where the project implements it. The cost is dependence on the engine’s on-disk representation.
Use VersityGW, S3Proxy, or rclone when an existing filesystem should remain authoritative. That buys plain recoverable files, conventional backups, direct inspection, and compatibility with ZFS, XFS, ext4, and NFS. Distributed durability then has to come from the filesystem or the storage array, not from the S3 process. On a single server or a NAS, that trade is often the right one.
Choosing the Right Self-Hosted S3 Server
For a single server that should resemble MinIO, start with RustFS.
For three or more modest servers where replication is the main requirement, and the application can live without bucket policies and versioning, choose Garage.
For enormous numbers of small objects, mixed filesystem access, or a data-lake workload that may grow into Iceberg tables, consider SeaweedFS.
When the same cluster must also provide block devices and a distributed filesystem, choose Ceph RGW.
When the requirement is specifically an S3 API over ordinary files — a NAS, an archive, a document repository, a crawler, or a backup target — start with VersityGW.
When the job is translating S3 onto Azure, GCS, Swift, SFTP, or another S3 service, use S3Proxy.
When the deployment is small, temporary, and can tolerate an experimental server, rclone serve s3 may be enough.
Recommended Architecture for a Single Storage Server
If applications should reach the data only through S3, RustFS owns the object layer and the filesystem is an implementation detail:
If the files themselves must survive the gateway, keep the data in a POSIX tree:
In the second design, redundancy is a ZFS mirror, RAID, snapshots, filesystem replication, or a conventional backup tool. The S3 service can be replaced without rewriting the data format.
Final Thoughts
Maintained self-hosted S3 still exists after MinIO’s public repository went read-only. The choice that matters is whether S3 owns the bytes or only fronts files that already exist. Every comparison above follows from that answer.
