Trusted sources

Databases are private by default; grant access with an IP allowlist from the database's Trusted Sources tab.

Every database rejects connections until you add the connecting host to its trusted sources allowlist. A trusted source is a single IPv4 address or a CIDR range.

Why an allowlist

A database with no network-level protection is one leaked credential away from being reachable by anyone on the internet. Trusted sources add a second layer: even with the correct user and password, a connection from an IP that isn't on the allowlist is refused before authentication is even attempted. This is why every cluster starts with an empty allowlist rather than a permissive one — you opt specific hosts in, instead of opting the internet out.

Add a trusted source

1. 1
   Open the database and find Trusted Sources

   This section only appears when the database's network is set to "Private network". Its subtext is explicit: "Incoming connections are restricted to trusted sources. All other connections will be denied."
2. 2
   Add your own IP the fast way

   Click Use my current IP — it auto-detects the public IP your request is coming from and fills it straight into the input, no need to look it up elsewhere.
3. 3
   Or type one in manually

   Enter a single IPv4 address (e.g. 203.0.113.7) or a CIDR range (e.g. 10.0.0.0/24). Click Add another IP address or CIDR notation to add more rows.
4. 4
   Click Save changes

   The new entries take effect immediately; connections from those IPs or ranges are now accepted.

Remove a trusted source

Each existing entry has its own trash-icon button — click it to remove that IP or range, then Save changes to apply it. Access for that entry is revoked immediately.

Choosing a range

• Prefer a single IPv4 address over a CIDR range whenever exactly one host connects — your laptop, a single app server.
• Reach for a CIDR range only when a whole block of hosts legitimately needs access, such as an autoscaling pool with several outbound addresses — and size the range as tightly as the pool actually requires, not wider "to be safe."
• Treat a broad range (or, worse, one that covers addresses you don't control) as a last resort, not a starting point.

Revisiting the allowlist

A trusted-sources list isn't a set-once setting — it's tied to wherever your app actually runs from, and that changes more often than it seems like it should. Redeploying to a new region, moving hosting providers, adding a load balancer, or scaling an app to a second instance can all change the outbound IP a connection comes from. When any of that happens, the old entry may stop matching anything real, and the new source needs to be added before it can connect.

• Re-check the allowlist after any infrastructure change that could alter your app's outbound IP — a new region, a new host, or a new autoscaling range.
• Remove entries for infrastructure you've decommissioned so the list doesn't quietly accumulate access nobody remembers granting.
• If connections start failing right after an unrelated infrastructure change, check trusted sources before assuming the database itself is the problem.