A Static Outbound IP for Render
Render sells Dedicated IPs on Pro workspaces and above, and unlike most platform offerings of this kind they are genuinely exclusive — Render's documentation says each set is “exclusive to your workspace” and gives you three IPv4 addresses. If you run on Render and can use it, that is the right answer and we will not pretend otherwise. This guide explains what the free default gives you, why it is usually not an allow-list, and the one case where an address you hold still wins.
The default: static, but shared
Every Render service already egresses from static addresses — you can read them in the dashboard under Connect → Outbound. The catch is in Render's own description: a workspace without dedicated IPs uses Render's default outbound ranges, “which are shared by other services in the same region”.
So the addresses do not change, which is genuinely useful, but they are not yours. Handing a partner that range says “allow every Render service in this region”. For a low-stakes internal API that may be fine and it costs nothing — use it. For a bank, a payment processor, or any reviewer who asks whether the source is exclusive to you, the honest answer is no, and the shared range also carries other people's reputation.
Render's own answer: Dedicated IPs
From Render's documentation:
- Pro workspace plan or higher, with an additional monthly fee for each IP set. Render's docs point at their pricing page for the figure — read it there before budgeting rather than trusting a number quoted elsewhere, ours included.
- Three IPv4 addresses per set, and the set is exclusive to your workspace.
- Region-specific. Every address in a set belongs to one selected region, and only services in that region use it. A second region means a second set.
- Workspace-wide or environment-scoped, and an environment-scoped set takes precedence over a workspace-level one.
If you are on Pro or above and everything that needs the allow-list runs on Render in one region, buy Render's Dedicated IPs. It is exclusive, it is operated by Render, there is no extra machine, and nothing below improves on it. We would rather tell you that than sell you a worse fit.
The case where an address you hold still wins
It is narrower than on most platforms, because Render's product is good. It comes down to scope.
Render's set is tied to a workspace and a region. That is exactly right when Render is where your code lives and stays. It is the wrong shape when the allow-list entry has to cover more than Render: a scheduled job on a VPS, a colleague's machine doing a manual reconciliation, a second region, or the same integration after a platform migration. Each of those is another IP set, another region, or another vendor conversation.
A dedicated address from 23.187.152.0/24, announced by AS396500, is one entry that travels. Attach it to a machine in another region, to a box in your office, or to whatever you run after Render, and the partner's allow-list never changes. Addresses that belong to a platform stay with the platform.
Honest caveats:
- You run the machine. Render runs theirs. For a single-region Render workspace this alone usually settles it in Render's favour.
- It covers the calls you deliberately route, not all egress from every service.
Choosing between them
- Render's default shared range if the far end genuinely does not mind other Render services being admitted. Free.
- Render Dedicated IPs if you are on Pro or above and the scope is Render, one region. Exclusive and first-party.
- An address you hold if the same source has to serve Render and things that are not Render, or you expect to move.
Verify the source address before you file it
Do not file the address the dashboard shows without confirming it from the code path that will really make the call:
curl -4 https://api.ipify.org
Run it from the service itself, and check it a second way (curl -4 https://ifconfig.co). If you bought a set, confirm it is actually in effect — an environment-scoped set overrides the workspace one, so a service in an environment you forgot about can still be leaving from the shared range. 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. Render 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
- Supabase Edge Functions — Supabase documents that there is no static egress IP
- Heroku — Private Spaces, proxy add-ons, or an address you hold
- 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: