Platform base images
Alongside your own custom images, every account can create MicroVMs directly from the platform’s own catalog of base images, or build a custom image 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 images show up badged Platform wherever images are picked: the MicroVM > MicroVMs > Create MicroVM wizard’s Image step, and the Base image picker on MicroVM > Images > Build image - required there for every source kind, not just Dockerfile.
What is in the catalog
Section titled “What is in the catalog”Each base image 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 image appears.
- A set of capability flags:
sshd- the image runs SSH on boot, so you can log in with an SSH key you attach at create time.envd- the image includes envd, the agent that powers the interactive web shell and the E2B SDK’s command/file operations.vcagent- the image 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 MicroVM created from one of those - or a custom image 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 image when you don’t. The exact flags each base carries are shown on its row in MicroVM > Images.
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 MicroVM > Images in your panel for what’s actually offered. The families the platform recognises today:
| Family | Typical distributions | Availability |
|---|---|---|
| Debian-based | Debian, Ubuntu | see the Images page in your panel |
| RHEL-based | AlmaLinux, Rocky Linux | see the Images page in your panel |
| Amazon | Amazon Linux | see the Images 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 image 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 MicroVMs already running an older version keep running it until you deploy a new one.
If your provider runs their own build pipeline for base images, the flow is bake, sign, publish to the mirror, sync into the catalog, then optionally promote a specific version as an image’s current one - the same “current version” concept your own custom images use.