> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Profile examples > Ready-to-POST profile templates and runner bindings for common CoreWeave Sandbox use cases. 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](/products/sandboxes/profiles/profiles) and the [Profile reference](/products/sandboxes/reference/profile). CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, [CoreWeave Support](https://cloud.coreweave.com/contact), or email [support@coreweave.com](mailto: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. ```json title="Profile template" theme={"system"} { "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. ```json title="Profile template" theme={"system"} { "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. ```json title="Profile template" theme={"system"} { "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. ```json title="Profile template" theme={"system"} { "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. ```json title="Profile template" theme={"system"} { "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](/products/sandboxes/operations/managed-runners) can bind multiple templates at once. The following runner hosts all five preceding profiles, with the CI template as the default: ```json title="Multi-profile runner" theme={"system"} { "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`: ```json title="Binding override: different allowlist per region" theme={"system"} { "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 * **[Agentic RL training](/products/sandboxes/client/guides/rl-training)**: RL-specific profiles (reward functions and multi-turn agent rollouts) with working Python code. * **[Understanding profiles](/products/sandboxes/profiles/profiles)**: Detailed reference on templates, bindings, and overrides. * **[Configure a sandbox profile](/products/sandboxes/profiles/configure)**: Egress, ingress, namespace strategy, and runtime class fields used in these examples. * **[Profile reference](/products/sandboxes/reference/profile)**: Every field on the spec.