Can I get a fixed IP address for my Vercel deployments?

Vercel deployments don't have a fixed IP address by default. Builds and Vercel Functions send outbound requests from a dynamic range of addresses, so a backend that filters by source IP will reject them. Two products replace that range with addresses you can allowlist, with Static IPs routing outbound traffic through shared static egress IPs on Pro and Enterprise, and Secure Compute placing your deployments in a dedicated private network on Enterprise.

Here's how to tell which one your backend needs, how to set it up, and where a fixed IP doesn't apply.

Copy link to headingWhy Vercel deployments don't have a fixed IP address by default

Vercel's CDN runs on anycast servers, where many locations answer on the same address, so every request is routed to the closest available infrastructure rather than to one fixed location. Each Vercel Function invocation is handled independently, and outbound requests can leave from a different server each time.

Outbound addresses also shift as Vercel scales its infrastructure, which is why there's no published IP range to add to an allowlist. Pinning your functions to a single region doesn't produce stable outbound addresses either.

To get addresses your backend can rely on, you need to route traffic through Static IPs or Secure Compute. Before you enable either one, confirm that a fixed IP is the control your backend actually requires.

Copy link to headingWhen you need a fixed IP and when identity-based auth works better

A fixed IP is the right tool when the service you're calling can only authorize traffic by source address. Legacy databases, corporate firewalls, and third-party APIs with allowlist-only access controls all fall into that category.

An IP allowlist authorizes traffic by network location, so it needs maintenance every time a range changes or a new service needs access, on every backend that holds a copy of the list. Identity-based controls avoid that upkeep because the credential travels with the request.

Two alternatives cover most modern backends:

• OpenID Connect (OIDC) federation: OpenID Connect on Vercel issues short-lived tokens your functions and builds exchange for cloud credentials, so AWS, Google Cloud, and Azure can authorize Vercel without an IP allowlist.
• Token or certificate auth: API keys, database credentials, and mutual Transport Layer Security (mTLS) tie access to identity rather than network position.

Use IP filtering as one layer rather than the only one. Keep a username and password pair or an authentication key on your backend even after you allowlist a dedicated IP pair, since the addresses alone don't authenticate the caller.

If your backend requires an allowlist, Static IPs is where most teams start.

Copy link to headingHow to get a fixed outbound IP with Static IPs

Static IPs routes outbound traffic from your Vercel Functions through static egress IPs in a Vercel-managed virtual private cloud (VPC). The VPC is shared, with subnet-level isolation between the teams on it, and traffic exits through a managed network address translation (NAT) gateway. Your backend sees the same addresses on every request.

Each region you activate gets its own pair of static IPs, and you can activate up to three regions per project. Static IPs is available on Pro and Enterprise at $100/month per project, plus Private Data Transfer at regional rates.

To enable Static IPs for a project:

1. Open your project in the Vercel dashboard and navigate to Settings.
2. Click the Networking section.
3. Click Manage Active Regions and pick up to three regions close to your backend services to keep latency down.
4. Copy the static IP addresses assigned to each region and add them to your backend service's allowlist.
5. Redeploy the project, then confirm that requests to your backend succeed.

Function traffic routes through the addresses as soon as they're assigned, but build traffic requires the Use Static IPs for builds toggle in the same Networking panel. It's disabled by default, and enabling it means both build and function traffic count as Private Data Transfer.

Static IPs is outbound only, and several limits apply:

• No dedicated infrastructure: The VPC is shared, so a security review that requires an isolated network won't pass on Static IPs.
• No VPC peering: Private connections into your own cloud network require Secure Compute.
• Project-level scope: The addresses apply to every deployment environment in the project. You can't limit them to production or preview.
• Beta features excluded: The extended max duration, large functions, and container images betas aren't supported. See Vercel Functions limits for current compatibility.

Teams that need dedicated infrastructure or a private path into their own cloud use Secure Compute instead.

Copy link to headingHow to get dedicated IP addresses with Secure Compute

Secure Compute places your builds and deployments in a private network that isn't shared with other teams. Each network comes with its own dedicated IP pair, AWS account ID, region, VPC ID, and private address range, which is what satisfies compliance programs that require isolated infrastructure. Teams subject to HIPAA can combine it with a Business Associate Agreement for that reason.

Secure Compute is an Enterprise feature with custom pricing. You can create networks yourself from the dashboard, though self-service creation isn't enabled for every Enterprise team. If you don't see the option, your Vercel account team can provision the network for you.

To create a network and connect a project:

1. Navigate to your team's Settings, open Networking, and click Create Network.
2. Select the Region closest to your backend infrastructure.
3. Expand Advanced options to set a CIDR Address Block, the Classless Inter-Domain Routing (CIDR) range that defines the network's private IPv4 addresses, or to pick specific Availability Zones, then create the network.
4. Open your project's Settings, go to Networking, and select an Active Network for each environment you want to connect.
5. Optionally select a Passive Network in another region for failover, and check Include Builds to put the build container in the network.
6. Click Save, then redeploy the project.

Each project environment connects to one active network, with a passive network used only for regional failover. Once the dedicated IP pair is ready, add it to your backend's access control list alongside your existing credentials.

Beyond dedicated addresses, Secure Compute supports VPC peering with your own AWS VPC, which gives your functions a private path to backends that never accept public traffic. Peering also changes the billing math, since traffic sent over a peering connection doesn't incur data transfer charges, while traffic that leaves the private network over the public internet is billed at $0.15/GB.

A few operational limits apply to every network:

• Projects per network: Up to 100. Split projects across additional networks beyond that.
• VPC peering connections: Up to 50 per network.
• Build provisioning: Builds attached to a network take up to 5 seconds longer while the secure build container is provisioned. Opting the build container out removes that delay.
• Beta features excluded: The same extended max duration, large functions, and container images betas that Static IPs skips aren't available here either.

With both products in view, the choice comes down to how much isolation your requirements call for.

Copy link to headingChoosing between Static IPs and Secure Compute for IP allowlisting

Compare the two products across plans, pricing, isolation, and networking features:

Static IPs covers IP allowlisting for a database or third-party API. Move to Secure Compute when your compliance program requires dedicated infrastructure, or when you need VPC peering or regional failover.

Configure one product per project rather than both. For AWS-hosted backends, a third option avoids the allowlist entirely.

Copy link to headingWhen AWS PrivateLink is a better fit than a fixed IP

If the service you're calling is AWS-hosted and publishes a PrivateLink endpoint service, AWS PrivateLink connects to it privately and removes the need for an allowlist. Vercel provisions a dedicated VPC endpoint for your team, keeps traffic on the AWS private network, and assigns a dedicated AWS Identity and Access Management (IAM) role that the provider allowlists as the connection principal instead of an IP address.

PrivateLink requires Advanced Networking on your team, and it fits a narrower set of backends than Static IPs:

• Supported targets: AWS-hosted databases such as Amazon RDS, Aurora, Neon, and Redshift, software-as-a-service providers that publish an endpoint service, internal services behind an AWS Network Load Balancer, and S3 or DynamoDB.
• Unsupported targets: On-premises backends, services in other clouds, and any service that hasn't published a PrivateLink endpoint service. These backends still need Static IPs or Secure Compute.
• Shared VPC: Each connection is dedicated to your team, but the underlying network is shared. Full isolation requires Secure Compute.

Connections are created from your team's Settings under Networking, and both function and build traffic can route through them. One exclusion applies to all three networking options.

Copy link to headingWhy a fixed IP address doesn't apply to the Edge Runtime or Routing Middleware

Secure Compute applies to Vercel Functions running the Node.js, Ruby, Go, and Python runtimes. The Edge Runtime isn't supported, so functions using it don't send traffic from the dedicated IP pair. Routing Middleware is excluded from Static IPs and PrivateLink connections for the same reason, since those connections are region-specific and Routing Middleware runs at the edge by default.

Edge execution occurs at the location that receives the request, outside the regional network that hosts your static or dedicated addresses.

To give edge logic a fixed egress address, move the IP-restricted call into a Vercel Function on a supported runtime and call that function from your middleware. The function's outbound request routes through Static IPs or Secure Compute as configured, at the cost of one additional network hop. Egress is only half the question, and the inbound half has a different answer.

Copy link to headingCan external services reach your deployment at a fixed inbound IP?

No. Static IPs and Secure Compute both apply to outbound traffic, and Vercel doesn't assign a fixed public IP that external services can use to reach your deployment directly. Inbound requests continue to arrive through the anycast CDN.

To control who reaches your deployment, restrict inbound traffic rather than publishing an address for it:

• Deployment Protection: Requires authentication before a deployment can be viewed, on Hobby and Pro as well as Enterprise.
• Trusted IPs: Limits access to a list of IPv4 addresses and CIDR ranges, so requests from anywhere else return a 404.
• WAF custom rules and IP blocking: Deny, challenge, or rate limit traffic by IP address, path, and other request attributes.

For private inbound access from infrastructure you control, VPC peering with Secure Compute is the closest fit, since your AWS network reaches your functions without crossing the public internet. Placing a third-party proxy in front of a deployment to obtain a fixed inbound address is possible, though it reduces firewall visibility and can trigger distributed denial-of-service (DDoS) mitigation against the proxy's addresses. Once the right product is configured, most of the remaining problems stem from a handful of predictable gaps.

Copy link to headingHow to troubleshoot static IP setup problems

Most setup problems trace back to one of three causes.

Copy link to headingBuild traffic still comes from dynamic IPs

Your functions reach the backend but the build fails against the same allowlist. Anything that runs during the build, including database migrations and content fetches from an IP-restricted content management system, uses dynamic addresses until the build toggle is on. On Secure Compute, the equivalent setting is Include Builds on each connected environment.

Copy link to headingBoth Static IPs and Secure Compute are configured on one project

When a project uses Secure Compute with Static IPs also enabled, Static IPs is ignored and all traffic uses the Secure Compute network. Check which product the project is attached to before you debug an allowlist, and confirm that the addresses in your backend's access control list match that product's addresses.

Copy link to headingYour Git provider blocks Vercel's IP addresses

A GitHub IP allowlist restricts Vercel's access to the GitHub API, which affects repository linking and source access during builds. Static IPs doesn't solve that case, because the connection comes from Vercel's Git integration rather than from your project's network. Deploy through GitHub Actions with vercel build and vercel deploy --prebuilt instead, as described in GitHub IP restrictions.

Checking these three in order, starting with which product the project is attached to, resolves most cases where the addresses look correct but traffic is still rejected.

Copy link to headingNext steps

Once you know which product fits your backend, enable it on the project and add the addresses to your backend's allowlist.

Follow the Static IPs getting started guide to activate regions and allowlist your addresses, or contact Vercel to add Secure Compute to an Enterprise plan.

Copy link to headingRelated resources

• Static IPs
• Secure Compute
• OpenID Connect federation
• Allowlist IP addresses
• Trusted IPs

Copy link to headingFrequently asked questions

Copy link to headingDoes Vercel publish a list of IP addresses I can allowlist?

No. Vercel's outbound addresses are dynamic and change as infrastructure scales, so any published range would go out of date. Enable Static IPs on Pro or Enterprise, or Secure Compute on Enterprise, and allowlist the addresses assigned to your project. Backends that accept OpenID Connect need no allowlist at all.

Copy link to headingCan I get a fixed IP address on the Hobby plan?

Not on Hobby. Static IPs requires Pro or Enterprise, and Secure Compute is Enterprise only. On Hobby, use credentials or OpenID Connect federation to authenticate outbound requests, and use Deployment Protection to control inbound access. Upgrade to Pro when a backend can only authorize traffic by IP address.

Copy link to headingIs IP allowlisting enough to secure my backend?

On its own, no. An allowlist confirms where a request came from, not who sent it. Keep authentication on the backend, including a username and password pair, an authentication key, or mutual TLS, and treat the dedicated or static addresses as one layer of access control rather than the only one.

Copy link to headingHow much does a fixed IP address cost on Vercel?

Static IPs costs $100/month per project on Pro and Enterprise, plus Private Data Transfer billed at regional rates for traffic routed through the addresses. Secure Compute uses custom Enterprise pricing, with Private Data Transfer at $0.15/GB for traffic leaving the private network over the public internet.