Deploy and Host Garage S3 on Railway

Garage is a lightweight, S3-compatible object store. This template runs it as a single service on a single volume, with the S3 API published on your Railway domain, a real healthcheck, and one important difference from the other Garage templates: the access key and secret you set on the deploy form are the credentials that actually work — on the first boot and on every boot after it.

About Hosting Garage S3

The service runs the official Garage v2.2.0 binary, pinned and verified by checksum at image build time, on Alpine. Metadata uses the LMDB engine (upstream's recommendation for a single node) and both metadata and object data live on one Railway volume mounted at /data. An in-container nginx gateway listens on Railway's injected $PORT and proxies the S3 API, with request buffering turned off so large multipart uploads stream rather than being spooled to disk, and /healthz proxied to Garage's own cluster-health endpoint so a broken boot fails the deploy instead of reporting success.

Boot is idempotent: the credential format is validated before the server starts, the RPC secret and admin token are persisted to the volume, the cluster layout is assigned with a capacity read from the mounted volume, and the access key is imported and granted ownership of the bucket whenever that key id is not already present.

Why Deploy Garage S3?

Object storage is usually the piece a project rents from someone else. Running Garage on Railway keeps uploads, backups, user media and build artifacts inside the same project as the app that writes them, with no per-request egress bill and no third-party account.

Compared with the other Garage templates on Railway, this one:

Uses the credentials you set. Elsewhere every key operation is guarded behind a first-boot marker file, so a key set or changed after the first deploy is silently ignored and the S3 endpoint answers AccessDenied: No such key — the top entry in those templates' own troubleshooting sections.
Cannot be deployed with an invalid key. Both credentials are generated in Garage's exact format (GK + 24 hex, and 64 hex), so the deploy form has no blank required fields. A bad value handed in by hand exits with a message naming the format instead of crash-looping.
Keeps secrets out of the deploy log. The boot summary prints the access key id and says the secret is not logged.
Has a healthcheck, and an S3 endpoint on the port Railway actually routes.

Common Use Cases

S3 backend for an app's user uploads, avatars and attachments
Backup target for restic, rclone or database dumps
Artifact and asset storage for CI and static sites

Dependencies for Garage S3

Garage runs standalone — no database and no cache service.

Deployment Dependencies

Garage — upstream project and documentation
Wrapper image source

Notes

Railway does not issue wildcard subdomains, so S3 clients must use path-style addressing (endpoint/bucket/key), not virtual-host style. Region is garage.

To rotate the credential, change GARAGE_ACCESS_KEY (a new GK + 24 hex id) and GARAGE_SECRET_KEY together, then redeploy. Garage never permits an access key id to be reused, so the secret of an existing id cannot be changed; buckets and their contents survive the rotation untouched.