Connect Replit to Azure SQL Server With a Static IP Using QGTunnel

Add your QuotaGuard Shield URL as a Replit Secret, let the Replit Agent download QGTunnel at startup, and your SQL Server connection always exits from the same two static IPs your Azure firewall expects.

I had a customer this week. An IT manager whose team was using Replit to build apps against an Azure SQL Server. Every time Replit redeployed, the outbound IP changed, their Azure firewall rule no longer matched, and the connection dropped. They had to keep updating the NSG rule by hand. Randall on our team put together the exact setup below, and it resolved the problem in one pass.

SQL Server Connections Require QGTunnel, Not an HTTP Proxy

The existing Replit + QuotaGuard guide covers HTTP and HTTPS traffic using a standard proxy URL. SQL Server on port 1433 is raw TCP traffic. An HTTP proxy won't intercept it. You need QGTunnel instead.

QGTunnel is a lightweight binary that wraps your app's process and routes outbound TCP connections through QuotaGuard's infrastructure. Your connection string doesn't change. Your app doesn't know a tunnel is involved. The Azure SQL Server sees traffic arriving from your two static IPs.

For this use case, use QuotaGuard Shield rather than QuotaGuard Static. Shield uses SSL passthrough. QuotaGuard routes the packets but never decrypts the data. For database connections carrying business data, that's the right architecture.

Step 1: Get Your Shield URL and Static IPs

Log into your QuotaGuard dashboard. Copy your Shield Connection URL. It looks like this:

https://username:password@us-west-shield-01.quotaguard.com:9294

Also note your two static egress IP addresses shown on the same page. You'll need them for the Azure firewall rule in the next step.

Step 2: Add the Inbound Rule to Your Azure VM

In the Azure Portal, go to your VM, click Networking, then Add inbound port rule. Fill in:

• Source: IP Addresses
• Source IP addresses: paste your two QuotaGuard static IPs
• Destination port ranges: 1433
• Protocol: TCP
• Action: Allow

Save the rule. Your SQL Server now accepts connections from those two IPs and nothing else on port 1433.

QuotaGuard tip: add both static IPs to the rule now, even if you only see traffic from one at first. QuotaGuard load-balances across both, and only allowlisting one causes intermittent failures that are painful to debug.

Step 3: Add Your Credentials as Replit Secrets

In your Replit project, click the padlock icon to open the Secrets panel. Add these five secrets:

QUOTAGUARDSHIELD_URL = https://username:password@us-west-shield-01.quotaguard.com:9294 DB_SERVER = your Azure VM IP or hostname DB_NAME = your database name DB_USER = your SQL Server username DB_PASSWORD = your SQL Server password

Secrets in Replit are encrypted at rest and injected as environment variables at runtime. They don't appear in your code or get committed to version control.

Step 4: Let the Replit Agent Wire It Up

This is where the setup gets fast. Open Replit's AI chat and paste this prompt exactly:

I have a QuotaGuard Shield account. Please set up QGTunnel so my app connects to my Azure SQL Server on port 1433 through the QuotaGuard Shield proxy. My credentials are already saved as Replit Secrets: QUOTAGUARDSHIELD_URL, DB_SERVER, DB_NAME, DB_USER, and DB_PASSWORD. Please download the QGTunnel binary as part of the startup process, wrap the server start command with it, and write a database connection utility using the mssql package.

The agent will handle downloading the QGTunnel binary, modifying the startup configuration to wrap your server start command with it, and writing a database connection module using the mssql package that reads credentials from your Secrets.

Step 5: Test the Connection

Once the agent finishes, ask it to verify the setup:

Can you test the database connection and confirm it's working?

If the test passes, your Replit app is now connecting to Azure SQL Server through your two static IPs. Redeploy as many times as you want. The IPs your SQL Server sees never change.

What to Check If It Doesn't Connect

Two failure modes cover almost everything:

Connection timeout. The Azure NSG rule doesn't have the exact QuotaGuard IPs, or SQL Server doesn't have TCP/IP enabled for remote connections. Check both. In SQL Server Configuration Manager, confirm TCP/IP is enabled under Protocols for your SQL Server instance.

Authentication failure. Your SQL Server is using Windows Authentication instead of SQL Server Authentication. Windows Authentication doesn't work for remote connections from cloud apps. In SQL Server Management Studio, confirm your SQL Server instance is set to SQL Server and Windows Authentication mode, and that the DB_USER account uses SQL Server Authentication.

Why This Works When a Standard Proxy Doesn't

The HTTP proxy setup in our existing Replit guide works for everything that speaks HTTP or HTTPS. SQL Server over port 1433 is a different protocol entirely. It establishes a raw TCP connection and speaks the Tabular Data Stream (TDS) protocol. Standard HTTP proxies don't know how to handle it.

QGTunnel solves this by operating below the application layer. It intercepts outbound TCP connections matching your configured destination and tunnels them through QuotaGuard. Your app's database driver just sees a normal connection. The tunneling is transparent.

QuotaGuard Shield plans start at $19/month. For database connections carrying real business data, SSL passthrough is the right architecture. See QuotaGuard Shield for details or start at quotaguard.com/products/pricing.