Railway Static IP: Fixed Egress for Railway Apps in 10 Minutes

Set the HTTP_PROXY and HTTPS_PROXY environment variables in Railway's dashboard, and your app gets a fixed outbound IP immediately. No code changes for most HTTP libraries. No infrastructure work. Start to finish: about 10 minutes.

This works for any Railway service that needs to reach a firewalled database, a third-party API with IP allowlisting, or any enterprise endpoint that won't talk to cloud IP ranges.

Why Railway Apps Get Blocked by Firewalls

Railway runs your services in containers on shared AWS infrastructure. When your app makes an outbound request, it goes out from whatever IP Railway's cluster is using at that moment. That IP can change on every deploy, every restart, and every scale event.

Most services don't care. But the ones that do really care. A PostgreSQL database with a security group. An enterprise API with a strict allowlist. A MongoDB Atlas cluster locked to known IPs. A banking partner that requires you to register your source address before they'll let you in.

I've seen customers move to Railway from Heroku specifically for the better developer experience, then immediately hit this when they try to connect back to a database they had allowlisted under a previous provider. The platform changed. The database didn't. The allowlist still expects a known address.

Railway doesn't offer static egress natively. The fix is a proxy.

Your Options for a Static Egress IP on Railway

There are a few ways to solve this.

Option 1: Railway private networking. Railway has private networking between services within the same project. That doesn't help when you need to reach an external database or API. It's a different problem.

Option 2: Railway's built-in static outbound IP (Pro plan). Railway Pro includes a shared static outbound IP you can enable per service. It's free with the plan and takes about 30 seconds to turn on. For many use cases this is good enough. The catch: it's shared infrastructure. Other Railway Pro customers use the same IP. You don't control it. If you need to tell a partner "only my app can reach this endpoint," a shared IP doesn't give you that guarantee. If your security model doesn't require IP isolation, start here before paying for anything.

Option 3: Deploy your own NAT gateway on AWS. You can run a dedicated NAT instance or NAT Gateway on AWS and route your Railway traffic through it. This gives you a fixed Elastic IP you fully own. It's also $32-$45/month just for the gateway, plus engineering time to build and maintain the routing. If something breaks at 2am, you own that too.

Option 4: QuotaGuard. Set two environment variables in Railway's dashboard. You get a load-balanced pair of static IPs that belong to your account alone. No other customer shares them. Plans start at $19/month. If something breaks, our engineers fix it.

If Railway's built-in shared IP satisfies your partner's requirements, use it. If you need dedicated IPs your account controls exclusively, that's what QuotaGuard provides. See our Netlify and Railway static IP comparison for a deeper look at the tradeoffs.

Setting Up a Static IP on Railway with QuotaGuard

After creating a QuotaGuard account, you'll land on your dashboard with a proxy URL that looks like this:

http://username:password@us-east-static-01.quotaguard.com:9293

That URL contains your credentials and routes traffic through your two static IPs. Copy it. Then go to your Railway service dashboard and add these two variables:

HTTP_PROXY=http://username:password@us-east-static-01.quotaguard.com:9293
HTTPS_PROXY=http://username:password@us-east-static-01.quotaguard.com:9293
NO_PROXY=localhost,127.0.0.1,.railway.internal

Set them under Variables in your Railway service settings. Redeploy the service. That's the entire setup for most apps.

The NO_PROXY value is important. Without it, internal Railway traffic tries to route through the proxy and fails. The .railway.internal suffix covers Railway's private networking addresses.

Verifying the Proxy Is Working

Before you provide your static IPs to anyone for allowlisting, verify the proxy is actually routing traffic. Make a test request to QuotaGuard's IP check endpoint:

curl https://ip.quotaguard.com

The response is a JSON object with the IP your request came from. It should match one of the two static IPs shown in your QuotaGuard dashboard. Run it a few times and you'll see both IPs alternate (they're load-balanced for high availability).

If it returns a Railway IP instead of a QuotaGuard IP, the environment variables aren't being picked up. Check that the service redeployed after you added them.

Code-Level Proxy Configuration (When ENV Vars Aren't Enough)

Most HTTP libraries in Node.js, Python, Ruby, and Go respect HTTP_PROXY and HTTPS_PROXY automatically. But some don't. If you're using axios, node-fetch, or another library that doesn't read environment variables, set the proxy explicitly in your code.

Node.js with https-proxy-agent:

import { HttpsProxyAgent } from 'https-proxy-agent';

const proxyUrl = process.env.QUOTAGUARDSTATIC_URL;
const agent = new HttpsProxyAgent(proxyUrl);

const response = await fetch('https://api.your-partner.com/endpoint', {
  agent,
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload)
});

Python with requests:

import requests
import os

proxy_url = os.environ['QUOTAGUARDSTATIC_URL']

proxies = {
    'http': proxy_url,
    'https': proxy_url
}

response = requests.post(
    'https://api.your-partner.com/endpoint',
    proxies=proxies,
    json=payload
)

Store your proxy URL as QUOTAGUARDSTATIC_URL in Railway Variables instead of hardcoding it. That way you can rotate credentials without a code change.

Connecting a Railway App to a Firewalled Database

The HTTP proxy handles web requests. It doesn't help with raw TCP connections like PostgreSQL, MySQL, or MongoDB. For those, you need QGTunnel.

I see this pattern a lot: someone moves their Railway app off Heroku, points it at an RDS database they'd been running for years with a security group, and can't connect. The database only allows the two IPs they'd whitelisted for their old Heroku dynos. QGTunnel is the fix.

Download QGTunnel and add it to your Railway service:

# In your Dockerfile or Railway build command
RUN curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz -C /app/bin

Then configure a tunnel in the QuotaGuard dashboard under Settings > Setup > Tunnel > Create Tunnel:

Update your Railway start command to wrap your process with QGTunnel:

# Railway start command
/app/bin/qgtunnel node server.js

With transparent mode on, your app connects to the original database hostname. QGTunnel intercepts the connection and routes it through your static IPs. Your database security group only needs those two IPs allowlisted.

QuotaGuard Shield: Static IPs for Inbound Railway Traffic

Everything above is about outbound traffic. Your Railway app reaching something external. Shield is the other direction.

If a third-party service needs to send webhooks or API calls to your Railway app, and they require you to give them a stable, fixed IP for that inbound traffic, Shield is what you need. It assigns a static IP to your Railway service's public endpoint.

This comes up most often with enterprise B2B integrations. Your customer's IT team needs to allowlist your server as a trusted source before they'll process data from you. With Railway's default dynamic IPs, that allowlist breaks every time your service redeploys. Shield fixes that.

See how Shield works for inbound static IPs.

Choosing the Right Plan

For most Railway use cases, start with Micro. The shared IPs on Micro and Medium are load-balanced and highly available. Enterprise is only necessary if your partner explicitly requires a dedicated IP that no other customer shares, or if you have specific compliance requirements.

Troubleshooting

Still getting the wrong IP after setting environment variables: Redeploy the service. Railway environment variable changes take effect on the next deploy, not immediately. Run curl https://ip.quotaguard.com from within the service after redeployment to confirm.

Internal service calls are failing: Check your NO_PROXY value. It should include localhost,127.0.0.1,.railway.internal to prevent internal Railway traffic from routing through the proxy.

407 Proxy Authentication Required: Your credentials are wrong. Copy the full proxy URL directly from your QuotaGuard dashboard and re-paste it into Railway Variables. Typos in the username or password format are the most common cause.

Database connection still refused after QGTunnel setup: Verify that your database security group or allowlist includes both of your QuotaGuard static IPs, not just one. They're load-balanced, so traffic can come from either IP.

Library not picking up HTTP_PROXY: Some libraries bypass system proxy settings. Check your library's documentation for explicit proxy configuration. The Node.js and Python examples above show how to pass the proxy URL directly if environment variables aren't being respected.

Get Started

Ten minutes to a fixed IP. Start a free trial, grab your proxy URL from the dashboard, and set it as an environment variable in Railway. That's the whole setup for most use cases.

See plans and start a free trial.

Still deciding whether you need dedicated IPs or Railway's built-in shared option is enough? The full Netlify and Railway static IP comparison covers that tradeoff in detail.

If your use case involves database connections, HIPAA-regulated data, or a two-way enterprise integration, reach out directly and you'll hear back from an engineer, not a support queue.