Vercel Connect adds Secure Compute routing for IP-allowlisted providers like Salesforce and Snowflake

What's new

Vercel has added Secure Compute support to Vercel Connect, the company's service for wiring applications to third-party data providers. According to the Vercel blog, connectors can now send their provider traffic through a chosen network's dedicated static IP addresses rather than the shared addresses Connect otherwise uses. The headline consequence is that Connect can integrate with providers that enforce IP allowlists, with Salesforce and Snowflake named as examples.

How the routing works

Once Secure Compute routing is enabled for a connector, the requests Connect makes to that provider, including the calls that acquire and refresh OAuth access tokens, travel through the selected network's dedicated addresses. The setting only governs Connect's own provider traffic: Vercel notes that an application's direct API routing is left untouched, so nothing else about a deployment's networking shifts.

Credential handling is likewise unaffected. Connect keeps managing tokens on the application's behalf, so developers neither hold provider credentials that never expire inside their code nor have to implement OAuth plumbing by hand.

Enabling it

The changelog describes a short setup path: open the connector's Settings page in the Vercel dashboard, pick an existing network under Secure Compute Routing, and save. If the provider uses an allowlist, you copy the IP addresses the dashboard displays for the selected network into that provider's own configuration. One detail worth flagging is scope: the routing choice applies to the connector and every project that uses it, rather than being configurable per project.

Two caveats

Vercel documents two behaviors to keep in mind before relying on the feature. First, the requests involved in initially creating a connector, along with all provider discovery requests, skip the selected network entirely and go directly to the provider, so not every Connect call will appear from the dedicated addresses. Second, there is no failover: if the chosen network goes down, routed requests fail outright instead of quietly reverting to Connect's shared pool. In practice that makes the network's reliability part of the integration's availability, but it also guarantees traffic never originates from an address the provider hasn't been told about.

Why it matters

IP allowlisting is a standard security control at large organizations, and platforms like Salesforce and Snowflake are frequently configured to accept API traffic only from known addresses. Integration services that run on shared infrastructure can be difficult to fit into that model, since their requests arrive from systems the customer doesn't control. Secure Compute routing closes that gap for Connect users, pairing a predictable egress footprint with the service's existing approach of keeping provider credentials out of application code.

For teams building on Vercel whose data sits behind strict network policies, this can turn Connect from a non-starter into a viable integration path. The trade-off is operational: because there is no fallback, the selected network becomes a production dependency, and teams adopting the feature should choose one they trust and monitor it accordingly.