IP allowlisting

Restrict which IP addresses can reach a database. Each database has its own allowlist, enforced at the network layer, and you can manage it from the dashboard or programmatically with the same API key you use to query - so apps on platforms with changing IPs can keep their own access current.

IP allowlisting is available on paid plans. Free databases that already use IP restrictions keep them for now; this may end as early as December 1, 2026. Compare plans.

Overview

How it works

Allowlisting is per-database and opt-in. A database with no allowlist entries accepts connections from any IP (your credentials and TLS still apply). The moment you add a first entry, the database only accepts connections from the addresses you have listed. Entries can be a single IPv4 or IPv6 address or a CIDR range, so you can allow a whole network at once.

203.0.113.5 - a single IPv4 address
2001:db8::1 - a single IPv6 address
10.0.0.0/24 - a CIDR range (256 addresses)
0.0.0.0/0 - every IPv4 address on the internet (use only on purpose; see the note on workloads hosted on Layerbase below)

The allowlist also applies to the HTTP data endpoints that accept your database credentials: the Neon-compatible /sql endpoint, the Upstash-compatible REST API, the PlanetScale-compatible HTTP API, QuestDB ILP over HTTPS, and the VQueue endpoint on a Valkey database. A request from an address that is not on the allowlist is refused, and on some of these endpoints the refusal looks the same as a wrong password.

Dashboard

Manage it from the dashboard

Open a database, go to its Firewall panel, and add or remove allowed addresses. Each entry takes an IP or CIDR range and an optional label so you remember what it is (for example, office-vpn). Changes apply within seconds.

While restrictions are on, the same panel lists connections the allowlist refused in the last 24 hours: how many, when the last one happened, and which source addresses they came from, split between the HTTP data API and native database connections. If you turned restrictions on and something stopped working, this is where to look. The count starts over when the server restarts, and the panel says so when that happened inside the window.

Refusals from Cloudflare addresses are labeled as such. Cloudflare Workers connect from many rotating Cloudflare addresses, so allowing the one you see will not keep a Worker connected. To connect from a Worker, turn restrictions off for that database and rely on its credentials.

API

Manage it from the API

The allowlist is fully scriptable with the same Authorization: Bearer sk_... key you use for the HTTP query API. An account key works for any of your databases; a database-scoped key works for the database it is scoped to. Four endpoints:

GET /v1/ip - returns the public IP this request came from ({ "ip": "..." })

GET /v1/databases/:id/firewall - list the current allowlist

POST /v1/databases/:id/firewall/allow - add an entry, { "ip": "1.2.3.4", "label": "optional" }

DELETE /v1/databases/:id/firewall/allow/:allowId - remove an entry

add your current IP to a database allowlist

# Set LAYERBASE_API_URL to the server URL from this database Connect panel
$ export LAYERBASE_API_URL='https://<api-host-from-connect-panel>'
# Find the IP this machine connects from
$ curl -s "$LAYERBASE_API_URL/v1/ip" \
    -H "Authorization: Bearer $LAYERBASE_API_KEY"
# => { "ip": "203.0.113.5" }

# Add it to the database allowlist
$ curl -s -X POST "$LAYERBASE_API_URL/v1/databases/$DB_ID/firewall/allow" \
    -H "Authorization: Bearer $LAYERBASE_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{"ip": "203.0.113.5", "label": "ci-runner"}'

Dynamic IPs

Keep a deployment IP current

For a deployment or serverless environment whose public egress IP can change between deployments, use Layerbase Cloud's allow-current-ip.sh helper during startup or deployment. It detects the environment's current public IP and idempotently adds it to one database's allowlist.

run from your deployment environment

# Download the helper without executing it
$ curl --fail --show-error --location \
  --output allow-current-ip.sh \
  https://layerbase.com/scripts/allow-current-ip.sh
$ chmod 700 allow-current-ip.sh

# Set these in your platform secret store, then run:
LAYERBASE_API_KEY
LAYERBASE_DATABASE_ID

$ ./allow-current-ip.sh

The helper requires curl and jq. It does not enable IP restrictions or remove stale entries, so enable restrictions deliberately and review the allowlist over time. A database-scoped API key limits the helper to that database.

This pattern is for an environment with a stable IP during its lifetime. If egress can change on every request or instance, use the platform's published CIDR ranges, mTLS where supported, or a managed static-egress proxy when one is available.

Good to know

Notes

Defense in depth, not the only layer. Allowlisting sits in front of (not instead of) TLS and your database credentials. Keep all three.
Broad ranges cover your networks, not ours. A range such as 0.0.0.0/0 or 10.0.0.0/8 is meant for addresses on the internet and your own networks. It is not a way to admit connections from other workloads running on Layerbase's shared infrastructure, and those connections can be refused even when a range covers them. If your own app running on Layerbase connects to a restricted database by its public hostname, add the exact address that app connects from as a single-address entry, not a range.
Scope your keys. A database-scoped API key can only manage its own database's allowlist, which is the safer key to ship in an app that self-allowlists. Manage keys under Settings.
Need identity, not just a source IP? For environments where IP allowlisting is not enough, client-certificate (mTLS) authentication requires every connection to present a valid certificate in addition to its password (PostgreSQL, Pro plan).

Get an API key Connecting to a database