Deploy and Host a gRPC Reverse Proxy on Railway

Deploy a compact Caddy 2.11.4 proxy that accepts HTTP/1.1 or h2c, exposes a dependency-free health endpoint, and forwards application traffic over h2c to a backend selected with SERVICE_URL.

About Hosting a gRPC Reverse Proxy

The template uses the immutable ghcr.io/monotykamary/grpc-reverse-proxy:v2.11.4-r3 image. Caddy listens on port 8080, serves GET /health, and forwards every other request to a reachable backend in host:port form.

The proxy works on Railway, with an important public-ingress distinction: Railway-generated HTTPS domains currently forward HTTP/1.1 to service containers. Those domains work for HTTP/REST clients whose requests can be forwarded to an h2c-capable backend, such as the Milvus REST v2 API. They do not provide end-to-end HTTP/2 for native gRPC clients.

Native gRPC clients can use the proxy through Railway private networking, a raw TCP proxy, or an external edge that preserves HTTP/2. A raw TCP proxy does not add Railway-managed TLS, so provide your own TLS termination and authentication for public native gRPC traffic.

Common Use Cases

Expose an HTTP/REST API backed by a private h2c-capable service
Route Milvus REST v2 requests to a private Milvus standalone service
Proxy native gRPC over Railway private networking
Place Caddy behind an edge or TCP transport that preserves HTTP/2
Add a stable /health endpoint around a private backend

Dependencies for gRPC Reverse Proxy Hosting

A reachable h2c backend in host:port form
An HTTP/REST client when using a Railway-generated HTTPS domain
End-to-end HTTP/2 when using a native gRPC client
User-managed TLS and authentication when exposing native gRPC through raw TCP

Deployment Dependencies

Implementation Details

Set the required SERVICE_URL variable to the backend address, for example api.railway.internal:50051. Do not include a URL scheme: the Caddy configuration explicitly uses h2c for upstream traffic.

The generated Railway domain targets port 8080. GET /health returns 200 ok without contacting the backend. The proxy does not provide application authorization; enforce access controls in the backend or a dedicated gateway.

The image accepts native h2c and passed gRPC reflection testing through transports that preserve HTTP/2. Railway-managed public HTTPS currently terminates HTTP/2 before the container, so use that route for HTTP/REST traffic rather than native gRPC SDK connections.

Why Deploy a gRPC Reverse Proxy on Railway?

Railway provides private service discovery, generated HTTPS for REST-compatible traffic, deployment health checks, logs, and straightforward image deployment. This template supplies a small bridge from those endpoints to private h2c backends while documenting when native gRPC requires a different ingress transport.