Static IPs for Retool Cloud: Use a Middleware Service to Hit IP-Restricted APIs

Most Retool Cloud customers who hit an IP allowlist requirement assume they have to migrate to self-hosted Retool to solve it. That's not true. A middleware pattern keeps Retool Cloud (with all its operational advantages) and gives you two static IPs you control. Setup is roughly 10 minutes, the middleware code is about 25 lines, and the IPs are stable across every Retool query, deploy, and platform change.

This post is the Retool Cloud deep dive. For the overview of static IPs for Retool in general (with comparisons to other approaches and the self-hosted HTTP_PROXY pattern), see Retool Static IP: Connect Retool to Firewalled Databases and APIs.

Why Retool Cloud's Shared IPs Aren't a Workable Allowlist Target

Retool Cloud runs on shared AWS infrastructure with dynamic outbound IPs. Retool does publish a broad list of IP ranges their cloud uses, and some teams add those ranges to database allowlists or partner API allowlists as a workaround. The problem with that approach: those ranges cover every Retool Cloud customer, not just yours. If you allowlist Retool's shared IPs in your database security group, you've effectively granted database access to every Retool customer on that infrastructure. Most security reviewers reject this immediately.

The alternative most teams reach for is self-hosting Retool, where container-level HTTP_PROXY gives you direct static IP control. That works (see the self-hosted Retool post) but it's a meaningful operational change. You take on container management, version upgrades, infrastructure scaling, and the cost difference between Retool Cloud and self-hosted enterprise tier.

The middleware pattern is the third option. You keep Retool Cloud. You deploy a small Node.js service somewhere with environment variable support (Heroku, Render, Railway, Fly.io). That service forwards Retool's outbound requests through QuotaGuard. From the destination's perspective, the traffic arrives from QuotaGuard's static IPs.

The Middleware Pattern: A Small Service That Carries Your Static IP

The architecture is three hops: Retool Cloud sends a request to your middleware service, the middleware forwards the request through QuotaGuard's proxy, and the destination receives a request from one of two QuotaGuard static IPs. The response flows back along the same path.

The middleware is a generic HTTP forwarder. It accepts a payload describing the actual request to make (URL, method, headers, body) and executes that request through the QuotaGuard proxy. One middleware instance handles every Retool resource that needs static IPs. You don't deploy a new middleware per destination.

The middleware host runs on infrastructure you control. Its outbound IPs aren't the static IPs (those are QuotaGuard's). The middleware just needs to be reachable by Retool Cloud and capable of running a Node.js process with the QuotaGuard proxy URL in its environment.

Build the Middleware Service

The canonical implementation is a small Express server with the https-proxy-agent package. From the QuotaGuard Retool integration docs:

import express from 'express';
import { HttpsProxyAgent } from 'https-proxy-agent';
 
const app = express();
app.use(express.json());
 
const proxyUrl = process.env.QUOTAGUARDSTATIC_URL;
const agent = new HttpsProxyAgent(proxyUrl);
 
app.post('/proxy', async (req, res) => {
  const { url, method = 'GET', headers = {}, body } = req.body;
  try {
    const response = await fetch(url, {
      method,
      headers,
      agent,
      body: body ? JSON.stringify(body) : undefined
    });
    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});
 
app.listen(process.env.PORT || 3000);

This is the minimum working version. It accepts a POST to /proxy with a JSON body describing the actual request to make, executes that request through QuotaGuard, and returns the response. Production hardening (auth, rate limiting, request validation) is covered later in this post.

Deploy on Heroku, Render, Railway, or Fly.io

Any platform that supports Node.js applications with environment variables works. The deployment specifics depend on your platform choice. The QuotaGuard side is identical regardless.

Sign up at QuotaGuard, copy the QUOTAGUARDSTATIC_URL from your dashboard, and set it as an environment variable on your middleware host. Set PORT if the platform expects a specific port binding.

Heroku is the simplest if you're already familiar with the platform. The QuotaGuard add-on auto-provisions and sets the QUOTAGUARDSTATIC_URL for you. Render, Railway, and Fly.io require manual signup at QuotaGuard.com and copying the URL into your platform's environment variables UI.

The middleware itself is cheap to host. On Heroku Eco ($5/month), Render Free, Railway, or Fly.io's free tier, the middleware runs comfortably for low-to-moderate Retool workloads. Heavy production usage may need a paid dyno, but the middleware processing cost is minimal compared to the actual API calls it's forwarding.

Connect Retool Cloud to the Middleware

In Retool, create a REST API resource that points to your middleware's URL. When you build queries against this resource in Retool, the query body describes the actual destination request:

{
  "url": "https://api.your-partner.com/endpoint",
  "method": "POST",
  "headers": {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_API_KEY"
  },
  "body": { "customer_id": "12345" }
}

The middleware extracts the url, method, headers, and body from this request, makes the actual call through QuotaGuard, and returns the destination's response back to Retool. From Retool's perspective, it's just calling a REST API. From your destination's perspective, the call arrived from a QuotaGuard static IP.

QuotaGuard Tip: Verify Static IPs Before Adding Them to Allowlists

Before you update any external allowlist with your QuotaGuard IPs, verify the middleware is actually routing through QuotaGuard. Create a Retool query against your middleware that calls https://ip.quotaguard.com. Run the query a few times. The responses should alternate between your two QuotaGuard static IPs as the load balancer rotates. If the responses show your middleware host's IP instead, the proxy agent isn't being used. Check the QUOTAGUARDSTATIC_URL environment variable on the middleware host and confirm the agent is being passed to the fetch call.

When the Middleware Pattern Doesn't Work

The middleware approach handles HTTP-based traffic. REST APIs, GraphQL endpoints, MongoDB Atlas Data API, Supabase REST API, PlanetScale's HTTP interface, and any other HTTP-callable service work cleanly.

The pattern does not work for native TCP database drivers. PostgreSQL's wire protocol, MySQL's TCP protocol, MongoDB's native binary protocol, Redis, and any other database that uses raw TCP cannot be proxied through an HTTP middleware. For those cases on Retool Cloud, your options are:

Option 1: Migrate the database to an HTTP API. MongoDB Atlas has a Data API. Supabase exposes its database via REST and GraphQL. PlanetScale has a HTTP interface for serverless contexts. If your database has an HTTP API option, the middleware pattern works against that interface.

Option 2: Add an API layer in front of your database. Deploy a small REST API service (similar architecture to the middleware) that talks to your database internally on a private network. Retool calls the REST API. The REST API queries the database. The database only sees connections from your API server's IP, which can be a stable IP you control.

Option 3: Migrate to self-hosted Retool. Self-hosted Retool can use QGTunnel for native TCP database connections. This is the cleanest path if you have many TCP database connections and the operational change is acceptable. See the self-hosted Retool post for the HTTP_PROXY pattern that handles HTTP resources, then add QGTunnel for the database layer.

Production Hardening: Authentication and Rate Limiting

The minimum middleware shown above is functional but not production-ready. Three additions matter for any middleware that handles real traffic.

Add authentication on the middleware endpoint. Without auth, anyone who discovers your middleware URL can use it as a free open proxy. The simplest approach is a shared secret in a header that Retool sends and the middleware validates. Generate a long random string, set it as both a Retool query header and a middleware environment variable, and reject requests where they don't match. For higher security, sign requests with HMAC and verify the signature.

Add rate limiting. A misbehaving Retool query (an infinite loop in a JavaScript transformer, for example) could hammer your middleware and cause QuotaGuard bandwidth overruns. Use express-rate-limit or your platform's built-in rate limiting to cap per-user or per-IP requests at a sensible threshold (e.g., 100 requests per minute per Retool deployment).

Whitelist the destination URLs your middleware will forward to. Without this, a compromised Retool account could use the middleware to send requests to arbitrary destinations. Keep a list of allowed destination hostnames in middleware configuration and reject requests to anything else. This is the defense-in-depth equivalent of an allowlist on the middleware itself.

For most production setups, all three additions together add about 30 lines to the middleware code. The QuotaGuard team can review your middleware implementation if you contact support before going live.

Self-Hosted Retool Has a Simpler Path

If you're already running self-hosted Retool, or you're willing to migrate, the HTTP_PROXY pattern is significantly simpler than this middleware approach. Self-hosted Retool inherits container-level environment variables across every HTTP-based resource without a separate middleware service. Set HTTP_PROXY on the Retool container, restart, and every existing and future resource exits through QuotaGuard automatically.

The trade-off is operational. Self-hosted Retool requires container management, version upgrades, infrastructure scaling, and an enterprise-tier license. Retool Cloud trades that operational simplicity for the static IP problem the middleware pattern solves. There's no universally right answer. Teams already invested in Retool Cloud usually find the middleware pattern less disruptive than migrating off Retool Cloud.

For the full self-hosted setup, see Static IPs for Self-Hosted Retool.

Frequently Asked Questions

How much latency does the middleware add?

One additional network hop. If the middleware is colocated with QuotaGuard (same cloud provider region), the added latency is typically 10-50ms per request. If the middleware is in a different region from QuotaGuard, expect 50-150ms additional. For most Retool use cases (interactive dashboards, admin tools), this is imperceptible. For latency-sensitive flows, deploy the middleware in the same region as your QuotaGuard subscription.

Can one middleware serve multiple Retool teams or workspaces?

Yes. The middleware is a generic forwarder, so any number of Retool resources can call it. The same QuotaGuard subscription's static IPs handle all the traffic. If you have multiple Retool workspaces, point each to the same middleware URL with a workspace-identifying header for routing or accounting purposes.

Does the middleware need to be public-facing?

It needs to be reachable from Retool Cloud, which runs on AWS infrastructure with rotating egress IPs. The simplest path is a publicly-reachable middleware URL with strong authentication. If you need a private network path, Retool Enterprise supports outbound connections to internal infrastructure via Retool's outbound region feature, which can target a private endpoint you've registered. For most teams, public + authenticated is simpler and equally secure.

What's the cost of running this in production?

QuotaGuard Static starts at $19/month with bandwidth bundled across plans. The middleware host runs on whatever you choose (Heroku Eco at $5/month, Render Free, Fly.io free tier, or similar). The middleware processing is lightweight; the actual cost-driving traffic is the destination API calls, which would happen regardless of the middleware. Total monthly cost for a low-to-moderate Retool integration is typically $20-40 including QuotaGuard and middleware hosting.

Does this work for streaming responses (SSE, chunked transfer)?

The basic middleware implementation in this post collects the full response before returning to Retool, which works for normal request/response patterns but not for streaming. For streaming use cases (real-time data, server-sent events), modify the middleware to pipe the response stream directly rather than awaiting response.json(). Retool's REST API resource has limited support for streaming, so verify the Retool side handles streams before investing in a streaming middleware.

How do I monitor what the middleware is doing?

Standard Node.js logging on the middleware host gives you per-request visibility. Log the request URL, response status, and timing. Most middleware hosts (Heroku, Render, Railway, Fly.io) provide log aggregation and monitoring. For audit purposes (which Retool query made which destination call), include a query identifier in the request headers and log it.

Can this work with Retool's OAuth-authenticated REST API resources?

Yes, but the OAuth happens between Retool and your middleware, not between Retool and the destination. The middleware then attaches the destination's API key (stored in middleware environment variables) to the actual outbound call. This is actually a security improvement: the destination's credentials live in the middleware, not in Retool.

Does this work for Retool Workflows on Retool Cloud?

Workflows can call your middleware via the same REST API resource that apps use. From the middleware's perspective, the traffic is identical. The static IP pattern works for both Retool Apps and Retool Workflows on Cloud as long as both use the middleware-based REST API resource for their external calls.

Get Started in 10 Minutes

The middleware pattern is the answer for Retool Cloud users who need static outbound IPs without migrating to self-hosted Retool. The setup is one Node.js service, one environment variable, one Retool REST API resource, and two static IPs added to your destination's allowlist. The operational simplicity of Retool Cloud stays intact.

QuotaGuard Static starts at $19/month, Shield at $29/month (recommended if your Retool resources include financial data, PHI, or other regulated content). 3-day trial, credit card required. See the Retool integration page for the canonical setup, pricing, or contact us with questions about your specific Retool deployment.