Public Networking
Public Networking refers to communicating over the public internet to services in Railway.
How it Works
Railway can detect if a deployed service is listening for traffic. When detected, Railway will provide a public domain for your service with the click of a button. The only thing you need to do, is properly handle the port assignment. More on this in the Public Networking guide.
If you have your own Domain already, Railway also supports adding custom domains to your services. For instructions on adding a custom domain, see the Public Networking guide.
Technical Specifications
*This information is subject to change at any time.
| Category | Key Information |
|---|---|
| DNS/Domain Names | - Support for domains, subdomains, and wildcard domains. - Subdomains and wildcards cannot overlap ( foo.hello.com cannot exist with *.hello.com unless owned by the same service).- Root domains need a DNS provider with ALIAS records or CNAME flattening. - Unicode domains should be PUNYcode encoded. - Non-public/internal domain names are not supported. |
| Certificate Issuance | - Railway attempts to issue a certificate for up to 72 hours after domain creation before failing. - Certificates are expected to be issued within an hour. |
| TLS | - Support for TLS 1.2 and TLS 1.3 with specific ciphersets. - Certificates are valid for 90 days and renewed every 30 days. - Cloudflare Proxying does impact certificate issuance and support for wildcard domains. |
| Edge Traffic | - Support for HTTP/1.1 and HTTP/2. - Support for websockets over HTTP/1.1 (may be interrupted after 2-4hrs, clients should handle reconnect). - Idle timeout of 900 seconds. - Max 100 request headers. - Max 100 concurrent streams per HTTP2 connection. - Max duration of 5 minutes for HTTP requests. |
| Request Headers | - X-Forwarded-For for identifying client's remote IP.- X-Forwarded-Proto always indicates HTTPS.- X-Request-Id for correlating requests against network logs. |
| Requests | - Inbound traffic must be TLS-encrypted - HTTP GET requests to port 80 are redirected to HTTPS. - HTTP POST requests to port 80 are redirected to HTTPS as GET requests. - SNI is required for correct certificate matching. |
Domain Rate Limits
To ensure the integrity and performance of our network, we enforce the following limits for all domains.
| Category | Limit | Description |
|---|---|---|
| Maximum Connections | 10,000 concurrent connections | The number of concurrent connections. |
| HTTP Requests/Sec | 3,000 RPS | The number of HTTP requests to a given domain per second. |
| Requests Per Connection | 10,000 requests | The number of requests each connection can make. |
If your application requires higher limits, please don't hesitate to reach out to us at [email protected].
Custom Domain Count Limits
The Hobby plan is limited to 2 custom domains per service.
The Pro Plan is limited to 10 domains per service by default but can be increased for Pro users on request, by reaching out to us at [email protected] or via private thread.
FAQ
What type of traffic can I send to my services in Railway?
We currently support HTTP and HTTP2 traffic from the internet to your services.
All traffic must be HTTPS and use TLS 1.2 or above, and TLS SNI is mandatory for requests.
- Plain HTTP GET requests will be redirected to HTTPS with a
301response. - Plain HTTP POST requests will be converted to GET requests.
For services that require TCP traffic, like databases, we also have a TCP Proxy feature.
How does Railway handle SSL certificates?
We provide LetsEncrypt SSL certificates using RSA 2048bit keys. Certificates are valid for 90 days and are automatically renewed 2 months into their life.
Certificate issuance should happen within an hour of your DNS being updated with the values we provide.
For proxied domains (Cloudflare orange cloud), we may not always be able to issue a certificate for the domain, but Cloudflare to Railway traffic will be encrypted with TLS using our default *.up.railway.app certificate.
Does Railway protect my services against DDoS?
We are unable to provide DDoS protection or WAFs at this time.
How do I handle forwarding traffic to my exposed port?
To have traffic from the public internet properly forwarded to your service's exposed port, you must ensure that you are properly using the PORT environment variable made available to every service deployment.
- If your application is listening on an explicitly defined port, you must define a
PORTvariable with the proper assignment in your service's variables. - If you do not explicitly define the
PORT, Railway provides one for you and exposes it during deployment.
More on this in the Public Networking guide.
Edit this file on GitHub