NetworkConfigService manages organization-scoped network configurations for CoreWeave Sandboxes. Each configuration holds desired NetworkOptions and can bind to one non-terminal sandbox. Updating a bound configuration applies the rules to that sandbox without restarting it. For a walkthrough, see Change network access on a running sandbox.
Availability and prerequisites
NetworkConfigService requires NetworkConfig support to be enabled on the API serving your organization. When this support isn’t enabled, its remote procedure calls (RPCs) return UNIMPLEMENTED with reason CWSANDBOX_NOT_IMPLEMENTED. Live updates also require live network updates to be enabled on the runner. For serverless sandboxes, CoreWeave manages these settings. For a CoreWeave Kubernetes Service (CKS) managed runner, set spec.overrides.env.ENABLE_LIVE_NETWORK_UPDATE to the string "true". See Manage runners. If live updates aren’t enabled on the runner, UpdateNetworkConfig returns FAILED_PRECONDITION with reason CWSANDBOX_INVALID_REQUEST.
HTTPS hostname updates also require a runner with HTTPS hostname support and a sandbox created with at least one httpsHostname grant. See Supported changes and limits.
Operations and authentication
The service is hosted athttps://api.cwsandbox.com. Requests require a bearer token with sandbox_user permission and access to the configuration’s organization. Bound updates also require access to the sandbox.
For JSON over Connect, send
POST to /coreweave.sandbox.v1.NetworkConfigService/[RPC-NAME] with the full request message, Content-Type: application/json, and Connect-Protocol-Version: 1. Replace [RPC-NAME] with a method from the table. The REST create and update bindings instead accept the NetworkConfig resource as the body. Request options such as updateMask are query parameters. For generated clients, see Protobuf.
NetworkConfigService is separate from the unavailable NetworkService, which concerns shared sandbox networks.
Resource fields
Field names in the following table use JSON camelCase. Protobuf fields use snake_case.
Create accepts an optional
requestId. List accepts pageSize, pageToken, and an optional platformManaged boolean filter. Omit the filter for both ownership types. Delete accepts allowMissing: true to succeed when the ID is absent.
Sandbox and template fields
SandboxSpec.networkConfigId is optional on creation and immutable afterward. With no ID, the platform creates a configuration from the optional write-only SandboxSpec.network input, or from empty rules that resolve to policy defaults. Sending both fields is invalid.
Sandbox Get and List responses expose the bound networkConfigId and omit inline network. Read NetworkConfig.spec for desired rules and sandbox status.effectiveEgress, status.effectiveIngress, and status.effectiveDnsEgress for the stored effective-state report.
A sandbox template retains inline spec.network as its reusable recipe and can’t store spec.networkConfigId. Each sandbox created from the template receives its own platform-managed configuration. A create-from-template request can instead provide overrides.networkConfigId to bind an unused caller-created configuration. Don’t also provide overrides.network in that request.
Update masks
Update supports these paths:
In JSON, encode
updateMask as a comma-separated string, for example "spec.egress,spec.denyEgress".
The wildcard
"*" works only over binary protobuf, such as gRPC or Connect with protobuf encoding. In JSON Connect requests and the REST updateMask query value, it fails during decoding with INVALID_ARGUMENT, before reaching the handler. That decoding error doesn’t include a CWSANDBOX_* reason.
An omitted mask can’t clear a repeated list. To clear egress, explicitly select spec.egress. Empty egress or ingress with the corresponding deny flag unset or false resolves to the policy default. To deny instead, clear the list and set the deny flag in the same update. A true deny flag and a non-empty list in the same direction are invalid.
To change DNS access, include spec.dnsEgress in the mask and set dnsEgress to DNS_EGRESS_MODE_ALLOW or DNS_EGRESS_MODE_DENY. A sandbox can’t request ALLOW when the runner policy requires DENY. Selecting spec.dnsEgress with DNS_EGRESS_MODE_UNSPECIFIED, or selecting that path while omitting its value, restores the runner policy’s default. This also applies when selecting all five paths for a full replacement. An unspecified policy defaults to ALLOW. Leaving spec.dnsEgress out of the mask preserves the stored mode.
DNS mode controls traffic on UDP/TCP destination port 53, not query-name authorization or DNS over other permitted transports. HTTPS hostname grants use egress[].httpsHostname and remain a separate TCP port 443 permission. Platform-required traffic on other ports can remain available under denyEgress.
Apply behavior and lifecycle
Creating or updating an unbound configuration validates syntax and stores desired rules. Runner-policy validation happens when a sandbox binds the configuration, and again for live updates. Live updates use the gateway’s current cached runner policy, which can briefly lag a policy write. Rules outside the policy are rejected rather than silently narrowed. A bound update waits for a sandbox inCREATING or PREPARING to reach RUNNING, within the request deadline. If the deadline passes first, the request fails with CWSANDBOX_SANDBOX_NOT_READY, and no changes are saved. Updates to a terminating or terminal sandbox fail with CWSANDBOX_SANDBOX_NOT_RUNNING. For a running sandbox, the update resolves the rules, persists desired state, and applies enforcement. Rule lists replace the corresponding grants. They aren’t appended. Services and their visibility are unchanged.
Persistence and enforcement are separate steps. A failure after persistence can leave desired rules, actual traffic permissions, and the sandbox’s effective-state report different. After a transient apply failure, some enforcement changes may already have taken effect and aren’t automatically rolled back.
Retrying the same desired rules reapplies enforcement even when the stored rules already match. After resolving a retryable error, read the current configuration and reapply the intended rules. Reconcile an etag mismatch before retrying. The token protects the desired-state write, not an atomic transaction across enforcement systems.
When a bound update’s resulting spec already matches stored desired state, it reapplies enforcement without checking etag. Don’t rely on the token to reject an unchanged-spec retry. An explicitly empty update mask remains a no-op and doesn’t reapply enforcement.
A permanent CWSANDBOX_INVALID_REQUEST rejection from the runner occurs before enforcement changes. If the update persisted new desired rules, the API attempts to restore the previous desired configuration. This restoration isn’t guaranteed and doesn’t overwrite a newer concurrent update. Read the configuration again after an error. A restoration changes the etag.
Platform-managed configurations are deleted after their sandbox terminates. Caller-created configurations remain and can be rebound or deleted once no non-terminal sandbox uses them. Copy spec into a new configuration to clone rules. Reusing an ID reuses the same resource.
Errors
Adding a sandbox’s first HTTPS hostname grant through an update, rather than at creation, can return
CWSANDBOX_INVALID_REQUEST. Some older sandboxes also reject hostname changes, including removals. In those cases, create a new sandbox with the required hostname grants. The runner must support HTTPS hostname grants to enforce them.