VersityGW is an S3 gateway: it speaks the Amazon S3 API on the front and translates every call into operations on whatever storage you already have underneath. Point it at a directory on a local filesystem, at Versity’s own ScoutFS parallel filesystem, at Azure Blob Storage or at another S3 endpoint, and the applications that only know how to talk S3 can use that storage without being modified. Files stay ordinary POSIX files where the backend is a filesystem, so the same data is reachable over S3 and through normal file access.

How it works

The gateway is stateless. Incoming S3 requests are resolved, signed and rewritten into backend calls; no index or metadata database sits in the middle, which means several gateway instances can run behind a load balancer and any of them can serve any request. It is written in Go, uses the Fiber HTTP framework for routing and the official AWS SDK for S3 semantics, so bucket and object behaviour follows real S3 rather than an approximation.

What it supports

• Bucket and object operations against a POSIX backend, ScoutFS, Azure Blob Storage or a remote S3 server.
• Bucket versioning with a separate versions directory on the filesystem backend, plus object lock for write-once workloads.
• Optional user management: a built-in IAM service with users, roles, access keys and a JSON flat-file mode that suits testing and small deployments, or the admin API for a real deployment.
• Static website hosting from buckets, with index documents, custom error pages and virtual-host style routing enabled separately from the S3 endpoint.
• S3 over RDMA for high-throughput HPC and data-intensive transfers, bypassing the kernel network stack.
• An optional WebGUI with a dashboard, user and bucket administration and a file explorer, switched on only when a WebUI listen address is supplied.

Deployment

Single static binaries are published for Linux, macOS, BSD and Windows on amd64 and arm64, with .deb and .rpm packages for the Linux side and a container image for Docker. A working gateway needs nothing more than a directory to serve: set ROOT_ACCESS_KEY and ROOT_SECRET_KEY, then run versitygw --port :7070 posix /srv/objects and an S3 endpoint is listening. Add --webui :7071 for the browser interface and --iam-dir for multiple accounts. Operational tuning around it — TLS certificates, a reverse proxy, systemd units, or a cluster of stateless instances behind a balancer — is ordinary server work, because the gateway itself keeps no state to coordinate.

Good fit for

Making an existing filesystem or HPC scratch tier reachable by S3-only tooling, replacing a single-node object store where object data should stay visible as plain files, fronting Azure Blob or another S3 provider for applications that expect AWS semantics, or serving static sites straight from buckets that live on local disks.

Alternatives

• SeaweedFS — object store built around its own volume servers, with an S3 gateway and a fast metadata layer.
• Garage — small self-hosted S3 store designed for geo-distributed clusters on modest hardware.
• Rclone — not a server, but the practical companion for mounting, syncing and moving objects across backends.

VersityGW is Apache-2.0 licensed and commercially supported by Versity, which also maintains the open source ScoutFS filesystem it can sit in front of.