# AI agent sandboxes on Kubernetes If your team already runs [Kubernetes](https://kubernetes.io), your AI agents' computers can run there too. Each computer becomes a pod in a namespace you choose, on your own nodes and network, scheduled and limited like any other workload. [SFCrew](https://sfcrewai.com/) is an open source app for AI teammates that do real work. You talk to each bot in chat, and each one gets its own computer with a desktop, browser, terminal and files that you can watch and take over. When you [host SFCrew yourself](https://sfcrewai.com/self-hosted-ai-agent/) on a cluster, it can create those computers as pods directly through the Kubernetes API, with no Docker socket and no outside sandbox provider. Updated November 4, 2026. ## What is a Kubernetes sandbox? Kubernetes runs containers across a cluster of machines and keeps them within the limits and rules you set. An AI agent sandbox on Kubernetes is a pod set aside for one agent's computer, kept apart from your other workloads by the cluster's own controls. SFCrew creates one plain pod per bot computer from its published computer image, the same Linux desktop it uses for Docker. The SFCrew API and worker talk to the Kubernetes API with their own service account, run commands and move files through `pods/exec`, and show the screen through a gateway inside the pod. That is why they normally run in the same cluster. ## What a bot can do on a Kubernetes computer From the chat it looks the same as any other SFCrew computer. The bot gets a desktop you can watch and take over, and it can: - Browse the web, sign in to sites and download files. - Run commands in a terminal, clone repositories and run scripts. - Read and write files in its workspace, which SFCrew saves when the computer stops and puts back when a new pod starts. - Keep its home folder on a persistent volume instead, if you point SFCrew at the volume that holds its data. ## When to choose Kubernetes Choose Kubernetes when you already run SFCrew or other services on a cluster and want bot computers under the same scheduling, quotas and network policy. It is also the self-hosted way to get a VM-like boundary: set a runtime class such as gVisor or Kata and every computer pod uses it. If you have one server and no cluster, [Docker](https://sfcrewai.com/sandboxes/docker/) is simpler and is SFCrew's default. If you don't want to run the computers at all, a hosted sandbox such as [Boat](https://sfcrewai.com/sandboxes/boat/), which SFCrew Cloud uses, or [E2B](https://sfcrewai.com/sandboxes/e2b/) does it for you. The [sandbox comparison](https://sfcrewai.com/sandboxes/) covers every option. ## Limits and security Each pod runs as the image's own non-root user, with no service account token mounted, all Linux capabilities dropped, privilege escalation off and the `RuntimeDefault` seccomp profile. Those are the same protections SFCrew gives a Docker computer. - Without a runtime class, a pod shares its node's kernel like any container. Set `KUBERNETES_SANDBOX_RUNTIME_CLASS_NAME` to gVisor or Kata for a stronger boundary, if your cluster has one installed. - SFCrew doesn't create a NetworkPolicy. Add one that admits only the SFCrew API, worker and web pods to the computer pods and blocks their egress to private ranges. - CPU and memory limits are unset unless you set them, so add limits or a namespace quota. - Pods are disposable. Anything installed outside the workspace is gone when a pod is replaced, unless the home folder is on a volume. - SFCrew creates plain pods. It does not use the Kubernetes [Agent Sandbox](https://agent-sandbox.sigs.k8s.io) custom resource. ## How to set it up These steps are for the admin of a [self-hosted SFCrew](https://sfcrewai.com/self-hosted-ai-agent/) running on a cluster. Kubernetes is configured through the server's environment, not in the app's Settings. The [computer providers guide](https://sfcrewai.com/docs/self-host-sandbox-providers/) has every variable and a sample Role. 1. Run the SFCrew API, worker and web app in your cluster from the published app image. SFCrew doesn't ship Kubernetes manifests, so you write your own deployments; the [self-hosting guide](https://sfcrewai.com/docs/self-host/) lists the services and the settings each one needs. 2. Create a namespace for computers. The default name is `sfcrew-sandboxes`. 3. Give the API and worker's service account a Role in that namespace that can create, get and delete `pods` and create and get `pods/exec`, and bind it with a RoleBinding. 4. Set `SANDBOX_PROVIDER=kubernetes` on the API and worker, plus `KUBERNETES_SANDBOX_NAMESPACE` if you chose another name. Pin `KUBERNETES_SANDBOX_COMPUTER_IMAGE` to a digest for production. 5. Optionally set `KUBERNETES_SANDBOX_RUNTIME_CLASS_NAME`, `KUBERNETES_SANDBOX_CPU_LIMIT` and `KUBERNETES_SANDBOX_MEMORY_LIMIT`, and add a NetworkPolicy. 6. Make sure the API, worker and web pods can reach computer pods on port 6080 and the display ports from 6100 up, then open a bot's computer to check that the desktop comes up. ## FAQ ### Can I use gVisor or Kata Containers for AI agent sandboxes? Yes, if your cluster has the runtime class installed. Set `KUBERNETES_SANDBOX_RUNTIME_CLASS_NAME` and SFCrew puts it on every computer pod it creates. ### Does SFCrew use the Kubernetes Agent Sandbox project? No. It creates ordinary pods with the Kubernetes API, so it needs no custom resources or extra controllers in your cluster. ### Do bots lose their files when a pod is deleted? Not their workspace. SFCrew saves it when a computer stops and restores it into the next pod. Software installed elsewhere on the pod is lost unless you keep the home folder on a persistent volume. ### Can the SFCrew API run outside the cluster? It can use a kubeconfig, but it also needs to reach each pod's IP for the screen, so in practice the API and worker run inside the cluster. ## More sandboxes for AI agents - [Compare all sandboxes](https://sfcrewai.com/sandboxes/) - [Boat](https://sfcrewai.com/sandboxes/boat/): Many bots with separate logins - [E2B](https://sfcrewai.com/sandboxes/e2b/): Public or multi-user deployments - [Daytona](https://sfcrewai.com/sandboxes/daytona/): Teams already on Daytona - [Novita](https://sfcrewai.com/sandboxes/novita/): Bots that pick up where they left off - [Railway](https://sfcrewai.com/sandboxes/railway/): Running everything in one Railway account - [Wuying](https://sfcrewai.com/sandboxes/wuying/): Windows apps, Alibaba Cloud and mainland China - [Docker](https://sfcrewai.com/sandboxes/docker/): Self-hosting with no cloud account - [Your computer](https://sfcrewai.com/sandboxes/your-computer/): Bots that need your real apps and logins ## Sources - [Kubernetes](https://kubernetes.io) - [Kubernetes, runtime classes](https://kubernetes.io/docs/concepts/containers/runtime-class/) - [gVisor](https://gvisor.dev) - [Kata Containers](https://katacontainers.io) - [Kubernetes Agent Sandbox](https://agent-sandbox.sigs.k8s.io) - [SFCrew, computer providers](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host-sandbox-providers.md) - [SFCrew, computer runtime and isolation](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/computer-runtime.md) - [SFCrew, self-hosting](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host.md)