Deploy and Host imgproxy on Railway

imgproxy resizes, crops and converts images on the fly from a signed URL. Store one original, serve every size and format from it — WebP and AVIF included — without a build step, a cron job or a folder full of thumbnails.

About Hosting imgproxy

Four services that make a complete image pipeline: imgproxy itself, S3-compatible object storage for the originals, a web console to upload and browse them, and a one-shot initializer that creates the bucket on first boot. imgproxy reads from the bucket over the private network and is the only thing that needs to be fast.

URL signing is on, with a generated key and salt.

Common Use Cases

User-uploaded avatars and photos: One original per user, every size derived on request, with the source never exposed publicly.
Responsive images for a site or app: srcset variants and modern formats generated on demand instead of at build time.
Replacing a paid image CDN: The same transformation grammar on infrastructure you own, with a year-long cache TTL in front of it.

Dependencies for imgproxy Hosting

Deployment Dependencies

imgproxy v3.18 — the transformation server
S3-compatible object storage on a Railway volume — the originals
A web console for uploads, and a one-shot bucket initializer
An imgproxy URL-signing helper in your application

Implementation Details

IMGPROXY_KEY and IMGPROXY_SALT are generated per deployment and URLs must be signed with them. This is not optional decoration: without signing, anyone could point your instance at arbitrary sources and use it as an open resizing proxy. Every official imgproxy client library takes the key and salt and produces the signature; copy both from the service variables into your application.

imgproxy reads from the bucket through the private endpoint, so image bytes never leave the project on their way in.

IMGPROXY_TTL is one year, which is the right default for content-addressed URLs — change the transformation and you change the URL, so a long cache is safe.

IMGPROXY_MAX_SRC_RESOLUTION is 16.8 megapixels. Uploads larger than that are rejected rather than allowed to exhaust memory; raise it deliberately if you handle camera originals.

The initializer container creates the bucket and exits. A stopped container after the first deploy is expected.

The console has its own public domain and uses the object store's root credentials — it is a full storage administration UI, so treat that URL as privileged.

Why Deploy imgproxy 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 imgproxy 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.

Resources: imgproxy is written in Go and idles under 100 MB, spiking per transformation; object storage and the console add a little more. On the order of $8–12 a month, with CPU the thing that scales with traffic.