Skip to main content
A managed runner is the CoreWeave-managed component that runs sandboxes inside your CKS cluster. This page covers the full lifecycle: deploy a runner, confirm it is healthy, adjust its configuration as your needs change, and remove it when you no longer need it. For where the runner sits in the sandbox architecture and how the gateway brokers requests to it, see Sandboxes architecture.
CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, CoreWeave Support, or email support@coreweave.com.

Before you begin

Both the CLI and the curl examples on this page authenticate with a CoreWeave API access token. Generate one from the Tokens page in the cloud console and copy the Token Secret value. For more on tokens, see Manage API access tokens. CLI: install the CoreWeave Intelligent CLI (cwic), then run cwic auth login and paste the token when prompted. The token is stored in your local cwic config. Subsequent commands read it automatically. You don’t need to set an environment variable.
curl: export the token in your shell so the examples on this page can pick it up:

Runner commands

The cwic sandbox runner group manages runners. The following table maps each lifecycle task to the command that performs it. Later sections walk through these commands in context. All input accepts YAML or JSON.

Deploy a runner

Each CKS cluster hosts at most one managed runner. To deploy one, supply:
  • Runner ID: a client-assigned human-readable ID, unique within your organization.
  • Zone: the geographic zone the cluster belongs to.
  • Cluster ID (or cluster name): which CKS cluster the runner runs on. You can find both on the Clusters page in the cloud console.
  • Profile bindings: at least one binding, with exactly one default. The profile referenced in each binding must already exist.
The wizard collects cluster, profiles, release channel, and maintenance windows interactively, then opens your editor with a pre-filled spec before submitting:
File mode accepts YAML or JSON, which makes it the preferred path for repeatable setups and a good fit for agents like Claude Code or Codex that generate runner specs on your behalf. The CLI also reads from stdin with -f -.
runner.yaml
Submit the spec:
Note the following behaviors:
  • maintenance_policy.windows is optional. When set, automatic updates apply only during the specified cron windows.
  • runner_group_id is optional. Use it for scheduling affinity when you have multiple runners in the same zone.

Common validation errors

Check runner status

After creation, check the runner’s status to confirm it rolled out successfully and to diagnose problems if it did not.
For a quick summary in tabular form, use the alias get:
Either command accepts the runner ID you supplied on create (prod-us-east-1) or the server-assigned UUID.
The response carries two status fields to track:
  • installStatus: progress of the runner deployment into your cluster (PENDING, PROVISIONING, READY, or FAILED).
  • connectionStatus: live connectivity (CONNECTED or DISCONNECTED). The runner’s heartbeat updates this value. Expect up to 30 seconds of lag.
When installStatus == FAILED, the response includes a structured installError:
remediationHints are the actions you should take. diagnosticDetail also contains internal logs that are useful to attach if you open a support ticket.

Update a runner

The runner edit command supports both an interactive wizard and a file-driven patch. Internally, updates use a field mask: only the fields you change are applied. Everything else is read-only, including installStatus, connectionStatus, timestamps, and the resolved deployment spec. The following paths are mutable:
  • identity.zone
  • identity.runner_group_id
  • managed_spec (whole object)
  • managed_spec.release_channel
  • managed_spec.maintenance_policy
  • managed_spec.overrides
  • profile_bindings (whole list)

Common runner updates

The following examples show the most frequent edits applied to a runner: switching release channels, attaching another profile, and tuning where the runner pod lands in your cluster.

Example: switch release channel

Apply a one-line patch from stdin:
Or write the patch to a file and submit it:
patch.yaml

Example: attach a second profile

profile_bindings is replaced as a whole list. To attach a new profile while you preserve the existing default, send both bindings:
bindings.yaml
The API matches entries by profile_template_id. Missing entries are detached, new entries are attached, and changed entries are updated in place, all in one transaction.

Example: pin node placement through deployment overrides

The managed_spec.overrides field tunes the runner’s own pod, not sandbox pods. Use it when the runner pod requires specific tolerations, node selectors, or runtime classes to land on the right nodes. A common case is routing the runner pod through the SUNK Pod Scheduler so it can run in your SUNK cluster alongside Slurm jobs. Set the scheduler name and the SUNK annotations on the runner overrides. See SUNK Pod Scheduler integration for the available annotations and required setup.
overrides.yaml

Trigger an on-demand runner update

When updateAvailable is true on the runner, you can apply the update immediately rather than wait for the next maintenance window:
The control plane resolves the latest version on the runner’s release channel and bumps target_revision. The in-cluster controller rolls it out.

List runners

To see every runner in your organization, or to narrow the view to a specific zone, cluster, or connection state, use the following list commands.
Filter by zone, cluster, or connection status:

Delete a runner

Remove a runner when you no longer need sandbox capacity on its cluster, or before you redeploy a fresh runner on the same cluster.
The CLI prompts for confirmation. Pass --yes to skip the prompt for scripted use:
Deleting a runner tears down the runner deployment in your cluster. Any sandboxes running on that runner stop. The profiles the runner referenced are not deleted. They remain available for other runners.
Deletion is permanent. If you only want to pause traffic, move sandboxes to another runner before you delete this one.

See also

Last modified on May 29, 2026