A Static Outbound IP for Netlify Functions
There is no static outbound IP for Netlify Functions on the standard plans, and no published list of Netlify addresses to allow-list either — Netlify staff answer this on their own forum with “there is not a list of IP addresses used by Netlify for inclusion in a whitelist”. Third-party writeups describe an Enterprise-only static egress option; we could not confirm that in Netlify's public documentation, so ask Netlify directly rather than taking our word or anyone else's. For everyone else the fix is to route the one allow-listed call through something that holds a fixed address — or, better, to stop needing one.
Why there is no list to ask for
Netlify Functions run on distributed, ephemeral infrastructure across cloud providers, and capacity is added and removed automatically. The outbound address belongs to that infrastructure and is reassigned freely. This is not a gap Netlify has neglected to fill; it is a consequence of the architecture that makes the platform work, which is why the answer on the forum is a flat no rather than a roadmap item.
A published range, if one existed, would cover an enormous amount of other traffic and would not be an allow-list in any useful sense.
Try this before you build anything
Two routes that cost nothing, and between them they cover most people who arrive at this question.
Ask whether the vendor accepts something other than an IP. IP filtering is the bluntest control on the list and many vendors now prefer alternatives: mTLS, a signed request, OAuth client credentials, or a shared secret in a header. It is a five-minute email and it frequently ends the problem. Build infrastructure only after the vendor has said no.
If you control the receiving end, do not use IP filtering at all. When the thing Netlify calls is your own API, a header secret or a signature you verify is stronger than an address list and does not break when infrastructure moves. Netlify's own staff point people at rewrites with headers for the same reason.
When the call really must come from a fixed address
Sometimes the far end is a bank, a filing service or a partner whose security policy is not negotiable. Then the requirement is narrow — one endpoint, one known source — and it does not need Netlify to change.
Run a small always-on box (a $5 VPS, a machine you already own) with a TunnelNet address attached, and have the function make that one outbound call through it. Everything else stays on Netlify exactly as it is.
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, and it is the same address if this integration later runs from somewhere that is not Netlify.
Honest caveats:
- You are adding a hop and a machine you keep running. On a platform chosen so that you do not run machines, that is a real cost, and if the vendor would have accepted a header secret you have built something you did not need.
- It suits named calls, not all egress from your site.
- If you are on Netlify Enterprise, ask them about their static egress option first. First-party beats a third party when it exists.
Verify the source address before you file it
Do not file an address you have not measured from the code path that will really make the call:
curl -4 https://api.ipify.org
Call it from the function, or from the box the function routes through, and check it a second way (curl -4 https://ifconfig.co). Run it more than once — on distributed infrastructure one observation describes one invocation. A mis-filed address fails as a total denial at the far end, 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. Netlify 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
- Supabase Edge Functions — Supabase documents that there is no static egress IP
- 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: