A Static Outbound IP for Supabase Edge Functions
Supabase Edge Functions cannot give you a static egress IP, and Supabase says so in its own documentation rather than leaving you to discover it. Functions run on a globally distributed Deno runtime and the outbound address differs between invocations. The Dedicated IPv4 add-on does not fix this — it is an inbound address for your database. If a vendor needs to allow-list the source of a call made from an Edge Function, the only real answer is to send that one call through something that holds a fixed address.
Why the address moves
Edge Functions execute on Deno Deploy's distributed infrastructure. Your function may run in a different location for each invocation, and the outbound address belongs to that infrastructure, shared with other workloads and reassigned freely. Two calls a second apart can leave from different addresses.
So there is nothing stable to hand a partner, and there is no published range to fall back on either. Supabase's own troubleshooting documentation states that Edge Functions cannot provide static egress IPs for allow-listing. That is an unusually direct answer from a vendor and it is worth trusting: it means no amount of configuration on your side will produce one.
The add-on that looks like the answer and is not
Supabase sells a Dedicated IPv4 add-on, and it is easy to buy it expecting this problem to go away. It solves a different problem in the opposite direction.
- Dedicated IPv4 is ingress. It gives your Postgres database a fixed address that others connect to, so you can be allow-listed by something reaching in, or connect from a network without IPv6.
- It does not change egress. Outbound calls from Edge Functions, and outbound connections made by the database itself, still leave from addresses you do not control and cannot predict.
If what you actually need is for a partner to reach your database on a known address, buy that add-on and stop reading — it is the right tool and it is cheaper than anything else here. This guide is about the other direction: your code calling out to somebody who filters by source address.
When you do not need us at all
Two cases where the honest answer is to change the architecture rather than buy anything:
- You already run a backend somewhere with a stable address. Move the one allow-listed call there and have the Edge Function ask it. A function calling your own API which calls the partner is less moving parts than a function calling a proxy which calls the partner.
- The partner supports something better than IP filtering. Plenty do now — mTLS, signed requests, OAuth client credentials, a shared secret in a header. IP allow-listing is the oldest and bluntest control on the list, and a vendor offering an alternative will usually accept it. Ask before you build infrastructure to satisfy a requirement that may be negotiable.
The answer when the call must come from a fixed address
The requirement is narrow — one partner endpoint, called from one known source — and it does not need Supabase to change. Run a small always-on box (a $5 VPS, a machine you already own, a container on hardware in your office) with a TunnelNet address attached, and have the Edge Function make that one outbound call through it.
What the partner sees is your dedicated address from 23.187.152.0/24, announced by AS396500. It does not change between invocations, it is not shared with anybody else, and it does not depend on where your function happened to execute.
The same address works from anywhere you attach it. That matters more than it sounds: if this integration has to work from an Edge Function today and from a container or a server later, the address survives the move. An address tied to a platform does not.
Two honest caveats, because this is a real trade and not a free win:
- You are adding a hop and a machine. That is one more thing that can be down, and it is yours to keep running. Supabase operates its own infrastructure and that is worth something.
- It suits a small number of specific calls — a partner API, a bank endpoint, a filing service. It is not a general answer to “all egress from my project”.
Verify the source address before you file it
Do not send the partner the address you configured. Send them the address a remote server actually sees, from the code path that will really make the call:
curl -4 https://api.ipify.org
Run it from the box the function will call through, and check it a second way (curl -4 https://ifconfig.co). The one expensive mistake here is assuming a source address instead of measuring it — and a mis-filed address fails as a total denial on the partner's side, not as a warning.
What this costs with us
A dedicated address is $20/month on TunnelNet Full, inbound and outbound on the same address, attached to a machine you already have. TunnelNet Business is $100/month for the same address with a written 8-working-hour response commitment (09:00–17:00 US Central, Monday to Friday), onboarding done with a person who verifies the source address from outside our network before you file it, and our measured uptime published — incidents included.
Plainly, because you are about to put a partner integration on this: we have no SLA and will not offer one until we have six months of measured history, 21 February 2027 at the earliest. A hub failure that withdraws routes takes about 25 seconds to recover, measured — and a hub that stays up while it stops forwarding is not failed over automatically at all. Supabase will quote you better availability numbers than that, and they will be true. Weigh it against what the address itself is worth to you.
Static IP for your platform
The same question, answered for each platform it comes up on most. Every one of them leads with that platform's own native or free answer:
- AWS Lambda — VPC and NAT Gateway, and what that really costs
- Vercel — $100/month per project, and Vercel documents the IPs as shared
- Netlify Functions — no list exists — what to try before building anything
- Heroku — Private Spaces, proxy add-ons, or an address you hold
- Render — shared by default, genuinely dedicated on Pro
- Railway — a Pro-plan toggle, and the “may be shared” caveat
- GitHub Actions — larger runners, or the free self-hosted answer
- Zapier — included on Professional, absent on Free
And the general case, if your platform is not listed: