DigitalOcean MicroVMs: the compute foundation for building your AI agent infrastructure (private preview)

An AI agent uses compute differently than a traditional application. Over a single session, it writes and runs code, calls a model, and waits on a tool or a person before picking the work back up. As a result, it needs real compute in short, intensive bursts. It also needs a hard boundary around the code it just generated, so one agent’s mistake can’t spread to the host or to other customers.

This pattern is not unique to agents. The same pattern of heavy bursts, long idle waits, and strong isolation also applies to:

• Sandboxes for untrusted or generated code

• Per-user environments you create on demand and throw away

• Short-lived jobs such as CI/CD runners and preview environments

Traditional infrastructure does not fit these requirements. An always-on server running around the clock for a workload that is busy only for a few minutes an hour means paying for a lot of idle compute time. Containers start quickly and pack densely, but they share a kernel with their neighbors. This is more trust than you want to place in code an agent just wrote. You can close the gap yourself—with pausing, snapshots, fast startup, and per-tenant isolation—but that requires running your own virtualization platform. When your product is the agent platform, the virtualization layer underneath is undifferentiated work you’d rather not own.

Today, we are introducing DigitalOcean MicroVMs in private preview: isolated virtual machines (VMs) that pause when idle and resume exactly where they left off. MicroVMs are the layer that powers DigitalOcean Managed Agents. Now, they’re also available directly to teams building their own agent infrastructure.

DigitalOcean MicroVMs: one isolated VM per session, paused when idle

A MicroVM is a lightweight virtual machine that runs your container image in its own VM, with its own kernel, isolated from other workloads on the host. You bring a public or private image from DigitalOcean Container Registry, choose a size, and access the running workload over an authenticated HTTPS endpoint. DigitalOcean MicroVMs run on open-source Firecracker technology, so each VM has a real hardware-virtualized boundary rather than a shared kernel.

What differentiates a MicroVM from a traditional VM is how it behaves when the work stops. A MicroVM pauses automatically after a timeout you set and resumes on the next request with its memory, files, and running processes exactly as they were. It consumes compute only while it is running. Checkpoints handle the other half of the problem—the setup tax you would otherwise pay on every start. Boot a MicroVM once and let it load its runtime, dependencies, and models. Then checkpoint that warmed-up state and start new MicroVMs from it, instead of rebuilding the environment each time.

If you’re building agent infrastructure, you can treat this as a disposable machine. It starts fast, retains its state across a pause, and shuts down cleanly when the session ends. DigitalOcean runs the fleet, the isolation, and the lifecycle underneath.

MicroVMs use cases

MicroVMs are a clear fit for agent infrastructure, where every session needs its own isolated environment that starts on demand, pauses while it waits, and resumes with its state intact. The same properties apply to workloads beyond agents, especially any workload that creates many short-lived environments, runs them in bursts, and needs a hard boundary between them.

Here’s where MicroVMs fit:

• Coding and eval workspaces: A hardware-isolate MicroVM for each task, where an agent writes, runs, and tests code, then disposes of the environment when it is done.

• Long-running agent workflows: Agentic workflows that run for hours, pause while they wait on a model or a person, and resume exactly where they left off.

• Parallel reinforcement learning (RL) environments: Many identical environments running side by side and reset sub-second for the next episode.

• Ephemeral data per agent: A throwaway Postgres or scratch store for each agent to read, change, and discard. What it writes survives a pause and is cleared when the session ends.

• Per-tenant tools and MCP servers: Each customer’s tools run in their own VM, so one tenant can never reach another’s.

• Untrusted or generated code: Plugin sandboxes, security analysis, and evaluation jobs, with each run isolated in its own VM.

• Short-lived jobs: CI/CD runners, pull request (PR) preview environments, and ETL steps that run, finish, and shut down.

The common thread across these use cases is the need for many isolated environments, created on demand, busy in bursts, and cheap to discard.

MicroVMs: Already powering DigitalOcean Managed Agents

MicroVMs already power a demanding agent workload at scale: DigitalOcean Managed Agents (available in public preview) runs every agent session inside a MicroVM. Harness Runtime, the execution layer inside Managed Agents, relies on MicroVMs to isolate agent-generated code, pause a session the moment it goes idle, and resume it in under a second with files and state intact. Teams at OpenHands, Qencode, and Amplitude are already building on DigitalOcean Managed Agents.

MicroVMs expose the same primitive directly, and the two products meet different needs. Managed Agents is DigitalOcean’s hosted platform for running agents: you bring an agent, and we operate the runtime, tool access, and scaling underneath it. MicroVMs are the layer operating underneath, for teams who would rather build and control their own execution layer than adopt a managed one. Build your own agent platform, sandbox product, or code-execution service on MicroVMs, or anything that needs fast, isolated compute that pauses when idle.