QuotaGuard and Railway Integration Guide

QuotaGuard gives Railway applications a stable, static outbound IP address for requests leaving the Railway platform — things like calls to third-party APIs, cloud databases behind security group rules, and partner services that require a pre-registered source address. QuotaGuard is not needed for traffic between Railway services that communicate over Railway’s private networking; that traffic stays internal and never touches the public internet.

Why Railway Apps Need Static IPs

Railway runs application containers on shared AWS infrastructure. Every time a service is deployed, restarted, or scaled, the container is assigned a new outbound IP from AWS’s shared pool. There is no guarantee the next IP will match the previous one, and no way to predict it in advance.

This is a practical problem for the following scenarios:

• Database security groups — AWS RDS, Google Cloud SQL, and other managed databases commonly restrict inbound connections to a list of trusted IP addresses. A Railway app with a rotating IP cannot maintain a stable entry on that list.
• Enterprise APIs with IP allowlists — B2B APIs in finance, healthcare, and logistics frequently require you to submit your source IP before issuing credentials. When that IP changes, the API rejects requests with a 403 or connection refusal.
• MongoDB Atlas IP Access Controls — Atlas requires every connecting IP to be explicitly listed. Railway’s dynamic IPs make this impossible to maintain without disabling the access control entirely.
• Partner APIs requiring registered source addresses — Payment processors, insurance carriers, and similar services often enforce source IP as a second authentication factor. A changed IP looks like an unauthorized caller.

Your Options for a Static Egress IP on Railway

Four approaches exist. Each involves real trade-offs worth understanding before choosing.

Railway private networking assigns stable .railway.internal hostnames for service-to-service communication inside Railway. It solves nothing for outbound internet traffic, because the external IP of that traffic is still dynamically assigned by AWS.

Railway Pro’s built-in shared static outbound IP is a legitimate option for many applications. Pro plan customers get a static IP enabled in roughly 30 seconds from the Railway dashboard. The important caveat: this IP is shared across all Railway Pro customers. If your security requirement is simply “give us a consistent IP to allowlist,” this works. If the requirement is IP isolation — for example, a bank that wants to ensure no other customer’s traffic can appear to originate from the same address — it does not.

A self-managed NAT gateway on AWS gives you a fully dedicated elastic IP, but requires provisioning a VPC, NAT gateway, and routing configuration yourself. AWS charges approximately $32–45/month for the NAT gateway alone, plus EC2 time if you use a self-hosted NAT instance. Expect meaningful engineering overhead to set up and maintain.

QuotaGuard provides a dedicated pair of static IPs assigned to your account, not shared with any other customer. It handles both HTTP/HTTPS proxy traffic and raw TCP connections (via QGTunnel). Plans start at $19/month. If Railway Pro’s shared IP satisfies your use case, use that — it costs nothing extra. If you need IP isolation, a load-balanced pair, or raw TCP support, QuotaGuard is the practical alternative to a self-managed NAT setup.

Getting Started

Create a QuotaGuard account at quotaguard.com. During setup you will choose a proxy region. Select the region geographically closest to the external service you are connecting to — not closest to Railway’s infrastructure — because latency is determined by the hop from the proxy to the destination.

After account creation, your proxy URL will look like this:

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

Your QuotaGuard account includes two static IPs, both active simultaneously. Traffic is load-balanced across them — you cannot control which IP a given request uses. When submitting IPs to a firewall allowlist or database security group, always add both IPs. You will find them listed in the QuotaGuard dashboard under your account overview.

Setting Up the HTTP Proxy (Most Services)

Most outbound HTTP and HTTPS traffic can be proxied by setting standard environment variables. No code changes are required for libraries that respect system proxy settings.

Step 1: Set Railway Environment Variables

In the Railway dashboard, open your service, navigate to Variables, and add these three environment 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

The NO_PROXY variable is required for Railway specifically. Without it, traffic to other Railway services over private networking will attempt to route through the proxy and fail. The .railway.internal suffix covers all of Railway’s internal service addresses. Any hostname matching that suffix bypasses the proxy entirely.

Store the full proxy URL (with credentials) as a separate variable named QUOTAGUARDSTATIC_URL as well — you will reference this in code for libraries that require explicit proxy configuration:

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

Step 2: Redeploy the Service

Environment variable changes in Railway do not take effect in a running container. You must trigger a redeployment for the new variables to be loaded. After the deploy completes, all outbound HTTP/HTTPS requests from the service will route through QuotaGuard.

Code-Level Proxy Configuration

Some libraries do not read system proxy environment variables. For those, pass the proxy explicitly in code.

Node.js — using 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 — using requests:

import requests, os

proxies = {
    'http': os.environ['QUOTAGUARDSTATIC_URL'],
    'https': os.environ['QUOTAGUARDSTATIC_URL']
}

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

In both cases, the proxy URL is read from QUOTAGUARDSTATIC_URL. If credentials ever need to be rotated, you update the Railway variable and redeploy — no code change required.

Verifying the Proxy Is Working

Before providing your static IPs to any external service for allowlisting, confirm the proxy is working correctly from inside the Railway container.

Run this from your service (via Railway’s shell, a test endpoint, or a startup log):

curl https://ip.quotaguard.com

The response is a JSON object showing the IP address the request arrived from. It should match one of the two static IPs listed in your QuotaGuard dashboard. Run it several times — you should see both IPs appear as the load balancer alternates between them.

Minimal Node.js verification function:

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

async function verifyProxy() {
  const agent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);
  const response = await fetch('https://ip.quotaguard.com', { agent });
  const data = await response.json();
  console.log('Outbound IP:', data);
  return data;
}

verifyProxy();

Expected output (you will see one of your two static IPs):

{ "ip": "12.34.56.78" }

Run it a few times and confirm both IPs from your dashboard appear. If you see a different IP, the proxy is not being used — check that QUOTAGUARDSTATIC_URL is set and the service was redeployed after adding the variable.

Database Connections via QGTunnel

The HTTP proxy handles web requests — HTTP, HTTPS, and any protocol that rides over those. It does not help with raw TCP connections. If your Railway app connects to PostgreSQL, MySQL, MongoDB (native driver), Redis, or any other database using a direct socket connection, the HTTP proxy does not apply.

QGTunnel is the solution for raw TCP. It runs alongside your application and intercepts outbound TCP connections, routing them through QuotaGuard’s static IPs before they reach the database.

Installing QGTunnel

Add this to your Dockerfile or Railway build command to install the binary:

RUN curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz -C /app/bin

Configuring the Tunnel

In the QuotaGuard dashboard, go to Settings > Setup > Tunnel > Create Tunnel and enter the following:

Use the actual hostname and port for your database. Repeat for each database host if you have more than one.

Updating the Start Command

Wrap your normal start command with qgtunnel:

/app/bin/qgtunnel node server.js

With transparent mode enabled, your application code does not change. It connects to the database using the original hostname (your-database.rds.amazonaws.com), exactly as before. QGTunnel intercepts that connection and routes it through your QuotaGuard static IPs. From the database’s perspective, the connection arrives from one of those two IPs.

Add both static IPs to the database security group. Because traffic is load-balanced, either IP may be the source of any given connection.

QuotaGuard Shield: Static IPs for Inbound Railway Traffic

Everything above covers outbound traffic — requests your Railway app sends to external services. Shield addresses the opposite direction.

If a third-party service needs to send webhooks or API calls to your Railway app, and that service’s IT or security team requires a fixed IP address for what they consider the inbound connection to their systems, Shield is the relevant product. This comes up in enterprise B2B integrations where a customer’s network firewall must allowlist your server before their systems will accept data from it.

Shield provides stable IP addresses for that inbound path, with SSL passthrough so traffic is end-to-end encrypted and the proxy does not inspect it. It is the appropriate choice for scenarios involving PHI, payment data, or compliance frameworks that prohibit traffic inspection at intermediary points.

Learn more about QuotaGuard Shield →

Troubleshooting

Wrong IP shown after setting env vars Environment variable changes require a redeployment to take effect in Railway. Trigger a redeploy from the Railway dashboard, then run curl https://ip.quotaguard.com from within the service to confirm the IP has changed.

Internal Railway service calls failing after adding proxy variables Check the NO_PROXY value. It must include localhost,127.0.0.1,.railway.internal. The .railway.internal suffix is what prevents Railway’s private networking traffic from being routed through the proxy. If that suffix is missing or misspelled, internal service discovery will fail.

407 Proxy Authentication Required The credentials in the proxy URL are incorrect. Open the QuotaGuard dashboard and copy the full proxy URL directly — do not retype it manually. The most common cause is a typo in the username or password separator format. The correct format is http://username:password@hostname:port, with a colon between username and password and an @ before the hostname.

Database connection still refused after QGTunnel setup Verify that the database security group allowlist includes both static IPs from your QuotaGuard dashboard. Because QGTunnel traffic is load-balanced across the IP pair, a connection can arrive from either address. Allowlisting only one IP will cause roughly half of connection attempts to be refused.

A library is not picking up HTTP_PROXY / HTTPS_PROXY Some HTTP client libraries bypass system proxy environment variables and require explicit configuration. Use the code-level proxy setup shown in the Setting Up the HTTP Proxy section above, passing the proxy URL directly to the HTTP client.

QuotaGuard Static vs QuotaGuard Shield

For most Railway use cases, Static is the right choice. It handles the full range of outbound HTTP/HTTPS requests and database tunneling. Choose Shield when you are transmitting protected health information, payment card data, or any data subject to a compliance framework that prohibits traffic inspection by intermediary services — the proxy provider must not be able to read the payload.

Ready to Get Started?

• Start a free QuotaGuard trial →
• Contact support if you have questions about your specific integration or need help choosing a plan.