Building a computer that can pause and resume in milliseconds: Inside the MicroVM architecture behind Managed Agents

Building a computer that can pause and resume in milliseconds: Inside the MicroVM architecture behind Managed Agents | DigitalOcean

© 2026 DigitalOcean, LLC. Sitemap .

Engineering

Building a computer that can pause and resume in milliseconds: Inside the MicroVM architecture behind Managed Agents

By Braden Bassingthwaite

Updated: October 15, 2026 20 min read

<- Back to blog home

An agent starts a test suite, edits a file, calls a model, and waits. Later, it resumes work with the same processes, files, and context. Sometimes it needs to fork that environment and try two approaches at once.

These workloads force a tradeoff on conventional infrastructure. Keep a machine running, and idle sessions continue to occupy resources. Destroy it, and the next interaction must rebuild the environment. Saving the filesystem helps, but it does not preserve a running interpreter, an in-memory index, or a process halfway through a task.

DigitalOcean Managed Agents , now in public preview, require a different foundation, so Harness Runtime gives each session a Firecracker microVM. The MicroVM platform underneath manages isolation, networking, storage, and checkpoint restore. Action Gateway complements that runtime with governed access to tools.

Firecracker uses KVM hardware virtualization , giving each guest its own kernel rather than sharing the host kernel as a container does. Network namespaces complement that VM boundary (not replace it).

The central design decision is to separate a session from the host that runs it:

A guest keeps a stable network configuration.

Immutable storage holds its checkpointed disk and memory.

Host-side proxies apply network policy and can attach credentials without putting those credentials in the guest environment.

Let&#x2019;s examine the MicroVM architecture design behind Managed Agents: from the cell control plane to a single memory page fault. Along the way, we will explain why our guests share an IP address, why a disk write usually stays local, and why near instant restore comes from loading less, not loading faster.

Start with a cell instead of a global scheduler

A cell is a single self-contained, region-scoped instance of the MicroVM platform. It brings its own VPC and DigitalOcean Kubernetes cluster, managed PostgreSQL database and Spaces bucket, and pool of hypervisor hosts. Because each cell is complete on its own, a region can run many of them side by side.

Cells give us a repeatable unit of capacity and operation. We can add host capacity within a cell or add another cell. A cell-local database or routing failure does not require every other cell to share that failure. Cells still depend on shared regional and platform services. A cell limits the blast radius of a failure but does not eliminate shared dependencies. High availability was a foundational design principle rather than an afterthought. By serving as a distinct unit for capacity, lifecycle coordination, and failure isolation, each cell prevents localized disruptions from impacting the broader infrastructure. This design sustains our current operational footprint while maintaining fault boundaries as the fleet expands into additional regions.

We split each cell into two parts:

The control plane , which owns lifecycle decisions, placement, and durable metadata. It runs on Kubernetes .

The host plane , which runs Firecracker and the services that provide guest networking, disks, and memory. It runs on hypervisor Droplets.

A cell separates request routing, lifecycle coordination, and durable state. This diagram shows selected paths, not every dependency.

The stores have different jobs:

PostgreSQL holds MicroVM definitions, execution state, routing and lease information, request activity, and checkpoint metadata.

Spaces holds the large disk and memory artifacts. The activator resolves execution placement from a compact routing view without reading checkpoint payloads or running the placement scheduler for every request.

The controller coordinates creation, pause, resume, and placement. Temporal workers handle longer operations, such as template preparation and host-fleet management. On each host, microvm-d turns those decisions into Firecracker processes and local resources.

The activator bridges lifecycle management and HTTP traffic. DigitalOcean deploys its three roles separately: dataplane replicas scale with requests, lifecycle replicas handle host heartbeats and reconciliation, and the execution role runs beside the controller. We deploy them separately to independently manage each component&#x2019;s scale as a traffic spike and burst of host heartbeats need different capacity. Certain services are deployed more frequently and a controller rollout should not require restarting the HTTP dataplane which would impact in-flight HTTP requests such as WebSocket or SSE.

The database underneath the control plane

Our production cells use DigitalOcean Managed PostgreSQL Advanced Edition . It holds the execution state the platform uses to place, route, pause, and restore MicroVMs.

That workload combines frequent small state updates with transactions that must commit related changes together, for example:

Publishing a checkpoint records its completed state and artifact references in one transaction.

PostgreSQL stores those decisions.

Spaces stores the much larger disk and memory payloads.

Keeping these responsibilities separate prevents snapshot size from becoming database transaction size.

Each cell&#x2019;s control plane connects to its database over a private VPC endpoint. Controller and orchestrator application traffic uses a transaction-mode PgBouncer pool. Many application connections share a bounded set of database backends, so an idle client does not reserve a backend connection. Session-dependent operations, such as schema migrations, use a separate direct connection.

Advanced Edition also addresses database operations that would otherwise complicate the control plane. Its connection pooler routes reconnecting clients to the new primary after a failover, without waiting on DNS changes. These operations do not remove the need to handle interrupted transactions. Query and connection-pool observability provides visibility into slow queries and connection pressure as execution concurrency grows.

DigitalOcean uses a managed database for these responsibilities, rather than building database failover and capacity management into the MicroVM scheduler. The database...