QuotaGuard and Railway Integration Guide

Route the connections that need a fixed source identity from Railway through QuotaGuard. The destination sees one of the two stable IP addresses assigned to your subscription, while unrelated Railway traffic can keep its normal route.

QuotaGuard is the normal fit when you need a small, managed allowlist without building and operating NAT or proxy infrastructure. QuotaGuard operates the egress service, load-balanced pair, monitoring, capacity, and incident response. Your application keeps the same allowlisted identity across Railway deploys and can keep it if you later change Railway regions or move the workload to another platform.

You do not need QuotaGuard for traffic between services in the same Railway project and environment. Use Railway private networking and its .railway.internal hostnames for that traffic.

Why Use QuotaGuard on Railway?

Railway services without its Pro static-egress feature use dynamic outbound infrastructure. That becomes a blocker when an external system accepts requests only from pre-approved source addresses.

Common examples include:

• a payment or banking API that requires registered source IPs;
• MongoDB Atlas or another database protected by an IP access list;
• a client API behind a corporate firewall;
• an SFTP server or enterprise service that accepts only known senders; and
• a partner that will approve two addresses but not a broad cloud range.

QuotaGuard gives the connection a stable identity without tying that identity to a Railway region. Application-level configuration can also be selective: route the protected API client through QuotaGuard and leave unrelated OAuth, telemetry, internal service calls, and public traffic on their existing paths.

Standard QuotaGuard plans provide a stable pair on shared managed proxy infrastructure. If a destination requires addresses used exclusively by your organization, contact QuotaGuard about an Enterprise dedicated deployment.

Railway’s Native Option

Railway Pro includes Static Outbound IPs. Railway currently assigns three permanent IPv4 addresses to a service and balances outbound traffic from its replicas across them. Railway says those addresses are not guaranteed to be dedicated and may be shared with other customers. They also change when the service moves to another Railway region.

That native feature is useful when you already need Railway Pro and want service-wide platform routing. QuotaGuard is designed for the common alternative: two stable addresses, selective per-client or per-destination routing, portability outside Railway, and a managed egress provider that owns the proxy infrastructure and support path.

Get Your QuotaGuard Connection

1. Create a QuotaGuard subscription.
2. Choose the closest practical one of QuotaGuard’s 12 AWS regions during signup.
3. Copy the complete connection URL and both static IP addresses from the QuotaGuard dashboard.
4. Add both IP addresses to the destination’s allowlist.

The connection URL has this form:

http://username:password@<your-quotaguard-proxy-host>:9293

Store the exact dashboard value in Railway as a secret variable named QUOTAGUARDSTATIC_URL. Do not assemble the hostname yourself or commit the credentials to source control.

Recommended: Route One HTTP Client Through QuotaGuard

Explicit client configuration keeps the route narrow. Only the client used for the protected destination receives the QuotaGuard dispatcher or proxy session.

Node.js with Undici

Node’s built-in fetch is powered by Undici and does not use an agent option from https-proxy-agent. Use Undici’s ProxyAgent as the request dispatcher:

import { ProxyAgent, fetch } from 'undici';

const dispatcher = new ProxyAgent(process.env.QUOTAGUARDSTATIC_URL);

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

if (!response.ok) {
  throw new Error(`Partner request failed: ${response.status}`);
}

Reuse the dispatcher rather than creating one for every request.

Python with Requests

Create a session for the protected destination instead of changing proxy behavior for every HTTP client in the process:

import os
import requests

partner = requests.Session()
partner.proxies.update({
    "http": os.environ["QUOTAGUARDSTATIC_URL"],
    "https": os.environ["QUOTAGUARDSTATIC_URL"],
})

response = partner.post(
    "https://api.your-partner.com/endpoint",
    json=payload,
    timeout=30,
)
response.raise_for_status()

Optional: Proxy-Aware Environment Variables

If every compatible HTTP client in the service should use QuotaGuard, set these Railway variables and redeploy:

HTTP_PROXY=http://username:password@<your-quotaguard-proxy-host>:9293
HTTPS_PROXY=http://username:password@<your-quotaguard-proxy-host>:9293
NO_PROXY=localhost,127.0.0.1,.railway.internal

The bypass entry keeps Railway private-network traffic off the public proxy path. Environment variables affect only software that honors them, so they are not proof that every library or protocol is using QuotaGuard. Test the actual client that opens the protected connection.

Verify the Outbound Address

From inside the deployed Railway service, make an explicit proxy request:

curl -x "$QUOTAGUARDSTATIC_URL" https://ip.quotaguard.com

The returned address should match one of the two IPs shown in your QuotaGuard dashboard. A short test may repeatedly show the same address because connection reuse and load balancing do not guarantee that both appear. The destination must still allowlist both so the managed failover path remains approved.

This check proves only that the test request used QuotaGuard. Verify that the production API or database client is configured to use the same route.

Raw Database and TCP Connections

PostgreSQL, MySQL, native MongoDB drivers, Redis, SFTP, and other raw TCP protocols do not use an HTTP proxy merely because HTTP_PROXY or HTTPS_PROXY exists. On Railway, use a compatible SOCKS5 client or run QGTunnel with the application process.

Install QGTunnel

Download and extract QGTunnel into the application image:

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

This package includes bin/qgtunnel and the files used by transparent mode. Make sure those files are present in the deployed image.

Configure the Destination

In the QuotaGuard dashboard, open Setup, select Tunnel, and create a tunnel for the actual database hostname and port. For a PostgreSQL example:

Then prefix the Railway start command with QGTunnel:

bin/qgtunnel node server.js

Replace node server.js with the service’s normal start command. QGTunnel reads QUOTAGUARDSTATIC_URL, fetches the tunnel configuration, starts the local route, and then starts the application.

Do not describe HTTP_PROXY as database configuration. Confirm the database’s actual connection logs show one of the two assigned QuotaGuard addresses before tightening its firewall.

QuotaGuard Static or Shield?

QuotaGuard Static starts at $19 per month and is the normal choice for API and database allowlisting. For HTTPS, the client creates a blind CONNECT tunnel and TLS continues to the destination; QuotaGuard does not decrypt the HTTPS payload. The customer-to-proxy connection uses the standard HTTP proxy protocol.

QuotaGuard Shield starts at $29 per month and adds TLS protection to the customer-to-proxy hop through its secure connection methods. Choose Shield when that protected first hop is required by the approved security or regulated-data architecture. Shield is not an inbound-IP product, and the presence of financial, health, or other sensitive data does not by itself prove which plan a customer’s review will approve.

Both products provide two stable outbound IP addresses. Standard plans use shared managed proxy infrastructure; exclusive IPs require an Enterprise dedicated deployment.

Troubleshooting

The destination still sees a Railway address. The production client is bypassing the proxy. Configure that library explicitly and verify the exact call path rather than relying on an environment variable alone.

Railway private service calls fail. If you use global proxy variables, confirm NO_PROXY includes localhost,127.0.0.1,.railway.internal. Prefer selective client configuration when only one external destination needs the static route.

The request returns 407 Proxy Authentication Required. Copy the complete connection URL from the QuotaGuard dashboard again. Check that Railway preserved special characters correctly and that the service was redeployed after the variable changed.

The database still refuses the connection. Confirm QGTunnel starts before the application, the tunnel matches the database hostname and port, and the destination has allowlisted both QuotaGuard addresses. Inspect the destination’s connection logs for the source it actually received.

The IP check shows only one assigned address. That is normal. Do not wait for a short test to display both; allowlist both addresses for the managed pair.

Start With One Protected Connection

Configure the API client or TCP route that actually needs the allowlist, verify it from the destination side, and leave unrelated Railway traffic unchanged. If the selected library or protocol needs a different proxy method, contact QuotaGuard support and include the Railway runtime, client library, destination hostname, and protocol.

• View QuotaGuard plans
• Railway Static Outbound IP documentation
• Railway private-networking documentation