Change network access on a running sandbox

Dynamic network policies in CoreWeave Sandboxes let you change a running sandbox’s network access without restarting its workload. For example, an agent can download dependencies, then restrict outbound traffic before it executes untrusted code. A sandbox references one NetworkConfig, which holds its desired network rules. Update that resource to change access. The placement’s network policy still limits which rules you can request: CoreWeave manages this policy for serverless sandboxes, and your administrator configures it for CoreWeave Kubernetes Service (CKS) runners.

Before you begin

Dynamic network policies support both serverless and CKS sandboxes when the feature is available on the selected runners. Serverless uses CoreWeave-managed runners, so you don’t need your own CKS cluster or runner. Before you begin, make sure you have the following:

A CoreWeave API access token with sandbox_user permission. See Manage API Access Tokens.
NetworkConfig support enabled on the API serving your organization. See Availability and prerequisites.
Live network updates enabled on the runner your sandbox uses. CoreWeave manages this for serverless runners. For a CKS managed runner, set spec.overrides.env.ENABLE_LIVE_NETWORK_UPDATE to the string "true". See Manage runners.
HTTPS hostname grants supported and permitted by the placement’s network policy, as required by the examples in this guide.
curl and jq installed locally.

The examples use serverless placement and JSON requests over Connect at https://api.cwsandbox.com. The Python and TypeScript clients don’t expose NetworkConfig operations. Set your token. Replace [API-ACCESS-TOKEN] with your CoreWeave API access token:

Set the API token

export TOKEN="[API-ACCESS-TOKEN]"

Create and bind a network configuration

Create a caller-owned configuration that permits HTTPS to the Python package index and its download host. Choose an ID that is unique in your organization. This example uses build-egress.

Create a network configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/CreateNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{
    "networkConfig": {
      "networkConfigId": "build-egress",
      "spec": {
        "egress": [
          {"httpsHostname": "pypi.org"},
          {"httpsHostname": "files.pythonhosted.org"}
        ]
      }
    }
  }'

The response is a NetworkConfig with its ID, desired spec, etag, and status. Creation validates rule syntax. When you bind the configuration to a sandbox, the platform checks the runner policy. Create a serverless sandbox that uses the configuration. This example allocates one CPU and 1 GiB of memory:

Create a sandbox with the configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.SandboxService/CreateSandbox' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{
    "sandbox": {
      "spec": {
        "containers": [{
          "name": "main",
          "image": "python:3.12-slim",
          "command": "sleep",
          "args": ["3600"],
          "resources": {"cpu": "1", "memory": "1Gi"}
        }],
        "mode": "SANDBOX_MODE_SERVERLESS",
        "networkConfigId": "build-egress",
        "maxLifetimeSeconds": 3600
      }
    }
  }'

Save the returned sandboxId. The platform applies the initial rules before the sandbox reaches RUNNING. For CKS, change spec.mode to SANDBOX_MODE_CKS and optionally select spec.runnerIds. A configuration can bind to only one non-terminal sandbox at a time. Don’t send both spec.networkConfigId and inline spec.network in the same create request. If you omit networkConfigId, the platform creates a configuration for the sandbox. It copies any inline spec.network rules, or uses an empty configuration that resolves to policy defaults. Read the assigned ID from GetSandbox.spec.networkConfigId.

Update rules for the running sandbox

Before changing the rules, test new HTTPS connections to pypi.org and files.pythonhosted.org from inside the running sandbox. For instructions, see the execution guide. Confirm both connections succeed, and save the probe commands to repeat after the update. Resolve any connection failures before continuing. When you are ready to restrict access, clear the sandbox’s egress grants and deny outbound DNS on UDP and TCP port 53. The update leaves declared ingress unchanged. To reject a stale desired-state write, read the current configuration and pass its etag with the update:

Restrict outbound access

config=$(curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/GetNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"networkConfigId":"build-egress"}') &&
etag=$(printf '%s' "$config" | jq -er '.etag') &&
jq -n --arg etag "$etag" '{
  networkConfigId: "build-egress",
  networkConfig: {
    etag: $etag,
    spec: {egress: [], denyEgress: true, dnsEgress: "DNS_EGRESS_MODE_DENY"}
  },
  updateMask: "spec.egress,spec.denyEgress,spec.dnsEgress"
}' | curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/UpdateNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  --data-binary @-

The response is the updated NetworkConfig. The sandbox keeps running with the same ID and process state. Platform-required traffic, such as permitted storage access on other ports, can remain available. denyEgress isn’t complete network isolation. Use an explicit mask when clearing a list. An empty egress list with denyEgress unset or false restores the policy default. It doesn’t mean deny all.

Verify the result

Replace [SANDBOX-ID] with the ID from creation and inspect the sandbox:

Inspect sandbox network status

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.SandboxService/GetSandbox' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"sandboxId":"[SANDBOX-ID]"}'

Check that the sandbox remains RUNNING, references the same spec.networkConfigId, and reports the updated status.effectiveEgress, status.effectiveIngress, and status.effectiveDnsEgress. The JSON response can omit empty repeated fields. Repeat the connection probes that succeeded before the update. Verify that new outbound HTTPS connections to both previously granted hosts fail and that the existing workload continues to run. Investigate unrelated failures, such as an unavailable destination, before treating a failed probe as evidence of enforcement. Status fields are a stored report of the last successful update, not a live measurement of enforcement.

An update can save the desired configuration before enforcement finishes. A transient failure can leave some changes applied without restoring the previous enforcement. Read the current configuration, reapply the intended rules with its current etag, and verify traffic before relying on a restriction. For a permanent runner rejection, the API attempts to restore the previous desired configuration. See Apply behavior and lifecycle. An etag mismatch requires rereading and reconciling concurrent changes.

Reuse or delete the configuration

When the sandbox terminates, a caller-created configuration becomes available for reuse. Its status.sandboxId can briefly retain the old ID while cleanup completes. You can bind the configuration to a new sandbox or delete it:

Delete an unused network configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/DeleteNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"networkConfigId":"build-egress","allowMissing":true}'

Deletion fails while a non-terminal sandbox uses the configuration. Platform-created configurations are deleted automatically after their sandbox terminates. To copy network intent to another sandbox, copy the configuration’s spec into a new configuration or inline create input. Copying GetSandbox.spec copies the configuration ID, not an independent set of rules.

Supported changes and limits

The following changes and limits apply to dynamic network policies:

You can update egress destination grants, declared ingress sources for existing CUSTOM services, denyEgress, denyIngress, and dnsEgress. Rules must remain within the runner policy.
Service ports and visibility remain create-time settings. See Public endpoints.
HTTPS hostname grants remain HTTPS-only on TCP port 443. You can change hostname grants live only on a sandbox created with at least one httpsHostname grant. To add hostname grants to a sandbox created without them, create a new sandbox.
Some older sandboxes can’t change their hostname grants live, including removing them. If the update is rejected with CWSANDBOX_INVALID_REQUEST, create a new sandbox with the required grants.
The runner must support HTTPS hostname grants. If it can’t enforce them, requests that add or change them return CWSANDBOX_INVALID_REQUEST.

For resource fields, update masks, and error handling, see the NetworkConfig API reference.

Sandboxes

Use sandboxes

Manage sandboxes

Reference

Change network access on a running sandbox

Before you begin

Create and bind a network configuration

Update rules for the running sandbox

Verify the result

Reuse or delete the configuration

Supported changes and limits

​Before you begin

​Create and bind a network configuration

​Update rules for the running sandbox

​Verify the result

​Reuse or delete the configuration

​Supported changes and limits

Before you begin

Create and bind a network configuration

Update rules for the running sandbox

Verify the result

Reuse or delete the configuration

Supported changes and limits