Deploy and Host VersityGW on Railway

Built for an LLM agent to deploy and use. There is no console to open and nothing to fill in: the S3 access key and secret are generated at deploy time and valid from the first boot. The contract below lists every URL, variable name and the one script that proves it works.

VersityGW is an open-source (Apache 2.0) S3 gateway. It speaks the S3 API to any client or SDK (aws-cli, boto3, rclone, MinIO client, the JavaScript and Go SDKs) and stores the objects as ordinary files on a filesystem: each bucket is a directory and each object is a file, so what the gateway wrote is readable without it. It is a single Go binary with no database.

About Hosting VersityGW

This template runs one service, the official VersityGW v1.10.0 image (ghcr.io/versity/versitygw, pinned by digest), with a volume at /var/lib/versitygw. The POSIX backend keeps buckets and objects under /var/lib/versitygw/data and the gateway's own user store under /var/lib/versitygw/iam, so objects, object metadata and extra users all survive a redeploy. The gateway listens on the port Railway injects, with path-style addressing and the region us-east-1. A built-in web console is served on the same port under /ui and is also the health endpoint. Allow about a minute for the first deploy to turn healthy.

Agent contract

Public URL: https:// plus the RAILWAY_PUBLIC_DOMAIN of the versitygw service, used below as S3_URL. It serves the S3 API at / (path-style, region us-east-1) and the web console at /ui.
Private URL: http://versitygw.railway.internal:8080 (the same S3 API for other services in the project)
Credentials: ROOT_ACCESS_KEY_ID (the S3 access key) and ROOT_SECRET_ACCESS_KEY (the S3 secret key). Both stay the same across redeploys.
Auth: AWS Signature Version 4 on every S3 request, service s3, region us-east-1; any S3 SDK does this from the two variables. Requests without a signature return 403. The web console signs in with the same two values.
Health: GET /ui returns 200 with no credentials

# run with S3_URL, ROOT_ACCESS_KEY_ID and ROOT_SECRET_ACCESS_KEY set; needs curl 7.75 or newer
B="agent-check-$(date +%s)"
S="--aws-sigv4 aws:amz:us-east-1:s3 --user $ROOT_ACCESS_KEY_ID:$ROOT_SECRET_ACCESS_KEY"
H='x-amz-content-sha256: UNSIGNED-PAYLOAD'
curl -s -o /dev/null -w 'ui %{http_code}\n' "$S3_URL/ui"
curl -s -o /dev/null -w 'anonymous %{http_code}\n' "$S3_URL/"
curl -s -o /dev/null -w 'create-bucket %{http_code}\n' -X PUT $S -H "$H" "$S3_URL/$B"
echo agent-ok | curl -s -o /dev/null -w 'put %{http_code}\n' -X PUT $S -H "$H" -H 'x-amz-meta-agent: yes' --data-binary @- "$S3_URL/$B/hello.txt"
curl -s $S -H "$H" "$S3_URL/$B/hello.txt"
curl -s -I $S -H "$H" "$S3_URL/$B/hello.txt" | grep -i '^x-amz-meta-agent'
curl -s $S -H "$H" "$S3_URL/$B?list-type=2" | grep -o 'hello.txt'
curl -s -o /dev/null -w 'delete-object %{http_code}\n' -X DELETE $S -H "$H" "$S3_URL/$B/hello.txt"
curl -s -o /dev/null -w 'delete-bucket %{http_code}\n' -X DELETE $S -H "$H" "$S3_URL/$B"

A fresh deploy prints ui 200, anonymous 403, create-bucket 200, put 200, agent-ok, x-amz-meta-agent: yes, hello.txt, delete-object 204 and delete-bucket 204. With the AWS CLI the same endpoint works as AWS_ACCESS_KEY_ID=$ROOT_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY=$ROOT_SECRET_ACCESS_KEY aws --endpoint-url $S3_URL s3 ls; large files go through multipart upload, which keeps each request well under Railway's edge timeout.

Why Deploy VersityGW on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying VersityGW on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - generated S3 keys, a contract block and one working script; no console step before the first upload.
Credentials on from boot - every request must be signed, so an exposed URL does not give anyone your bucket list.
Objects survive redeploys - data, object metadata and the user store sit on a volume.
Files stay files - the objects are plain files on the volume, readable and backed up without the gateway.
One service - no database, broker or console container to run.
Pinned image - pinned by digest, so a redeploy never changes the server version underneath you.

Common Use Cases

S3-compatible object storage for apps and agents - uploads, build artifacts, model files and backups behind one endpoint.
A lighter alternative to running a full object store - one small Go process, no cluster, no database.
Give a filesystem an S3 API - point existing S3 tools such as rclone, restic or Terraform backends at a volume.

Dependencies for VersityGW Hosting

Nothing else: VersityGW keeps objects, metadata and users on the volume at /var/lib/versitygw.

Deployment Dependencies

versity/versitygw - upstream project
VersityGW documentation - backends, users and S3 feature support