AI agent sandboxes on Kubernetes

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 is simpler and is SFCrew's default. If you don't want to run the computers at all, a hosted sandbox such as Boat, which SFCrew Cloud uses, or E2B does it for you. The sandbox comparison 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 custom resource.

How to set it up

These steps are for the admin of a self-hosted SFCrew running on a cluster. Kubernetes is configured through the server's environment, not in the app's Settings. The computer providers guide 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 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.