VirtConsole 3.2.2

VirtConsole 3.2.2 adds a new kind of compute to the platform. Next to KVM instances, Kubernetes clusters and managed databases, your customers can now run MicroVMs: Firecracker virtual machines that boot in seconds, are metered by the second, and are built for the workloads that do not fit a long-lived server: AI agent sandboxes, disposable CI runners, preview environments, batch jobs.

It is one resource with three parts. Images are what runs. MicroVMs are running copies of an image. Connectors launch MicroVMs on demand from GitHub and GitLab. Everything else in this post hangs off those three.

Images: build once, run anywhere

A customer builds an image from a Dockerfile on top of a platform base image, imports an existing container image from any registry, or points at a git repository and lets the platform build it. Images are versioned; a MicroVM always runs a named version, and rolling forward or back is picking a different one.

Each image carries runtime defaults: environment variables, exposed ports, and lifecycle hooks (a command to run on start, resume, suspend and terminate). A MicroVM inherits the image’s environment and can override or add keys of its own.

Base images are published and signed by VirtConsole, labelled by operating system, and synced into every installation automatically: Debian 13, Ubuntu 24.04, Ubuntu 26.04, AlmaLinux 10 and Amazon Linux 2023, with Rocky Linux 10 available as an option. Customers and their admins build on top of them and never have to supply a kernel or a root filesystem.

MicroVMs: seconds to boot, seconds on the bill

The create wizard asks for a location, an image and version, a plan, and a network, then the MicroVM is up. From there:

• Lifetime you choose. Leave it uncapped, or set a maximum of up to 8 hours and decide whether the MicroVM pauses or is killed when time runs out. Extend a running MicroVM’s timeout at any point.
• Idle pause and always-on. Pause automatically after a period of no activity, or mark a MicroVM always-on so it never idles.
• Pause and resume. A paused MicroVM keeps its memory and disk on the node and resumes where it left off.
• HTTP ingress with HTTPS. Expose a port on a wildcard sandbox domain or attach a custom domain; certificates are issued and renewed by the platform.
• Public or VPC networking. A MicroVM gets a public IP, a VPC address, or both, exactly like a KVM instance. VPC-only MicroVMs leave through the VPC’s NAT gateway, and the same security groups apply.
• SSH straight in. Pick account SSH keys at create time and they are injected before first boot; the show page prints the ssh root@<ip> command for the public IP or, on a VPC, through your VPN gateway.
• Web shell, logs, live metrics. A terminal into the running MicroVM from the panel, a streaming console log, and CPU, memory, disk and network charts sampled every 15 seconds on the node.

Billing is per second of vCPU and memory plus disk per hour, straight from the plan, with the estimate shown in the wizard before anyone commits.

An E2B-compatible API for AI agents

Every account can create API keys for the MicroVM sandbox API, which speaks the same wire protocol as E2B. Existing E2B code runs against your VirtConsole with two environment variables:

pip install e2b
export E2B_API_KEY=<key from the panel>
export E2B_API_URL=https://<your panel host>/api/e2b

from e2b import Sandbox

sbx = Sandbox.create("sandbox-base")
print(sbx.commands.run("echo hi").stdout)
sbx.kill()

Creating, listing, pausing, resuming and killing sandboxes works from the panel’s own hostname with no DNS setup. When the provider has configured a sandbox domain with wildcard DNS for a location, commands, file transfers and get_host() reach the sandbox’s own ports too, and the card on the API keys page tells the customer exactly which of the two they have.

The API keys page ships a quick start in Python, JavaScript, the CLI, cURL, Anthropic and OpenAI, and the documentation now carries a guide to running sandboxes as agent tools with the Anthropic SDK, the OpenAI Agents SDK, the Vercel AI SDK, LangChain and the Pi coding agent, plus a use-case catalogue for sandboxes, images, MicroVMs, connectors and keys. Beside the E2B surface there is a plain REST API under /api/microvm/* for everything the panel does, using location_id for the location a resource lives in.

Connectors: a fresh MicroVM per CI job

Install the provider’s GitHub App on an organisation, or register a GitLab runner token, and every CI job gets its own MicroVM booted from the image you choose, on the plan you choose, torn down when the job ends. No shared runner state between jobs, no idle runner fleet, and the per-second meter stops the moment the job finishes.

For admins: turn it on per location, know when it is ready

MicroVMs are enabled per hypervisor group, the same switch you already use for managed databases and load balancers. A node joins by enabling the MicroVM engine on its card; the engine automatically binds the node’s file-backed storage with the most free space so images, disks and paused-state snapshots never land on the root filesystem.

A new Readiness page walks through the setup and says what is missing before customers can use the feature: nodes reporting, Firecracker version, the group switch, base image catalog, plans mapped through a plan group, networking, sandbox domain, wildcard certificate and the API mount. Each failing check links to the page that fixes it.

Plans carry vCPU, memory, disk and the three prices; plan groups map plans to locations from a drawer with the plans on one side and the locations on the other. That drawer design now covers every plan group page on the platform: Cloud Service, managed databases, load balancers, volumes and VPN gateways.

The admin MicroVM pages list every customer MicroVM with the node’s live view, force-stop a run, audit API key use, and manage connectors.

Also in this release

• Provider-managed backups. A hypervisor group can carry a default backup policy every new instance inherits, and backups are throttled per node.
• location_id in the customer API. The user REST API, the E2B API, the OpenTofu provider and the MCP server now call a hypervisor group a location; hypervisor_group_id still works as an alias for existing code. The admin API keeps the old name.
• Rebuild a dead node from its backups. Every hypervisor now writes a nightly configuration bundle to its backup storage, and the node page gains a Rebuild from backups action: pick a replacement node and the platform restores each instance from its latest backup chain, re-homes networking and reports progress as a task. The disaster-recovery guide covers the flow end to end.
• ConfigServer Firewall on KVM nodes. The hypervisor agent detects CSF and leaves host port management to it instead of fighting for the INPUT chain. Security groups, VPC NAT and the console proxies keep working, and the CSF guide lists the ports to open in csf.conf.
• Node operations documentation. New admin pages cover enabling MicroVMs end to end, plans and plan groups, images and the catalog, the MicroVM node card, restart and logs.

Thanks for building on VirtConsole. Questions or trouble upgrading, reach us any time.