Platform base kits
Alongside your own custom kits, every account can create sandboxes directly from the platform’s own catalog of base kits, or build a custom kit on top of one. These are maintained centrally and kept up to date without any action on your part.
Where to find them
Section titled “Where to find them”Base kits show up badged Platform wherever kits are picked: the Sandboxes > Sandboxes > Launch kit picker, and the Base kit picker on Sandboxes > Kits > Build a kit - required there for every source type, not just Dockerfile.
What is in the catalog
Section titled “What is in the catalog”Each base kit carries:
- An operating system: family, name, version, codename and architecture (for example Debian 13 “trixie”, x86_64), shown with the distribution’s logo wherever the kit appears.
- A set of capability flags:
sshd- the kit runs SSH on boot, so you can log in with an SSH key you attach at create time.envd- the kit includes envd, the agent that powers the interactive web shell and the E2B SDK’s command/file operations.vcagent- the kit includes the platform’s own lightweight guest agent (lifecycle hooks, metrics) without the interactive shell agent.
sandbox-base, debian-13, ubuntu-24.04 and ubuntu-26.04 bake envd; the other platform bases don’t, so a sandbox created from one of those - or a custom kit built on top of one - cannot enable shell ingress. Pick one of the envd-capable bases (or build on one) whenever you need the web shell or E2B command/file operations; pick one of the others for a smaller kit when you don’t. The exact flags each base carries are shown on its row in Sandboxes > Kits.
Operating systems
Section titled “Operating systems”The exact set of available operating systems is a live catalog your provider keeps current, not a fixed list - check Sandboxes > Kits in your panel for what’s actually offered. The families the platform recognises today:
| Family | Typical distributions | Availability |
|---|---|---|
| Debian-based | Debian, Ubuntu | see the Kits page in your panel |
| RHEL-based | AlmaLinux, Rocky Linux | see the Kits page in your panel |
| Amazon | Amazon Linux | see the Kits page in your panel |
How the catalog stays current
Section titled “How the catalog stays current”Your provider’s master server pulls a signed manifest from the platform’s package mirror once a day and verifies its Ed25519 signature before accepting anything from it - a sync that fails signature verification, or whose manifest is missing required fields, changes nothing. New base kit versions and kernel updates published upstream reach your account’s picker automatically on the next sync; you don’t need to do anything to pick them up, and sandboxes already running an older version keep running it until you deploy a new one.
If your provider runs their own build pipeline for base kits, the flow is bake, sign, publish to the mirror, sync into the catalog, then optionally promote a specific version as a kit’s current one - the same “current version” concept your own custom kits use.