How to attach Vercel Sandbox to a Secure Compute network

Vercel announced on 30 September 2026 that Vercel Sandbox now supports Secure Compute. You attach a sandbox to your team’s dedicated network with one network ID: networkId in the JavaScript SDK, network_id in the Python SDK, or --network-id on the Sandbox CLI. After that, the sandbox’s public-internet traffic leaves through the network’s static IPs. It can also reach private resources in your own AWS VPC through VPC peering.

This matters if you run agent-written or untrusted code that has to talk to a database, an internal API or a partner service that only accepts known IP addresses. Below: what attaching does, how it differs from a sandbox’s default networking, the setup steps with the commands, how to check it worked, what it costs, and the limits the announcement and docs spell out. The feature is new, and everything here comes from Vercel’s announcement and its Sandbox and Secure Compute docs. Where they say nothing, this page says nothing too.

What attaching a sandbox to a Secure Compute network means

A Vercel Sandbox is an isolated Linux environment you create from code or the CLI. Each one runs in its own Firecracker microVM with a dedicated kernel. Vercel builds it for running untrusted code, such as AI-generated scripts, clean test runs and throwaway debugging environments. Each sandbox has its own network namespace with controlled outbound access.

A Secure Compute network is a dedicated private network that Vercel provisions for your team inside a VPC. It comes with a pair of static IPs that won’t change, a NAT gateway, and isolation from other customers’ traffic. Each network shows its AWS account ID, AWS region, AWS VPC ID and CIDR block. Until now it was used to connect Vercel Functions and build containers to backend infrastructure.

Attaching a sandbox to one of these networks routes the sandbox’s traffic through your team’s network. Two things change:

1. Egress IPs become predictable. Traffic to the public internet exits through one of the network’s two static IPs. You can put those two addresses on a backend’s allowlist.
2. Private resources become reachable. If the network is peered with your AWS VPC, the sandbox can reach resources inside that VPC, such as a database or internal service with no public endpoint.

When a sandbox has no network attached, its public traffic comes from a Vercel infrastructure IP. That address is not yours, and you can’t allowlist it as your own.

Who can use it, and what the 30 September release added

The announcement says the feature is available to Enterprise teams with Secure Compute. You need an existing Secure Compute network before a sandbox can join one.

The release adds three things:

• A networkId option when you create a sandbox, in the JavaScript SDK (@vercel/sandbox) and the Python SDK.
• A --network-id flag on sandbox create in the Sandbox CLI.
• The ability to attach, change or clear the network on an existing sandbox with update (SDK) or sandbox config network-id (CLI).

One catch comes before any code: self-service network creation isn’t available to every Enterprise team. If Create Network doesn’t appear under your team’s Settings > Networking, the Secure Compute docs tell you to ask your Vercel account team to provision a network for you.

How Secure Compute differs from the sandbox controls you already have

Teams that already run sandboxes usually have one of three setups. Each one answers a different question.

Network policy and allowed domains decide where traffic may go

The Sandbox CLI already lets you shape outbound access when you create a sandbox. --network-policy deny-all gives a sandbox no internet access. --allowed-domain ai-gateway.vercel.sh limits it to one domain. sandbox config can update the network policy later. These controls decide which destinations the code may contact.

Secure Compute decides where the traffic comes from and which private network the sandbox sits on. A partner API that allowlists IPs cares about the second question. A policy that blocks exfiltration cares about the first. The CLI lists the two as separate options, so treat them as separate controls and decide on each one.

A VPN client inside the sandbox

The Sandbox docs list VPN clients as a supported workload. You can connect to a VPN provider from inside the sandbox to reach private networks during a session. The trade-off is that the VPN credentials and client live inside the same VM as the untrusted code. With Secure Compute, the routing sits in the network the sandbox is attached to, so the code inside never holds a VPN credential.

Secure Compute on projects

If you already use Secure Compute, it’s attached per project environment, with an active network, an optional passive network for failover, and an optional Include Builds setting. You attach each sandbox by network ID when you create it, or later with update.

If all you need is fixed egress IPs for allowlisting, the Secure Compute docs point to Static IPs as the lighter product for projects. The sandbox announcement and the sandbox Secure Compute guide only describe attaching sandboxes to Secure Compute networks.

Before you start: a network, its ID and an authenticated CLI

1. Have a Secure Compute network. In the dashboard, go to your team’s Settings > Networking and click Create Network. Pick a Region. The docs say to choose the one closest to your backend. Under Advanced options you can set a custom CIDR Address Block and specific Availability Zones. Click Next, review, then Create Network.
2. Plan the CIDR now if you will peer. The CIDR block of your Secure Compute network and the CIDR block of your AWS VPC must not overlap. Pick a range your VPC doesn’t use before you create the network.
3. Copy the Network ID. In Settings > Networking, select the network. The Network ID is in the top-left corner of the page, below the network name. The same page lists the network’s two static IPs. Write them down, because you will use them to check the attachment.
4. Install and log in to a client. For the CLI:

npm i -g sandbox
sandbox login

For code, install the JavaScript SDK (@vercel/sandbox) or the Python SDK and authenticate it as its reference describes.

Attach a new sandbox and prove the egress IP

Pass the network ID when you create the sandbox. It starts on that network. Then run a command that calls a public IP echo service. The service reports the address the request came from, which should be one of your network’s static IPs.

JavaScript:

import { Sandbox } from '@vercel/sandbox';

const sandbox = await Sandbox.create({
  name: 'my-sandbox',
  networkId: '3k9x7m2p5q8w1z4n',
});

const result = await sandbox.runCommand({
  cmd: 'curl',
  args: ['-s', 'https://checkip.amazonaws.com/'],
});

console.log((await result.stdout()).trim()); // One of the network's static IPs

Python:

import asyncio

from vercel import sandbox


async def main() -> None:
    box = await sandbox.create_sandbox(
        name="my-sandbox",
        network_id="3k9x7m2p5q8w1z4n",
    )

    result = await box.run_process(
        "curl",
        ["-s", "https://checkip.amazonaws.com/"],
        capture_output=True,
    )

    print(result.stdout.strip())  # One of the network's static IPs


asyncio.run(main())

CLI:

sandbox create --name my-sandbox --network-id 3k9x7m2p5q8w1z4n
sandbox exec my-sandbox -- curl -s https://checkip.amazonaws.com/

The announcement shows the same create step with npx sandbox@latest create --network-id your_network_id_here if you’d rather not install the CLI globally.

Compare the printed address with the two IPs on the network’s detail page. A match confirms the sandbox is attached. Any other address means the sandbox isn’t using the network, and you should check the ID you passed.

Give the sandbox a name. If you leave out name or --name, Vercel generates one. You need that name for later calls such as Sandbox.get(), get_sandbox(), sandbox config, sandbox stop and sandbox exec, so save it if you let Vercel choose. Names are unique per project and can’t be changed after creation.

Move an existing sandbox onto a network: the change waits for the next session

This is the part of the release most likely to catch you out. A session is one running VM instance inside a sandbox. A persistent sandbox (the default) spans many sessions: it stops, snapshots its filesystem, and resumes later with its configuration reapplied.

When you set networkId at creation, the sandbox starts on the network. When you change it with update, the change takes effect on the sandbox’s next session. A running session keeps its current network until it stops. So the pattern is: update, stop, resume.

On a persistent sandbox you don’t have to start it again yourself. The next SDK call, such as runCommand or run_process, resumes it into a new session on the new network.

JavaScript:

import { Sandbox } from '@vercel/sandbox';

const sandbox = await Sandbox.get({ name: 'my-sandbox' });
await sandbox.update({ networkId: '3k9x7m2p5q8w1z4n' });
await sandbox.stop();

// The next command resumes the sandbox into a new session on the new network
const result = await sandbox.runCommand({
  cmd: 'curl',
  args: ['-s', 'https://checkip.amazonaws.com/'],
});

console.log((await result.stdout()).trim());

Python:

box = await sandbox.get_sandbox(name="my-sandbox")
await box.update(network_id="3k9x7m2p5q8w1z4n")
await box.stop()

result = await box.run_process(
    "curl",
    ["-s", "https://checkip.amazonaws.com/"],
    capture_output=True,
)
print(result.stdout.strip())

CLI:

sandbox config network-id my-sandbox 3k9x7m2p5q8w1z4n
sandbox stop my-sandbox
sandbox exec my-sandbox -- curl -s https://checkip.amazonaws.com/

The same rule applies when you switch a sandbox from one network to another. If an agent is mid-task in a long session, it stays on the old network until that session ends. Sandboxes stop on their own after a timeout (5 minutes by default, set with --timeout on create), but don’t count on that to apply a network change. Call stop yourself and check the IP afterwards.

Reach private resources in your AWS VPC over peering

Static egress IPs cover public endpoints that allowlist addresses. VPC peering covers resources with no public endpoint at all. Vercel accepts a VPC peering connection between your Secure Compute network and your AWS VPC. Once it’s in place, a sandbox attached to that network can reach private resources in the VPC.

1. Check the CIDRs. The Secure Compute network’s CIDR block and your VPC’s CIDR block must not overlap. If they do, create a new network with a custom CIDR under Advanced options.
2. Request the peering from AWS. In your AWS VPC dashboard, create the peering connection with the values from your Secure Compute network settings: your own VPC ID as the requester VPC ID, the AWS account ID, the Vercel network’s VPC Peering ID as the accepter VPC ID, and the Vercel network’s region. Finish the remaining steps as the Secure Compute docs describe.
3. Allow the network in your access controls. Add the network’s IP pair to your backend’s access control list.
4. Keep authentication on. The Secure Compute docs are explicit: you still need a username and password or an authentication key on top of IP filtering. The IPs alone aren’t enough.
5. Test from a sandbox. Attach a sandbox and run a connection check against the private host with sandbox exec, the same way you checked the egress IP.

Point 4 matters more for sandboxes than for functions. Sandboxes exist to run code you don’t fully trust. Any sandbox attached to the network sends traffic from the same two allowlisted IPs as everything else on it. If the IP is your only check, untrusted code gets the same access as your production functions. Give sandboxes their own database user or API key with the narrowest rights the task needs.

Detach a sandbox when the work is done

Clear the network assignment to detach: null in TypeScript, None in Python, none in the CLI. Detaching follows the same session rule as attaching, so stop the sandbox and let the next call resume it.

import { Sandbox } from '@vercel/sandbox';

const sandbox = await Sandbox.get({ name: 'my-sandbox' });
await sandbox.update({ networkId: null });
await sandbox.stop();

const result = await sandbox.runCommand({
  cmd: 'curl',
  args: ['-s', 'https://checkip.amazonaws.com/'],
});

console.log((await result.stdout()).trim()); // A Vercel infrastructure IP

sandbox config network-id my-sandbox none
sandbox stop my-sandbox
sandbox exec my-sandbox -- curl -s https://checkip.amazonaws.com/

After detaching, the echo service reports a Vercel infrastructure IP, which no longer matches either of your network’s static IPs. That confirms the sandbox has left the network.

What an attached sandbox costs

The Sandbox docs set out two billing rules for attached sandboxes:

• Traffic that leaves the private network over the public internet is billed as Private Data Transfer.
• Traffic sent over VPC peering to your AWS environment doesn’t incur data transfer charges.

Vercel keeps the current rates and usage monitoring on the Secure Compute pricing section. Sandboxes that download packages, pull images or call public APIs all generate Private Data Transfer once attached. Attach only the sandboxes that need the network, and let the rest keep default networking.

The limits and gotchas the docs call out

• Enterprise and Secure Compute only. Teams without both can’t use the option.
• Self-service networks aren’t universal. No Create Network button means a request to your Vercel account team.
• Network changes wait for the next session. update doesn’t affect the running session. Stop the sandbox, then verify the IP. Detaching works the same way.
• Generated names get lost. Leave out the name and Vercel picks one. Store it, or you can’t run sandbox config or sandbox stop against that sandbox later.
• Use the Network ID. The ID is shown below the network name on its detail page. That ID is the value you pass to the SDK or CLI.
• CIDRs must not overlap for VPC peering. Fix this when you create the network, because the docs only describe setting the CIDR at that point.
• IP allowlisting isn’t authentication. The docs require credentials on top of the IP pair.
• Region is your call. The Secure Compute docs say to create the network in the region closest to your backend. Sandboxes provision in iad1 by default and take --region on create. The sandbox Secure Compute guide doesn’t state a rule linking the sandbox region to the network region, so run the IP check in the region you deploy to.
• Public egress has a cost. Internet-bound traffic from an attached sandbox is Private Data Transfer. Peered traffic isn’t charged.

A rollout checklist for agent and CI sandboxes

1. Confirm your team is Enterprise with Secure Compute, and find or request a network.
2. Choose the network’s region and CIDR with VPC peering in mind.
3. Note the Network ID and the two static IPs from Settings > Networking.
4. Add the IPs to the target backend’s allowlist and issue a separate, narrowly scoped credential for sandbox workloads.
5. Create a named test sandbox with networkId and confirm the echo service returns one of the two IPs.
6. Set up and test VPC peering if the sandbox needs private resources.
7. Decide which sandboxes get the network and which keep default networking. Add a network policy or allowed domains where untrusted code shouldn’t reach the wider internet.
8. For existing sandboxes, script update, stop, verify. Never assume a running session picked up the change.
9. Watch Private Data Transfer usage in the first weeks after rollout.

Running on Vercel? See how Polylane monitors Vercel in production.