Skip to main content
The e2b/k3s template turns an E2B Sandbox into a preconfigured, single-node k3s cluster. kubectl, cluster DNS, networking, storage, and the standard k3s components are configured when the sandbox starts. Use it when an agent or CI job needs a real Kubernetes API without provisioning or sharing a permanent cluster.
The k3s template is in preview and is not yet battle-tested across every Kubernetes workload. It is intended for ephemeral development and testing workflows, not as a highly available environment for hosting production traffic.

Quickstart

Create and connect to a k3s sandbox from the CLI:
kubectl is already configured. On a fresh or resumed sandbox, wait for the node and cluster DNS objects to appear and become ready before deploying:
You can also create the sandbox with the standard E2B SDK:

Deploy and preview an application

This example creates an nginx Deployment and Service, forwards the Service to a sandbox port, and prints an E2B URL that you can open in a browser.
The sandbox remains available for up to 15 minutes so you can open the URL. Kill it earlier with the command printed by the script. To verify in-cluster DNS and ClusterIP routing, run a client pod against the Service:

Where to use it

  • Give a coding agent an isolated cluster for a repository that expects Kubernetes.
  • Validate Helm charts, operators, CRDs, manifests, Services, and DNS in CI.
  • Create a cluster per pull request for integration tests or browser previews.
  • Reproduce Kubernetes issues without provisioning EKS, GKE, or AKS.
  • Test untrusted workloads without sharing a staging cluster.
The useful production pattern is cluster per task: create a sandbox, deploy and test the workload, collect the results, and remove the sandbox. Promote the same images, charts, and manifests to your managed production cluster after validation.
1

Create an isolated k3s sandbox

The agent, CI job, or preview service gets its own Firecracker microVM and Kubernetes control plane.
2

Deploy the production artifacts

Apply the same container images, Helm charts, CRDs, or manifests that will be promoted later.
3

Test the complete workload

Exercise Pods, Services, DNS, storage, and browser-visible endpoints without affecting a shared cluster.
4

Promote and clean up

Send validated artifacts to the production cluster, save any required test output, and kill the sandbox.

Limitations

  • The template runs one Kubernetes node in one sandbox. It does not provide high availability.
  • A sandbox is disposable. Do not treat its local Kubernetes storage as a durable system of record.
  • Multi-node clusters across sandboxes are not supported.
  • Overlay CNIs that require VXLAN, Geneve, or macvlan are not supported. The template uses Flannel’s host-gw backend.
  • IPVS kube-proxy mode and nested-virtualization runtimes such as Kata Containers or KubeVirt are not supported.
For production application hosting, use a managed or otherwise highly available Kubernetes cluster with durable storage, backups, monitoring, and load balancing. Use E2B k3s to develop and validate what you deploy there.