Skip to main content
This page collects five complete profile configurations for common use cases, so you can start from a working example rather than build a profile template from scratch. Each example is a full POST /v1beta2/sandbox/profile-templates request body. Paste it into curl -d after you set $TOKEN, then adjust the fields you need. For field-by-field background, see Understanding profiles and the Profile reference.
CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, reach out to CoreWeave Support, or email support@coreweave.com.

​
GPU data-science workbench

A long-lived per-user sandbox with an H100, PyTorch preloaded, generous memory, and internet egress to pull datasets and packages.
Profile template
{
  "profileTemplate": {
    "displayName": "ds-gpu-h100",
    "description": "Data-science workbench; H100, PyTorch, per-user namespace, internet egress",
    "spec": {
      "containerImage": "ghcr.io/myorg/python-ds:3.11-pytorch-2.3",
      "runtimeClass":   "kata-qemu-nvidia-gpu",
      "resourceDefaults": {
        "cpuRequest":    "4",
        "memoryRequest": "16Gi",
        "cpuLimit":      "8",
        "memoryLimit":   "32Gi"
      },
      "instanceTypes": ["h100"],
      "nodeSelector":  { "gpu": "h100" },
      "namespaceConfigJson": "{\"strategy\":\"per-user\",\"namespacePrefix\":\"ds-\"}",
      "networkConfigJson":   "{\"egress\":{\"default\":\"internet\",\"modes\":{\"internet\":{\"type\":\"internet\"}}}}"
    },
    "labels": { "team": "ml", "gpu": "h100" }
  }
}

​
CPU agent with allowlisted egress

A multi-tenant agent profile where each agent lands in its own user namespace, can reach only GitHub and the public npm or PyPI CDNs, and is Kata-isolated.
Profile template
{
  "profileTemplate": {
    "displayName": "agent-allowlist",
    "description": "Per-user agent sandbox with allowlisted egress and Kata isolation",
    "spec": {
      "runtimeClass": "kata-qemu",
      "resourceDefaults": {
        "cpuRequest":    "1",
        "memoryRequest": "2Gi",
        "cpuLimit":      "2",
        "memoryLimit":   "4Gi"
      },
      "namespaceConfigJson": "{\"strategy\":\"per-user\",\"namespacePrefix\":\"agent-\"}",
      "networkConfigJson":   "{\"egress\":{\"default\":\"allowlist\",\"modes\":{\"allowlist\":{\"type\":\"allowlist\",\"cidrs\":[\"140.82.112.0/20\",\"151.101.0.0/16\"]}}}}"
    },
    "labels": { "workload": "agent" }
  }
}

​
Ephemeral CI runner

Short-lived, minimal resources, no persistent state, and restricted to a single CI namespace. No GPUs. gVisor is sufficient.
Profile template
{
  "profileTemplate": {
    "displayName": "ci-test-runner",
    "description": "Ephemeral CI test runner; minimal resources, CI-only namespace, restricted egress",
    "spec": {
      "runtimeClass": "gvisor",
      "resourceDefaults": {
        "cpuRequest":    "250m",
        "memoryRequest": "512Mi",
        "cpuLimit":      "1",
        "memoryLimit":   "2Gi"
      },
      "namespaceConfigJson": "{\"strategy\":\"static\",\"staticNamespace\":\"ci-sandboxes\",\"autoCreate\":false}",
      "networkConfigJson":   "{\"egress\":{\"default\":\"allowlist\",\"modes\":{\"allowlist\":{\"type\":\"allowlist\",\"cidrs\":[\"140.82.112.0/20\"]}}}}"
    },
    "labels": { "workload": "ci" }
  }
}

​
Untrusted code execution

Defense-in-depth: Kata VM isolation, per-profile namespace, and zero egress.
Profile template
{
  "profileTemplate": {
    "displayName": "untrusted-exec",
    "description": "Untrusted code execution; full isolation and no network",
    "spec": {
      "runtimeClass": "kata-qemu",
      "resourceDefaults": {
        "cpuRequest":    "500m",
        "memoryRequest": "512Mi",
        "cpuLimit":      "2",
        "memoryLimit":   "2Gi"
      },
      "namespaceConfigJson": "{\"strategy\":\"per-profile\",\"namespacePrefix\":\"untrusted-\",\"labels\":{\"policy\":\"restricted\"}}",
      "networkConfigJson":   "{\"egress\":{\"default\":\"none\",\"modes\":{\"none\":{\"type\":\"none\"}}}}"
    },
    "labels": { "security": "untrusted" }
  }
}

​
Long-running worker with internal service exposure

A background worker that other org sandboxes can reach on a ClusterIP service, with internet egress for outbound API calls.
Profile template
{
  "profileTemplate": {
    "displayName": "worker-internal-svc",
    "description": "Long-running worker; internet egress + internal service exposure",
    "spec": {
      "containerImage": "ghcr.io/myorg/worker:latest",
      "runtimeClass":   "kata-qemu",
      "resourceDefaults": {
        "cpuRequest":    "1",
        "memoryRequest": "2Gi",
        "cpuLimit":      "4",
        "memoryLimit":   "8Gi"
      },
      "namespaceConfigJson": "{\"strategy\":\"per-org\"}",
      "networkConfigJson":   "{\"egress\":{\"default\":\"internet\",\"modes\":{\"internet\":{\"type\":\"internet\"}}},\"ingress\":{\"internal\":{\"scope\":\"org\",\"service\":{\"serviceType\":\"ClusterIP\"}}}}"
    },
    "labels": { "workload": "worker" }
  }
}

​
Attach templates to a runner

After you create the preceding profile templates, attach them to a runner so sandboxes can use them. A runner can bind multiple templates at once. The following runner hosts all five preceding profiles, with the CI template as the default:
Multi-profile runner
{
  "runnerId": "shared-runner-us-east-1",
  "runner": {
    "displayName": "Shared multi-profile runner (US East)",
    "identity": {
      "zone":      "us-east-1",
      "clusterId": "[YOUR-CKS-CLUSTER-ID]"
    },
    "managedSpec": { "releaseChannel": "RELEASE_CHANNEL_STABLE" },
    "profileBindings": [
      { "profileTemplateId": "[CI-TEST-RUNNER-ID]",      "isDefault": true },
      { "profileTemplateId": "[DS-GPU-H100-ID]",         "profileName": "gpu"        },
      { "profileTemplateId": "[AGENT-ALLOWLIST-ID]",     "profileName": "agent"      },
      { "profileTemplateId": "[UNTRUSTED-EXEC-ID]",      "profileName": "untrusted"  },
      { "profileTemplateId": "[WORKER-INTERNAL-SVC-ID]", "profileName": "worker"     }
    ]
  }
}
Sandboxes launched on this runner pick a profile by profileName (or get the ci-test-runner default).

​
Use binding overrides for per-runner tweaks

When you need the same template to behave differently on different runners, use binding overrides instead of a duplicate template. For example, you can attach the same agent-allowlist template to two runners, but tune the allowlist per region with overridesJson:
Binding override: different allowlist per region
{
  "profileTemplateId": "[AGENT-ALLOWLIST-ID]",
  "profileName":       "agent",
  "overridesJson":     "{\"networkConfigJson\":\"{\\\"egress\\\":{\\\"default\\\":\\\"allowlist\\\",\\\"modes\\\":{\\\"allowlist\\\":{\\\"type\\\":\\\"allowlist\\\",\\\"cidrs\\\":[\\\"140.82.112.0/20\\\",\\\"10.42.0.0/16\\\"]}}}}\"}"
}
Note the double-escaped JSON. networkConfigJson is itself a string field, and overridesJson is a string-encoded ProfileSpec that contains it. Apply overrides at higher-level fields (nodeSelector, runtimeClass, and resourceDefaults) where they don’t require nested escaping.

​
See also

Last modified on May 29, 2026