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

Serverless and changing egress IPs

If your app runs somewhere with rotating egress IPs (Supabase Edge Functions, serverless platforms, some CI runners), you do not need a third-party static-IP proxy. Have the app allowlist its own IP on startup: call GET /v1/ip to read its current address, then POST .../firewall/allow to add it - both with the key it already has. Remove stale entries with the DELETE endpoint or rely on a CIDR range if the platform publishes one.

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.
Certificate-based auth is coming. For environments where IP allowlisting is not enough, client-certificate (mTLS) authentication is on the roadmap.

Get an API key Connecting to a database