Vercel Connect Supports Secure Compute: Direct Static IP Access to Salesforce and Snowflake

Vercel's integration connection feature, Connect, has received a key update: it now officially supports Secure Compute routing. This means developers can now access service providers like Salesforce and Snowflake that use IP allowlists through dedicated static IP addresses, solving the previous pain point of being blocked due to shared IPs when connecting to enterprise-grade services.

Why IP Allowlists Are a Challenge

Many enterprise-grade SaaS platforms, for security reasons, require callers to add their source IP to a whitelist before accessing their APIs. Salesforce and Snowflake are typical examples—their customer base consists primarily of mid-to-large enterprises, and their security policies tend to be strict.

Vercel Connect previously used a shared IP pool for outbound requests. For ordinary services without IP restrictions, this was fine, but for providers that need to precisely identify the caller, shared IPs become an obstacle: you can't hand a set of unpredictable IP addresses to a provider for whitelist configuration.

The introduction of Secure Compute changes this. Once routing is enabled, requests from Connect to providers go through the dedicated static IP of the selected network instead of Connect's shared IPs.

IP allowlist is an access control mechanism based on source IP addresses. Service providers maintain a list of trusted IPs at the firewall or application layer, and only requests from those addresses are allowed through; all others are rejected. It is often used alongside mTLS, OAuth, and other mechanisms to form defense in depth.

For enterprise-grade SaaS, the value of IP allowlists lies in the fact that even if an attacker steals an API key, they cannot call the interface as long as their egress IP is not on the whitelist, thereby limiting the blast radius of a "credential leak" to a controllable scope. The trade-off is that callers must have stable, pre-communicable egress IPs—which is exactly what shared IP pool architectures struggle to provide.

How to Configure

The configuration process is divided into two phases. The first step is done on the Vercel side: open the target connector's Settings and select an existing network in the Secure Compute Routing section.

The second step is done on the provider side: if the provider uses an IP allowlist, you need to add the static IP address displayed by the selected network to the provider's whitelist settings. Finally, return to Connect and save the changes.

The dedicated IP address displayed after selecting a Secure Compute network in Connect is the address that needs to be submitted to the provider. The entire process does not require writing any additional network configuration code.

Secure Compute is a network isolation capability provided by Vercel that allows teams to create independent compute networks for projects and assign them dedicated static egress IPs. Unlike the default shared infrastructure, these IPs are exclusive to that network and will not change due to traffic from other tenants, so they can be safely registered in third-party services' allowlists.

Once enabled, outbound traffic from the specified connector is sent through the selected network's static IP, while deployment and routing behavior for the rest of the project remain unaffected. This allows the same network policy to cover both traditional proxy scenarios and Connect-managed credential calls.

Credential Management Is Unaffected

It's worth noting that this update only changes the network path of requests; the credential management mechanism remains unchanged. Developers still don't need to store long-lived provider keys in their applications or build OAuth flows themselves. Requests to obtain and refresh access tokens also go through Secure Compute routing, consistent with business API calls.

The application's own direct API routes are also unaffected by this setting—it only applies to provider requests sent by Connect. This design confines network-layer changes to the Connect module, reducing the risk of introducing regressions.

OAuth flow refers to the standard protocol by which an application obtains an access token through an authorization server. In Connect's model, token acquisition and refresh are managed by the platform, and developers don't need to store long-lived provider keys in code or environment variables. This is independent of network path changes: regardless of whether requests go through shared IPs or Secure Compute static IPs, the token issuance and rotation logic remains the same.

The benefit of decoupling the network layer from the credential layer is that teams can adjust either dimension independently without triggering regressions in the other. If a network needs to be changed or an allowlist adjusted in the future, there's no need to redesign the application's authentication code.

Two Limitations to Note

Secure Compute routing does not cover all of Connect's communication scenarios. There are two boundary conditions to be aware of.

Initial creation discovery requests do not go through static IPs. Requests when first creating a connector, as well as all provider discovery requests, bypass the selected network and connect directly to the provider. If the provider also enforces IP whitelist restrictions on these types of requests, they need to be handled separately.

No fallback mechanism. When the selected network is unavailable, routed requests fail directly rather than falling back to Connect's shared IPs. This is a deliberate design choice—preferring failure over degrading to shared IPs, to avoid hard-to-troubleshoot authentication anomalies on the provider side caused by IP changes. For production applications relying on Connect, this means paying attention to the availability of the selected network.

What This Means for Developers

This feature is most valuable for two types of teams: first, teams that are integrating applications on Vercel with enterprise-grade services like Salesforce and Snowflake, who previously may have had to set up an additional proxy layer due to IP restrictions; second, teams already using Secure Compute networks, who can now bring Connect requests under the same network policy management.

From a broader perspective, Vercel is gradually filling in the infrastructure needed to evolve from a deployment platform to an integration platform. Connect handles credential hosting and OAuth flows, while Secure Compute handles network isolation and IP control. Combined, the security boundary for applications on Vercel accessing external enterprise services becomes clearer. For teams that need to deploy applications under compliance frameworks, this layer of capability may be more important than mere deployment convenience.

One-line Summary

Vercel Connect supports Secure Compute routing, enabling access to enterprise services with IP allowlists through dedicated static IPs.

Paragraph Summary

Vercel Connect has added support for Secure Compute routing, allowing outbound requests to services like Salesforce and Snowflake that use IP allowlists to be sent through the selected network's dedicated static IP, rather than being blocked by shared IP pools. Configuration requires just two steps: select a network in Connect's Settings, then add the displayed static IP to the provider's whitelist. The credential management mechanism remains unchanged—developers still don't need to store long-lived keys or build OAuth flows themselves. Note that initial connector creation and discovery requests do not go through static IPs, and requests fail directly when the network is unavailable rather than falling back to shared IPs.