Using Vercel with Microsoft Azure

You can run your frontend on Vercel while your APIs, databases, and internal services stay in Microsoft Azure. Vercel connects to Azure at three layers:

• Network: reach Azure resources that restrict access by IP address or accept traffic only from inside your Virtual Network.
• Identity: authenticate to Azure services with short-lived Microsoft Entra ID credentials instead of stored secrets.
• Source code: build and deploy from a repository on GitHub or using Azure DevOps.

By default, Vercel deployments can egress from any IP address. Using Secure Compute you can give your Vercel projects a dedicated network with a fixed egress surface for IP allowlisting. Additionally, Secure Compute supports direct, private connectivity to your Azure Virtual Network and Azure resources connected to that.

When your Azure services are reachable over the public internet and only need to know which addresses your traffic comes from, static IPs are enough. Vercel offers two options:

• Secure Compute: a dedicated, single-tenant network with its own static IP pair, available as an add-on on Enterprise plans. Use this when you also need network isolation or private connectivity.
• Static IPs: a shared static egress pool on Pro and Enterprise plans, without the dedicated network.

Add the resulting IP addresses to the firewall rules of the Azure resource you're calling, such as the firewall on an Azure SQL Database, an Azure Storage account, or an Azure Front Door instance. Keep authentication in place on top of the IP filtering, because the IP addresses alone aren't a sufficient access control.

When your Azure resources have no public endpoint, connect your Secure Compute network directly to your Azure Virtual Network. Secure Compute gives you a dedicated network that Vercel runs on your behalf, so Vercel can terminate a site-to-site (S2S) VPN between that network and your Azure VPN Gateway. Additional options with higher bandwidth and lower latency are also available.

Once the connection is established, your Vercel Functions route traffic to private addresses in your Virtual Network. This includes Virtual Machines or Kubernetes clusters deployed in the network. It also includes any Azure service exposed through a private endpoint from Azure Private Link: Azure Cosmos DB, Azure SQL Database, Azure Storage, Azure Key Vault, and apps on App Service or Container Apps can all be reached this way.

To scope a connection to your topology and bandwidth requirements, get in touch with our team.

Use OIDC federation so your Vercel deployments authenticate to Microsoft Entra ID with short-lived tokens instead of credentials stored as environment variables. Vercel issues a signed OIDC token to your builds and functions, and workload identity federation exchanges it for an Entra ID access token.

This works for managed Azure services and for APIs you build yourself. Any endpoint that accepts a Microsoft Entra ID access token accepts the credential your deployment obtains, including Azure services like Cosmos DB or Azure Storage, or APIs you host.

Follow Connect to Microsoft Azure to register the application in Entra ID, add the federated credential, and call an Azure service from your code.

Network connectivity and identity are independent choices. You can use OIDC federation on its own over the public internet, use Secure Compute on its own with another authentication method, or combine both so that a private connection carries a keyless, short-lived credential.

Vercel builds and deploys from wherever your code lives:

• GitHub: connect a repository for automatic production deployments on pushes to your production branch and preview deployments on every other push.
• Azure DevOps: use the Vercel Deployment Extension to trigger deployments from Azure Pipelines, whether your code is in Azure Repos or another Git provider connected to your pipeline.