Sandbox isolation

This page explains where workspace actually run and what isolation guarantees you get out of the box.

The model

Each workspace pod is a : a pod whose primary container runs inside a small, fast-booting guest VM. The host kernel still sees the pod, but the processes inside the workspace see their own kernel, their own dev tree, their own filesystem mounts.

What that buys you

Kernel-CVE blast radius is one workspace. A vulnerability that lets an attacker escape a Linux container would, on a shared-kernel host, give them the host kernel and every other workspace on that node. With a per-pod guest kernel, they get a kernel they already had — the one inside their own VM. They still can’t reach other workspaces.
Real /dev/kvm, real virtualization. The host fleet boots only on hardware that exposes Intel VMX or AMD SVM. Pods that don’t get a working device fail to schedule rather than silently downgrading to weaker isolation.
Predictable cold-start. Booting a guest VM costs roughly one to two seconds on top of normal pod scheduling. That cost is paid once when the workspace comes up, not per request.
System pods on the host kernel. Networking (CNI), DNS, and node-level agents run with the host runtime — they don’t need VM isolation, and forcing them through one would slow scheduling without adding security. Only the pods that run untrusted code opt into the Kata runtime.

How a workspace pod ends up here

When you create a workspace, the scheduler pins the pod to nodes that:

Are part of the sandbox fleet (not the control plane).
Have hardware virtualization available and the Kata runtime installed.
Match any product-tier preferences attached to your account.

If those constraints can’t be satisfied, scheduling fails fast rather than placing the pod on a host that lacks the isolation guarantees. You’ll see the failure surfaced as a workspace-startup error, not a degraded silent fallback.

Networking

Inbound traffic to a workspace lands at Cloudflare first: TLS terminates at the edge, DDoS protection runs at the edge. Cloudflare then forwards to the gateway on the sandbox host running your workspace, which routes the request to the right pod.

Origin firewall rules accept traffic only from Cloudflare’s published IP ranges. The sandbox hosts themselves have no other public exposure — there’s no path into the cluster that bypasses the edge.

Observability

Infrastructure pods on the sandbox fleet — the CNI agent, k8s-gateway, pod-status-sync, CSI, DNS — emit stdout, OpenTelemetry traces, and metrics through a single OTel pipeline tagged with the cluster identity. Operations and engineering see one consistent view of the host fleet across the cluster.

Workspace session pods (yolo-session-*) are intentionally not in that default pipeline — they don’t ship their raw stdout to the same channel as infra pods. Instead, the session pod emits structured events (lane status transitions, heartbeats, lane lifecycle, workspace operations) through Container API → common-api, which forwards them onto the observability pipeline so support and engineering can still follow what’s happening inside a session. The session pod itself stays a tight isolation boundary; signal leaves it only through that gateway.