4 backend paths make it a translator, not a storage layer
VersityGW v1.8.0 translates S3 requests for 4 backend paths: POSIX, ScoutFS, Azure Blob Storage, and another S3 service. That makes it useful when applications already speak S3 but the data must remain on storage you own. The gateway is stateless, so several instances can sit behind a load balancer without assigning buckets to a particular gateway. The backend still owns the bytes.
The scope has grown beyond a thin filesystem adapter. Release v1.8.0 added a standalone IAM service, OIDC federation work, a Helm chart for that service, static website fixes, and an RDMA service tied to NVIDIA cuObject. GitHub showed 2,939 stars and 154 open issues and pull requests combined when we fetched the repository. This is active infrastructure code, with a correspondingly wide surface to check before deployment.
Ports 7070 and 8080 make the demo easy, identity remains your job
The v1.8.0 POSIX quick start listens on port 7070 and needs two credentials plus a directory. An optional second directory keeps older object versions. You can add the browser interface on port 8080 and sign in with the same access and secret keys. That is enough to put an AWS CLI in front of a local directory and learn whether the basic translation suits your application.
In v1.8.0, production identity still takes more thought. The convenient --iam-dir mode writes account records as plain text and relies on file permissions, a limitation the documentation states directly. VersityGW also supports LDAP, Vault, S3-backed IAM, FreeIPA, and a separate IAM process. The standalone route handles users, roles, policies, access keys, and OIDC, but it is another service with its own storage, root credentials, and private connection. A Unix socket is the simpler single-host choice, while a network endpoint requires mutual TLS.
What happened when we ran it
Our sandbox installed 174 Go packages in 28 seconds. The build completed in 76 seconds, and go test finished in 43 seconds with 60 passed and 0 failed. Our measurement setup used commit c111b7d in an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Nothing in the supplied run log showed an install, compiler, or test error.
The checkout contained 974 files, about 244,303 lines of source, and occupied 9.7 MB before dependencies. We found 23 CI workflow files, a Dockerfile, and a tests directory. That is better evidence of routine project discipline than a polished quick start alone, though our 60-test run did not exercise a live Azure account, a multi-node load balancer, RDMA hardware, or each S3 client your users may bring.
Passing 60 tests does not settle every S3 edge case
Open issue 2398, filed against v1.7.0, describes uploads whose decoded bytes are correct but whose stored metadata still includes Content-Encoding: aws-chunked. Strict readers can then reject a later download. An open pull request was already addressing that report on September 16, 2026. The sequence is encouraging, but it also shows why a gateway needs client-level acceptance tests rather than a single successful upload and download.
Other open reports reach into less common paths. Issue 2309 documents a race and an HTTP 405 when one VersityGW instance using the S3 backend is chained to another using POSIX. Issue 513 asks for per-user Unix permission enforcement in multi-tenant POSIX mode. Neither report makes the common single-gateway path unusable. Both mark boundaries a storage administrator should test before exposing shared files or stacking gateways.
The README's stateless gateway does not add storage replicas
VersityGW v1.8.0 is stateless, so adding gateway instances does not replicate a one-disk POSIX backend. If that disk fails, its failure story remains a single disk. ScoutFS, Azure, or an upstream S3 service brings a different story. This distinction is VersityGW's appeal and its limit: you keep the existing storage architecture, including its backup, recovery, and consistency decisions.
The same rule applies to security boundaries. Root credentials have full authorization. TLS is optional rather than automatic, and the default S3 listener uses port 7070. The admin service can listen separately. Event delivery can target Kafka, NATS, RabbitMQ, or a webhook, yet each integration adds credentials and failure handling outside the gateway. A careful rollout starts with one backend, one client matrix, and the identity mode you intend to retain.
September activity makes a focused trial reasonable
The repository was pushed on September 16, 2026, twelve days after v1.8.0 was published. The release included IAM, OIDC, RDMA, Azure pagination, and several S3 behavior fixes. Issue and pull-request activity continued after the tag, including work on chunked upload metadata and list response fields. That combination points to active maintenance, while the 146 open issues show that compatibility work is ongoing.
VersityGW is easiest to recommend when replacing the storage backend would be the wrong project. Its 28-second install and clean 60-test result make evaluation cheap, and its backend choices cover several real migration shapes. Do not stop at the green suite. Put your SDK versions, multipart uploads, checksums, versioning rules, IAM policies, and failure recovery through the exact deployment you plan to keep.