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.

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 (effectively allow-all; use only on purpose)

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.

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

# Find the IP this machine connects from
$ curl -s https://cloud.layerbase.dev/v1/ip \
    -H "Authorization: Bearer $LAYERBASE_API_KEY"
# => { "ip": "203.0.113.5" }

# Add it to the database allowlist
$ curl -s -X POST https://cloud.layerbase.dev/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.
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