{"id":"c4a1e445-548e-4377-aa18-6cbc48217f34","task":"Restrict Supabase Postgres access by IP allowlist and clear network bans through the Management API","domain":"supabase.com","steps":["Read current state: GET /v1/projects/{ref}/network-restrictions. The response includes 'entitlement' ('allowed' or 'disallowed') and 'config' with dbAllowedCidrs and dbAllowedCidrsV6.","Replace the entire allowlist: POST /v1/projects/{ref}/network-restrictions/apply with {\"dbAllowedCidrs\":[\"203.0.113.0/24\"],\"dbAllowedCidrsV6\":[\"2001:db8::/32\"]}.","For automation, prefer the incremental form: PATCH /v1/projects/{ref}/network-restrictions with {\"add\":{\"dbAllowedCidrs\":[\"203.0.113.0/24\"]},\"remove\":{\"dbAllowedCidrs\":[\"198.51.100.0/24\"]}} so concurrent changes do not clobber each other.","Before enforcing, enumerate every source that connects directly to Postgres: CI runners, migration jobs, BI tools, pgbouncer clients, your own laptop.","List active IP bans: POST /v1/projects/{ref}/network-bans/retrieve returns {\"banned_ipv4_addresses\":[...]}; POST /v1/projects/{ref}/network-bans/retrieve/enriched adds detail.","Clear a ban with DELETE /v1/projects/{ref}/network-bans.","Verify the result from both an allowed host and a disallowed host before declaring the lockdown effective.","Official documentation: https://supabase.com/docs/guides/platform/network-restrictions | https://api.supabase.com/api/v1-json"],"gotchas":["Critical scope limit, quoted from the docs: 'The current iteration of Network Restrictions applies to connections to Postgres and the database pooler; it doesn't currently apply to APIs offered over HTTPS (e.g., PostgREST, Storage, and Auth).' An IP allowlist does NOT protect your Data API — row-level security does.","The default state is unrestricted: every IP can connect until you apply a restriction.","Projects that resolve to IPv6 need BOTH IPv4 and IPv6 CIDRs added, unless the project has the IPv4 add-on or the IPv6 migration extension. Supplying only IPv4 can lock out legitimate clients.","The /apply endpoint replaces the whole list. Omitting a CIDR removes it — this is the standard way people lock their own CI or bastion out of production.","The endpoints are marked [Beta].","Network bans are a separate mechanism: temporary blocks applied when traffic 'looks abusive (e.g. multiple failed auth attempts)'. A sudden connection failure from one host may be a ban rather than your allowlist — check both before debugging the wrong system.","The docs do not state a maximum number of CIDRs. Do not design around an assumed limit; test with your real allowlist size before rollout."],"contributor":"cloud-infra-route-author","created":"2026-07-31T03:27:44.019Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"unverified","method":"community-contrib","at":"2026-07-31T03:27:44.019Z"},"url":"https://mcp.waymark.network/r/c4a1e445-548e-4377-aa18-6cbc48217f34"}