Versity S3 Gateway
An open-source (Apache 2.0) S3-compatible gateway that translates S3 API calls into POSIX filesystem operations. A thin translation layer rather than a full object store — the underlying bytes live on NFS, XFS, ext4, or any other POSIX filesystem, and Versity surfaces them under S3 semantics. Hosted at github.com/versity/versitygw, ~2,400 stars as of April 2026.
Summary
An open-source (Apache 2.0) S3-compatible gateway that translates S3 API calls into POSIX filesystem operations. A thin translation layer rather than a full object store — the underlying bytes live on NFS, XFS, ext4, or any other POSIX filesystem, and Versity surfaces them under S3 semantics. Hosted at github.com/versity/versitygw, ~2,400 stars as of April 2026.
The "S3 facade over existing POSIX" niche. Where MinIO and RustFS are full object stores with their own on-disk layout, Versity preserves the existing filesystem and adds S3 as an access mode. The natural fit for lab clusters, HPC parallel filesystems, archival NAS, and any environment where data already lives in POSIX but downstream applications expect S3.
- Versity is not a complete object store — S3 API coverage is a deliberate subset. Don't expect feature parity with MinIO or AWS S3.
- Performance is bounded by the underlying filesystem's directory and inode performance, not by Versity itself. Large LIST operations on directories with millions of files will reflect that.
- Concurrent S3 + POSIX writes to the same path can produce surprising results — Versity does not arbitrate between the two access modes.
implementsS3 API — GET / PUT / LIST / DELETE / multipart upload subsetdepends_onPOSIX — gateway translates rather than storingalternative_toMinIO — for POSIX-backed deployments where MinIO would mean rebuilding the data layoutcompetes_withCeph — specifically the RADOS Gateway componentsolvesVendor Lock-In +solvesAGPL Licensing Risk — Apache 2.0 license, no rewrite of underlying storage
Definition
An open-source S3-compatible gateway that translates S3 API calls into POSIX filesystem operations — a thin "S3 facade" over any underlying NFS, XFS, ext4, or other POSIX-mounted storage. Apache 2.0 licensed, hosted at [github.com/versity/versitygw](https://github.com/versity/versitygw) (~2,400 stars as of April 2026). Unlike MinIO, Ceph, or RustFS — which are full object storage systems with their own on-disk layout — Versity is purely a translation layer. The actual bytes live on the underlying filesystem; Versity exposes them under S3 semantics.
Many organizations have large existing POSIX deployments (lab clusters, on-prem NAS, archive tiers, HPC parallel filesystems) that they want to expose to S3-native applications without rewriting either side. Versity fills the gap that MinIO abandoned when it went proprietary, and that newer Rust-based object stores (RustFS) don't address — those store data in their own internal format, not as POSIX files that other tools can also read.
S3-compatible bridge over existing NAS or HPC parallel filesystems, multi-protocol access (POSIX + S3) to the same dataset, S3 facade on archival / cold-storage tiers, lab and research environments where data already lives in POSIX but downstream tooling expects S3.
Recent developments
versitygw v1.6.0 (June 2026) + backup-ecosystem validation. 1.6.0 adds static website hosting (virtual-host buckets, custom error routing) and improved cross-compiled binaries on top of the multi-backend layer. Adoption catalysts stacked up this year: community-validated as a Veeam backup target (immutability, SOBR, synthetic fulls), and the ScoutAM S3-to-tape pairing landed an exascale archive win at the Texas Advanced Computing Center — tape behind an S3 endpoint, with a perpetual free read license so archives never ransom their own data. Per versity/versitygw releases, Veeam community validation thread, and Versity — S3-to-tape deep dive.
Direct key→path translation: object
reports/2026/january.csvlands at exactly that relative POSIX path. No encoding, no indirection, no proprietary on-disk layout — the data is also readable by every POSIX-aware tool on the same volume. The clearest differentiator vs MinIO/Ceph/RustFS (all of which use opaque internal storage formats). Per Versity Blog — How Versity S3 Gateway Maps Object Keys to POSIX File Paths.Built from scratch in Go; completely stateless deployment. Multiple Versity Gateway instances deploy in a cluster to scale aggregate throughput — "zero communication stateless design" gives near-perfect horizontal scalability up to backend-storage limits. Per Versity — Analyzing Scale-Out Performance.
Multi-backend support: generic POSIX, Versity's ScoutFS, Azure Blob, other S3 servers. Versity is a translation layer, not a storage system — it can sit in front of ScoutFS (Versity's archival filesystem) for HSM workflows, Azure Blob for cross-cloud, or other S3 servers for migration/replication scenarios. Per Versity — VersityGW product page.
TrueNAS Apps Market integration. Versity Gateway now ships as a one-click TrueNAS app — installs and exposes any TrueNAS dataset as an S3 endpoint without a separate VM/container. Brings S3-on-NAS to the self-hosted SMB/lab audience. Per TrueNAS Apps Market — Versity Gateway.
"I Just Want Simple S3" use case is the 2026 distribution wedge. Independent dev write-ups (Feld blog April 2026) frame Versity as the answer to "I have a filesystem, I want S3 semantics over it, no other commitments" — the lighter-weight alternative to running a full Ceph or MinIO cluster. Per Feld — I Just Want Simple S3 (April 2026).
Apache 2.0 license — full enterprise OSS compatibility. Avoids the AGPL friction that pushed enterprise adoption off MinIO; permissive license clears the same procurement gauntlet that Linux/Apache-licensed infrastructure tools do. Per GitHub — versity/versitygw.
Production case study: Healthchecks.io moved off managed cloud storage entirely to Versity. Facing performance and reliability issues with AWS S3, OVHcloud, and UpCloud, Healthchecks.io migrated to self-hosted object storage fronted by Versity S3 Gateway — chosen over MinIO and SeaweedFS for simplicity — running on a dedicated server with NVMe RAID1 + Btrfs behind a WireGuard tunnel. At migration, the deployment served 14M objects (119GB) at up to 150 uploads/sec peak. Per Healthchecks.io — Now Uses Self-Hosted Object Storage.
CERN is evaluating VersityGW alongside MinIO, S3Proxy, and XrdS3 as S3 storage middleware. CERN presentations on S3 storage middleware benchmarking include VersityGW as one of the candidates under joint evaluation, with an open call for volunteers to help stand up test instances — the same national-lab/HPC-adjacent adoption pattern already noted for Sandia and Los Alamos. Per CERN Indico — S3 Gateway for EOS and CERN video — Performance Benchmarks of S3 Storage Middleware.
Scale-out numbers behind the "near-linear scaling" claim. Versity's own scale-out testing: 1MB uploads went from 1,238 MB/s on a single gateway to 6,152 MB/s across five (near-linear), and HEAD request throughput scaled from 9,704 req/s to 48,048 req/s (linear) — the concrete benchmark data behind the stateless-cluster claim already on the node. Per Versity — Analyzing the Versity S3 Gateway's Scale-Out Performance. Sources: GitHub — versity/versitygw · Versity — VersityGW product page · Versity Blog — Object Keys to POSIX File Paths · Versity — Scale-Out Performance Analysis · TrueNAS — Versity Gateway app
Connections 7
Outbound 7
scoped_to2implements1alternative_to1competes_with1Resources 3
Apache 2.0 S3-compatible gateway that exposes any POSIX filesystem as S3. The "S3 facade over POSIX" niche that full object stores like MinIO and RustFS do not address.
v1.4.1 release notes (April 22, 2026) — improved multipart upload support and expanded S3 API coverage. Authoritative source for what the current release actually delivers vs roadmap claims.
Versity Software's commercial site — context on the vendor backing the open-source gateway (their commercial product is a different scale-out object storage system; the gateway is the Apache 2.0 piece).