How to Restrict Retool Logins by IP Address

If you need to restrict Retool logins to specific IP addresses or IP ranges, you're not alone — it's one of the most frequently requested security features in the Retool community. The short answer is: IP restriction is supported on self-hosted Retool instances, but is not natively available on Retool Cloud. Here's everything you need to know to make the right call for your team and, if you go the self-hosted route, how to actually set it up.

Why IP Restriction Matters for Retool

Retool sits in front of your most sensitive internal systems — databases, APIs, and tools that touch customer PII. Limiting who can even reach the login screen based on network location is a foundational zero-trust security control. It ensures that even if credentials are compromised, an attacker outside your corporate network or VPN can't get in. For teams subject to SOC 2, HIPAA, or internal compliance requirements, this isn't optional — it's a hard requirement.

Does Retool Cloud Support IP Allowlisting?

As of now, Retool Cloud does not support IP-based login restrictions. This has been a recurring request in the Retool community since at least 2021, and the Retool team has acknowledged the demand. However, their current recommendation is to move to a self-hosted instance if IP restriction is a hard requirement. The good news: Retool's Business tier for self-hosted instances is now priced comparably to the Cloud plans, which removes the historic price barrier that made self-hosting feel prohibitive.

If you're on Cloud and this is blocking you, the pragmatic options are: (1) migrate to a self-hosted instance, or (2) add a network-layer proxy or VPN in front of your Retool Cloud org URL — though the latter is limited and not officially supported.

How to Restrict Retool Logins by IP on a Self-Hosted Instance

If you're running self-hosted Retool — on AWS, GCP, Azure, or your own infrastructure — you have full control over network access. Below are the main approaches.

Option 1: Restrict Access at the Load Balancer or Security Group Level (AWS)

• Navigate to your EC2 Security Groups (or the security group attached to your ALB/ELB).
• Find the inbound rule allowing traffic on port 443 (HTTPS) or 80 (HTTP).
• Change the source from 0.0.0.0/0 to your specific IP range in CIDR notation — e.g., 203.0.113.0/24 for a /24 block, or 203.0.113.5/32 for a single IP.
• Save the rule. Traffic from any IP outside that range will be dropped before it ever reaches Retool.

This is the cleanest approach — it enforces the restriction at the infrastructure layer, independent of Retool's application logic. Even if someone has valid credentials, they can't reach the login page from outside the allowed range.

Option 2: Use a VPN to Gate Access

• Deploy your self-hosted Retool instance in a private subnet with no public internet access.
• Require users to connect to a corporate VPN (e.g., AWS Client VPN, Tailscale, OpenVPN) before they can reach the Retool URL.
• Only traffic originating from the VPN's IP range will be routed to the Retool instance.

This is the most robust option for distributed teams. Users on any device or location can still access Retool — as long as they're connected to the VPN first. It also scales better than maintaining a static IP allowlist as your team grows or works remotely.

Option 3: NGINX or Reverse Proxy IP Allowlist

If you're running Retool behind an NGINX reverse proxy, you can enforce IP restrictions at the proxy layer using the allow and deny directives:

• Open your NGINX server block configuration.
• Add the following inside the location / block:

allow 203.0.113.0/24;
deny all;

• Reload NGINX with nginx -s reload.

Any request from an IP not in your allowlist will receive a 403 Forbidden response before Retool processes it.

What to Do If You're Stuck on Retool Cloud

If migrating to self-hosted isn't feasible right now, here are a few partial mitigations worth considering:

• Enable SSO with your identity provider (Google Workspace, Okta, Azure AD) and enforce IP-based conditional access policies at the IdP level — many enterprise IdPs support this natively.
• Use Retool's permission groups to limit what users can see and do, reducing the blast radius of a compromised account.
• Require MFA for all Retool users via your SSO provider.

None of these are a true substitute for network-layer IP restriction, but they meaningfully reduce risk while you evaluate a self-hosted migration.

Bottom Line

If restricting Retool logins by IP address is a hard security requirement for your team, self-hosting is currently your only supported path. The infrastructure overhead is real, but Retool's self-hosted setup on AWS or GCP is well-documented, and the pricing gap with Cloud has largely closed. If you're handling PII, financial data, or anything with compliance implications, the control you get from self-hosting — IP restrictions included — is usually worth it.