Retool Static IP: Connect Retool to Firewalled Databases and APIs

Retool Cloud doesn't give you a static outbound IP. If your database has a security group, or your enterprise API requires a registered source address, Retool's shared cloud IPs will get blocked. The fix is a proxy that gives your Retool queries a fixed, dedicated IP your IT team can allowlist once.

This works for Retool Cloud and self-hosted Retool. Setup takes about 10 minutes.

Why Retool Gets Blocked by Firewalled Databases

Retool Cloud runs on AWS shared infrastructure. When your app makes a query, it goes out from one of Retool's rotating cloud IPs. That IP changes. Your database security group or enterprise firewall sees a new source address every time and blocks it.

This is one of the most common reasons engineers contact us. The Retool app works perfectly in local development, where the developer's office IP is already allowlisted. Then they move it to Retool Cloud and every query fails. The database is fine. The query is correct. The problem is the source IP changed.

It comes up most often with:

• Amazon RDS PostgreSQL or MySQL with a VPC security group
• MongoDB Atlas clusters with IP allowlisting enabled
• Enterprise SaaS APIs (Salesforce, Workday, SAP) that require a registered IP
• Internal APIs behind a corporate firewall
• Any database a security team has locked down to known addresses

Your Options for a Static Egress IP with Retool

Option 1: Retool's IP allowlist (publish, don't trust). Retool publishes a list of IP ranges their cloud uses. You can add all of them to your allowlist. The problem is it's a large range of shared IPs used by every Retool customer. You're opening your database to all of them, not just your app. Most security teams won't accept that, and the list changes when Retool updates their infrastructure.

Option 2: Retool on-prem or self-hosted. Run Retool on your own EC2 instance or Kubernetes cluster and assign a static Elastic IP. Full control, no shared infrastructure. The cost is the EC2 instance, the engineering time to run it, and the operational overhead of keeping Retool upgraded. If you're already running self-hosted Retool, you can add the proxy at the host level and skip most of this complexity.

Option 3: QuotaGuard. Route your Retool resource queries through a proxy with two dedicated static IPs. They belong to your account. No other Retool customer shares them. Add them to your database allowlist once. Plans start at $19/month.

If your security model requires a known, isolated source IP that can't be shared with other customers, that's what QuotaGuard provides.

Setting Up a Static IP for Retool Cloud

Retool Cloud doesn't support global proxy environment variables the way a self-hosted instance does. Instead, you configure the proxy at the resource level, or route queries through a small intermediary.

Option A: REST API Resources

For Retool resources that make HTTP requests (REST API, GraphQL, custom API resources), configure the proxy directly in the resource base URL using your QuotaGuard credentials.

After creating a QuotaGuard account, your proxy URL looks like this:

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

For REST API resources in Retool, use a Retool workflow or custom JavaScript query to route the request through the proxy:

// Retool JavaScript query using fetch through a proxy-aware backend
// Best pattern for Retool Cloud: proxy via a lightweight middleware service

const response = await fetch('/api/proxy', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    targetUrl: 'https://your-enterprise-api.com/endpoint',
    method: 'GET'
  })
});
return response.json();

Option B: Middleware Service (Recommended for Database Connections)

Retool Cloud can't make raw TCP connections to a PostgreSQL or MySQL database through an HTTP proxy. The proxy only handles HTTP/HTTPS traffic. For direct database connections from Retool Cloud, the cleanest solution is a small middleware service.

Deploy a lightweight Node or Python service (on Railway, Render, or your own infrastructure) that has QuotaGuard configured. Retool talks to that service via HTTP. The service makes the database query from a static IP and returns the result.

This sounds like extra work, and it is an extra step. But it solves the problem cleanly, and it means your database never has to be exposed to cloud IPs at all. The middleware is the only thing that touches the database.

Here's a minimal Express service that does exactly this:

import express from 'express';
import { Pool } from 'pg';

const app = express();
app.use(express.json());

const pool = new Pool({
  connectionString: process.env.DATABASE_URL
});

app.post('/query', async (req, res) => {
  const { text, values } = req.body;
  const result = await pool.query(text, values);
  res.json(result.rows);
});

app.listen(3000);

Deploy that service somewhere with QuotaGuard's HTTP_PROXY set. Your database security group allowlists the two QuotaGuard static IPs. Retool calls the middleware's REST endpoint. The middleware is the only thing with database access.

Setting Up a Static IP for Self-Hosted Retool

Self-hosted Retool is simpler. Set the proxy at the host level and every Retool resource picks it up automatically.

In your Docker Compose file or Kubernetes deployment, add these environment variables to the Retool container:

# docker-compose.yml
environment:
  - 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,retooldb

Redeploy the Retool container. All outbound HTTP/HTTPS traffic from Retool now routes through your static IPs automatically, including REST API queries, GraphQL, and any other HTTP-based resource.

For direct database connections (PostgreSQL, MySQL) on self-hosted Retool, use QGTunnel. Download it and wrap your Retool process:

# Download QGTunnel
curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz

# Start Retool through the tunnel
bin/qgtunnel ./start-retool.sh

Configure your database tunnel in the QuotaGuard dashboard under Settings. Set the remote destination to your database host and port, enable transparent mode, and Retool connects to the original hostname while the traffic exits from your static IPs.

Verifying Your Static IP Is Working

Before you give your two static IPs to your IT team for allowlisting, confirm traffic is actually routing through them.

Create a Retool REST API resource pointed at QuotaGuard's IP check endpoint:

GET https://ip.quotaguard.com

The response returns the IP your request came from. It should match one of the two static IPs in your QuotaGuard dashboard. Run it a few times and you'll see both IPs rotate (load-balanced for availability).

If it returns a non-QuotaGuard IP, the proxy isn't configured correctly. Check your environment variables and redeploy.

QuotaGuard Shield: Static IPs for Inbound Retool Traffic

Everything above is outbound. Your Retool app reaching external data sources.

Shield is the other direction. If your Retool instance receives data from an enterprise system that only pushes to known, registered IP addresses, Shield assigns a fixed static IP to your inbound endpoint. Your enterprise data source allowlists that IP. Pushes, webhooks, and API calls arrive at a stable address regardless of where your Retool instance is hosted.

This comes up most often with enterprise ETL pipelines that push data into internal tools, or financial systems that only send data to pre-registered endpoints. See how Shield works for inbound traffic.

Choosing the Right Plan

Most Retool use cases start on Micro and upgrade as traffic grows. Enterprise is for situations where your partner or compliance requirement explicitly demands a dedicated IP that no other account shares.

Troubleshooting

Retool Cloud queries still failing after setup: Retool Cloud doesn't pick up global environment variables the way self-hosted does. You need the middleware approach for direct database connections. For HTTP-based resources, verify your proxy URL is formatted correctly including the protocol: http://username:password@hostname:9293.

Self-hosted proxy not applying to all resources: Some Retool resource types use their own HTTP clients that may not respect system proxy environment variables. Test each resource type individually with the ip.quotaguard.com check. For database resources on self-hosted Retool, QGTunnel is more reliable than HTTP_PROXY for raw TCP connections.

407 Proxy Authentication Required: Credentials in the proxy URL are wrong. Copy the full URL directly from your QuotaGuard dashboard rather than typing it manually.

Database still rejecting connection after allowlisting: Check that both static IPs are in your allowlist, not just one. QuotaGuard uses two IPs in a load-balanced pair. Traffic can come from either.

Middleware approach returning slow queries: Add connection pooling to your middleware service. Each Retool query hitting the middleware without pooling opens a new database connection. That adds latency and hits connection limits on databases like RDS. The pg Pool example above handles this correctly.

Get Started

Start a free trial, get your proxy URL from the dashboard, and configure your Retool deployment. Self-hosted Retool is two environment variables and a redeploy. Retool Cloud with direct database connections needs the middleware pattern, which takes a bit longer but gives you a cleaner security model.

See plans and start a free trial.

If you're dealing with HIPAA-regulated data, a PCI environment, or an enterprise security team with specific IP isolation requirements, reach out directly and you'll hear back from an engineer.