Using the environments
A ready-to-apply SandboxEnv — an environment with a warm pool, and the one line that points it at another template.
A SandboxEnv binds one template and fans out to member
pools; the pool is what holds the Pods a sandbox is claimed from. One
environment is enough to show how they are put together — the page is the
manifest from
config/samples,
and the other two templates take it with a one-line change.
| Environment | On which template |
|---|---|
| A warm pool | E2B Basic — two Pods kept warm |
Switching it to E2B Docker or
E2B Kata is templateRef.name, plus a
member name and a size that match what the sandbox actually runs: a container
engine needs more memory than a bare sandbox, and a microVM carries its own
kernel inside the same numbers.
Order of application
The template has to exist first, and the cluster id has to be the one the
worker was installed with (controller.localClusterId and
spec.clusters[].clusterID are the same value):
kubectl apply -f config/samples/e2b-basic_sandboxtemplate.yaml
kubectl apply -f config/samples/e2b_sandboxenv.yamlWhat the sample decides, and what the platform does
The member declares the shape (inlineResources), how it scales
(config.scalingGroup, matched by an entry in spec.autoscaling.groups), and
how many Pods to keep warm (spec.replicas). It does not repeat the Pod
spec: the environment renders each member from the template on the next
reconcile, so the file stays the part a person decides.
On a deployment that bills by quota (abx envs <env> prints poolSizing), a
member must name an instance type and a quota label instead of
inlineResources — the CLI guide's pools section has
the three shapes.
Check it
kubectl get sandboxenv e2b
abx envs --cluster YOUR_CLUSTER # the env, and its pools
abx envs e2b --cluster YOUR_CLUSTER # one env, member by memberidleReplicas above zero means a claim will be served instantly; until then
the Pods are still starting.