// the find
versity/versitygw
A simple to deploy but feature rich S3 object storage server for your filesystem
versitygw is a stateless S3 API gateway that sits in front of any POSIX filesystem, Azure Blob, or another S3 server and translates S3 requests into native backend operations. It's aimed at teams who already have NFS/local storage or ScoutFS and want S3 compatibility without migrating data. You get real S3 auth (SigV4), versioning, object lock, multipart, and event notifications on top of a plain directory.
The stateless design is the right call — you can run multiple instances behind a load balancer with no coordination layer, which is how you actually scale this kind of gateway. The backend abstraction is clean enough that ScoutFS, Azure Blob, and plain POSIX share the same interface, and the plugin system (see plugins/noop) lets you add backends without touching core code. Test coverage is unusually thorough for an infrastructure project: unit tests with race detection, BATS shell scripts against real S3 clients (AWS CLI, s3cmd, curl), functional tests across all backends, and govulncheck in CI. Event notifications via Kafka, NATS, RabbitMQ, and webhook are a real differentiator — most S3-compatible servers skip this entirely.
IAM is the weak link. The flat JSON file mode is fine for dev, but the LDAP and IPA integrations are thin and the Vault backend delegates trust in ways that aren't obvious from the docs. Anyone running this in production with multiple teams will hit IAM limitations fast. The POSIX backend has a fundamental impedance mismatch with S3 semantics around consistency: S3 list-after-write consistency doesn't map cleanly to filesystem directory reads, and the code has to work around this in ways that can surprise you under concurrent load. S3 Select support (s3select/ directory) appears incomplete — it has arch-split files but no actual SQL parsing visible in the tree, so anything relying on SELECT queries on objects will silently fail or return errors.