TL;DR - Database IP whitelisting restricts connections to your database server to only specific, approved IP addresses. Every major cloud provider supports it and most enable it by default. - The main problem: your IP address changes. Home ISPs, mobile hotspots, coffee shop Wi-Fi, and even some corporate networks use dynamic IPs. Every time your IP changes, your database connection breaks. - This guide covers step-by-step whitelisting instructions for AWS RDS, DigitalOcean, Google Cloud SQL, Azure, and Hetzner. - Three approaches to solve the dynamic IP problem: VPN (complex), SSH tunnel (manual), or a static IP gateway like DBEverywhere (set once, works from any network). - DBEverywhere gives you a single static IP to whitelist. Connect from any browser, any network, any device. Free tier available.

Table of Contents

• What Is Database IP Whitelisting?
• Why IP Whitelisting Matters More Than You Think
• The Dynamic IP Problem
• How to Whitelist an IP on Every Major Cloud Provider
• Three Approaches to Stable Database Access
• VPN vs. SSH Tunnel vs. Static IP Gateway: A Comparison
• The Static IP Approach
• FAQ
• Conclusion

The Developer's Guide to Database IP Whitelisting

If you've ever tried to connect to a managed database from your laptop and been met with a timeout, the answer is almost always the same: your IP isn't whitelisted. Database IP whitelisting is the first line of defense for every managed database service, and understanding how to configure it properly — and how to stop fighting with it — is essential for any developer who works with remote databases.

This guide walks through what IP whitelisting is, why cloud providers enforce it, how to set it up on five major platforms, and three approaches to solving the most common frustration: your IP address keeps changing.

What Is Database IP Whitelisting?

Database IP whitelisting (also called an IP allow list) is a firewall rule that permits connections to your database server only from specific IP addresses. Any connection attempt from an IP not on the list is silently dropped — the client sees a timeout, not an authentication error.

It works at the network layer, before your database even evaluates credentials. Think of it as a bouncer checking IDs at the door. Even if someone has the correct username and password, they can't connect if their IP isn't on the list.

Every major cloud database provider implements this:

• AWS RDS uses Security Groups with inbound rules
• DigitalOcean Managed Databases uses Trusted Sources
• Google Cloud SQL uses Authorized Networks
• Azure Database uses Server Firewall Rules
• Hetzner Cloud uses Cloud Firewalls

The rule syntax varies by provider, but the concept is the same everywhere: you specify one or more IP addresses or CIDR ranges, and only traffic from those addresses can reach your database port (typically 3306 for MySQL, 5432 for PostgreSQL, 27017 for MongoDB, or 6379 for Redis).

A single-host entry like 203.0.113.42/32 allows exactly one IP. A range like 203.0.113.0/24 allows 256 addresses (203.0.113.0 through 203.0.113.255). The /32 suffix means "this exact address" — it's the most restrictive and most secure option for whitelisting.

Why IP Whitelisting Matters More Than You Think

You might wonder why database credentials alone aren't enough. After all, a 32-character password with mixed case, numbers, and symbols is hard to brute-force. The issue is that credentials protect against unauthorized authentication, while IP whitelisting protects against unauthorized connection attempts entirely.

Without IP whitelisting, your database port is reachable from every IP address on the internet. That means:

• Brute-force attacks can target your authentication layer directly. Automated scanners continuously probe common database ports. Shodan indexes over 3.6 million MySQL instances visible on the public internet.
• Zero-day exploits in the database engine itself become exploitable by anyone, not just those who can reach the port. When a critical CVE drops for MySQL or PostgreSQL, every internet-exposed instance is a target.
• Credential leaks become catastrophic. If a database password ends up in a Git commit, a .env file on a public S3 bucket, or a Slack message screenshot, anyone who finds it can connect immediately.

With IP whitelisting, all three threats are neutralized at the network level. A leaked password is useless without network access from an approved IP. Brute-force scanners never reach your authentication layer. Zero-day exploits require the attacker to first compromise a machine at an approved IP address.

This is why every managed database provider ships with IP whitelisting enabled and an empty allow list by default. It is not optional security — it is the baseline.

The Dynamic IP Problem

Here's where theory meets frustration. IP whitelisting works perfectly when your IP address is stable. For servers and infrastructure, it usually is. For developers, it usually isn't.

Home ISPs assign dynamic IPs. Most residential internet connections use DHCP, which means your public IP address can change every time your router reboots, every time your ISP rotates its pool, or just periodically on a lease timer. Comcast, Spectrum, AT&T, and most global ISPs do this by default. You can sometimes get a static IP for an extra $10-15/month, but that only solves the problem for one location.

Mobile networks rotate IPs constantly. Tethering from your phone or working from a mobile hotspot means your IP can change mid-session. Carrier-grade NAT (CGNAT) makes this worse — thousands of subscribers share IP pools, and your outbound IP can shift without warning.

Coffee shops, coworking spaces, airports. Every time you change Wi-Fi networks, you get a new IP. If you travel for work or split time between an office and home, you're updating firewall rules constantly.

VPNs don't always help. Commercial VPNs (NordVPN, ExpressVPN) rotate their exit IPs and share them across thousands of users. Whitelisting a VPN's IP means whitelisting every customer on that VPN server — that defeats the purpose entirely.

The result is a painful cycle: connect from a new network, get a timeout, Google "what is my IP," update the firewall rule, wait for propagation, try again. Multiply this across a team of developers and it becomes a real productivity drain.

How to Whitelist an IP on Every Major Cloud Provider

Below are step-by-step instructions for the five most common managed database platforms. In each case, you'll need to know the IP address you want to whitelist. You can find your current public IP by visiting whatismyipaddress.com or running curl -s ifconfig.me in your terminal.

AWS RDS: Security Groups

AWS RDS uses VPC Security Groups to control inbound traffic. Each RDS instance is associated with one or more security groups, and each group contains inbound rules specifying allowed IP ranges and ports.

1. Open the AWS Console and navigate to RDS > Databases
2. Click your database instance and find VPC security groups under Connectivity & security
3. Click the security group link to open it in the EC2 console
4. Select the Inbound rules tab and click Edit inbound rules
5. Click Add rule:
6. Type: MySQL/Aurora (port 3306) or PostgreSQL (port 5432)
7. Source: Custom, then enter your IP in CIDR notation (e.g., 203.0.113.42/32)
8. Description: Something identifiable, like "Office IP" or "DBEverywhere gateway"
9. Click Save rules

Changes take effect within seconds. No restart needed.

Tip: If you use a static IP service like DBEverywhere, you add that one IP here and never touch this screen again — regardless of where your team members are physically located.

Read more: How to whitelist IPs for AWS RDS ->

DigitalOcean: Trusted Sources

DigitalOcean Managed Databases use Trusted Sources to restrict access. By default, new database clusters allow connections from all IPs — you should lock this down immediately.

1. Open the DigitalOcean Cloud Console and navigate to Databases
2. Click your database cluster
3. Scroll to the Trusted Sources section in the Overview tab
4. Click Edit and then Add Trusted Source
5. Enter your IP address (e.g., 203.0.113.42) or select an existing Droplet/Kubernetes cluster
6. Click Save

Once you add at least one trusted source, all other IPs are blocked. DigitalOcean does not use CIDR notation here — you enter individual IPs or select cloud resources.

Important: If you lock yourself out by adding a trusted source that doesn't include your current IP, you can still edit the trusted sources list from the DigitalOcean control panel. The control panel always has access.

Read more: DigitalOcean trusted sources setup ->

Google Cloud SQL: Authorized Networks

Google Cloud SQL uses Authorized Networks to control external access. By default, no external IPs are authorized.

1. Open the Google Cloud Console and navigate to SQL
2. Click your instance
3. Click Connections in the left sidebar
4. Under the Networking tab, find Authorized networks
5. Click Add a network:
6. Name: A label for this entry (e.g., "DBEverywhere static IP")
7. Network: Your IP in CIDR notation (e.g., 203.0.113.42/32)
8. Click Done, then Save

Changes can take a few minutes to propagate. Cloud SQL also supports private IP via VPC peering, but that requires your client to be inside the same VPC — not useful for browser-based access.

Read more: Google Cloud SQL authorized networks ->

Azure Database: Server Firewall Rules

Azure Database for MySQL and PostgreSQL uses server-level firewall rules that specify allowed IP ranges.

1. Open the Azure Portal and navigate to your database server
2. Under Security, click Networking (or Connection security for older configurations)
3. Under Firewall rules, click Add current client IP address (Azure auto-detects your IP) or manually add a rule:
4. Rule name: A label (e.g., "dbeverywhere-gateway")
5. Start IP address: 203.0.113.42
6. End IP address: 203.0.113.42 (same value for a single IP)
7. Click Save

Azure uses IP ranges rather than CIDR notation. For a single IP, set the start and end to the same address. Rules take up to 5 minutes to take effect.

Note: Azure also provides a toggle to "Allow access to Azure services." This whitelists all Azure-internal IPs and is overly broad for most use cases. Leave it off unless you specifically need it.

Read more: Azure database firewall configuration ->

Hetzner: Cloud Firewall

Hetzner Cloud uses Cloud Firewalls that you attach to servers. If you're running a database on a Hetzner Cloud Server (not managed — Hetzner doesn't offer managed databases), you configure the firewall at the server level.

1. Open the Hetzner Cloud Console and navigate to Firewalls
2. Click Create Firewall (or edit an existing one)
3. Add an Inbound Rule:
4. Protocol: TCP
5. Port: 3306 (MySQL) or 5432 (PostgreSQL)
6. Source IPs: Your IP in CIDR notation (e.g., 203.0.113.42/32)
7. Under Apply to, select the server(s) running your database
8. Click Create Firewall

Hetzner firewalls are stateful — you only need to define the inbound rule. Return traffic is automatically allowed.

Read more: Hetzner cloud firewall setup ->

Three Approaches to Stable Database Access

Once you understand the provider-specific setup, the real question is: how do you maintain stable access when your IP changes? There are three common approaches, each with different tradeoffs.

Approach 1: VPN with a Static Exit IP

Run your own VPN server (WireGuard or OpenVPN) on a VPS with a static IP. Whitelist the VPS IP in your database firewall. Every developer connects through the VPN, and all database traffic exits from the same IP.

Pros: - Works for all database types and protocols - Encrypts all traffic between your device and the VPN server - One IP to whitelist per VPN server

Cons: - You're managing a VPN server now — setup, updates, user management, certificate rotation - Adds latency to every query (your traffic goes: laptop -> VPN server -> database) - If the VPN server goes down, everyone loses database access - Some networks (hotels, corporate Wi-Fi) block VPN protocols - Each developer needs to install and configure a VPN client

This is the "right" approach if you already have a VPN for other purposes. If you're setting one up purely for database access, it's significant overhead for a narrow use case.

Approach 2: SSH Tunnel Through a Bastion Host

Set up a bastion host (jump server) with a static IP in the same network as your database. Whitelist the bastion's IP. Developers create SSH tunnels to forward their local port to the database:

ssh -L 3306:your-db-host.example.com:3306 user@bastion.example.com

Then connect your database client to localhost:3306, and traffic flows through the tunnel.

Pros: - Leverages existing SSH infrastructure - No additional software beyond an SSH client - Fine-grained access control via SSH keys

Cons: - Each developer sets up the tunnel manually, every session - Tunnels break when your laptop sleeps, your Wi-Fi drops, or you switch networks - Requires managing SSH keys, user accounts, and the bastion host itself - Not practical for browser-based tools — phpMyAdmin can't use your local SSH tunnel

SSH tunnels work well for command-line clients and desktop GUI tools. They're less practical when you need browser-based access or when your team includes people who aren't comfortable with terminal commands.

Approach 3: Static IP Gateway (Set Once, Access Forever)

Use a service that routes your database connections through a known static IP. Whitelist that IP once. Connect from any browser, any network, any device — the gateway IP never changes.

Pros: - One-time firewall setup, regardless of team size or location - No VPN client, no SSH tunnel, no terminal required - Works from any network, including mobile and restricted Wi-Fi - No infrastructure to manage

Cons: - Your database traffic routes through a third party - Monthly cost (though typically less than running your own VPN server)

This is the approach DBEverywhere takes. You whitelist one IP address in your database firewall. Every session — whether you're on your home network, your phone, or an airport lounge — connects through that same IP. The firewall rule never needs to change.

VPN vs. SSH Tunnel vs. Static IP Gateway: A Comparison

The Static IP Approach

DBEverywhere provides a static IP gateway purpose-built for this use case. Here's how it works:

1. Whitelist the DBEverywhere IP in your database firewall (one time, using the steps in the provider sections above)
2. Open your browser and go to dbeverywhere.com
3. Enter your connection details — host, port, username, password
4. You're in. phpMyAdmin or Adminer loads in your browser, connected to your database through the static IP you already whitelisted

Your credentials are used for the session and not stored (unless you explicitly opt in on the paid tier). The connection routes from DBEverywhere's static IP to your database. From your database firewall's perspective, every connection comes from the same trusted address.

The free tier gives you 5 sessions per month with a 20-minute timeout. The paid tier ($5/month) provides unlimited sessions, 8-hour timeouts, saved connections, and SSH tunnel support for databases behind bastion hosts.

Try it free at dbeverywhere.com ->

FAQ

Is 0.0.0.0/0 safe to whitelist?

No. The CIDR range 0.0.0.0/0 means "every IPv4 address on the internet." Adding this to your database firewall rules effectively disables IP whitelisting entirely. Some developers use it during initial setup or debugging and forget to remove it. This is one of the most common and dangerous database security misconfigurations. Always use the narrowest CIDR range possible — ideally /32 for individual IPs.

How do I find my current public IP address?

From a terminal, run curl -s ifconfig.me or curl -s checkip.amazonaws.com. From a browser, visit whatismyipaddress.com. Note that your public IP may differ from the private IP shown in your system's network settings (e.g., 192.168.x.x or 10.x.x.x). You need the public IP for database firewall rules.

Does IP whitelisting replace the need for a database password?

No. IP whitelisting and authentication serve different purposes. IP whitelisting controls who can attempt to connect. Authentication (username/password) controls who can actually log in. You need both. A strong password without IP whitelisting leaves your database exposed to brute-force attacks from the entire internet. IP whitelisting without a password would let anyone at the approved IP connect. Use both layers together.

Can I whitelist a dynamic IP?

Technically yes, but it requires updating your firewall rule every time your IP changes. Some developers script this — a cron job that checks the current IP and updates AWS Security Groups via the CLI, for example. This works but is fragile, creates brief windows where the old IP is still authorized, and doesn't help when you're on a network where you can't run scripts. A better long-term solution is to route through a static IP, whether via VPN, bastion host, or a gateway service.

How many IPs can I whitelist?

It depends on the provider. AWS Security Groups allow up to 60 inbound rules per group by default (increasable to 200 via support request). DigitalOcean Trusted Sources supports up to 30 entries per database cluster. Google Cloud SQL allows up to 256 authorized networks per instance. Azure allows up to 128 server-level firewall rules. For most teams, these limits are not a constraint — but they're another reason to consolidate access through a single static IP rather than whitelisting every developer's home IP individually.

Conclusion

Database IP whitelisting is foundational to database security, and every cloud provider enforces it for good reason. The challenge isn't the concept — it's the operational friction of maintaining accurate firewall rules when developer IPs are constantly changing.

You have three paths: manage a VPN, set up SSH tunnels, or route through a static IP gateway. The first two give you full control at the cost of infrastructure overhead. The third — a static IP service like DBEverywhere — gives you a single IP to whitelist once, with browser-based access from anywhere, and zero infrastructure to maintain.

Whichever approach you choose, the worst option is the one most developers default to: widening the firewall rules to 0.0.0.0/0 because updating them is annoying. Pick an approach that makes the secure path the easy path, and you won't be tempted to compromise.

Get a static IP for your database access at dbeverywhere.com ->