DigitalOcean Details MicroVM Design Behind Managed Agents

Why agents need a different foundation

DigitalOcean describes a typical agent workload: the agent starts a test suite, edits a file, calls a model and waits. Later it resumes with the same processes, files and context. Sometimes it must fork the environment to try two approaches at once.

Conventional infrastructure forces a tradeoff, the company says. A machine that keeps running leaves idle sessions occupying resources. A machine that is destroyed must rebuild its environment on the next interaction. Saving the filesystem helps, but it does not preserve a running interpreter, an in-memory index or a process halfway through a task.

For that reason, Harness Runtime gives each session a Firecracker microVM. The MicroVM platform underneath manages isolation, networking, storage and checkpoint restore, while Action Gateway adds governed access to tools. Firecracker uses KVM hardware virtualization, so each guest has its own kernel instead of sharing the host kernel as a container does. Network namespaces complement that VM boundary rather than replace it.

The central design decision is to separate a session from its host. A guest keeps a stable network configuration, and immutable storage holds its checkpointed disk and memory. Host-side proxies apply network policy and can attach credentials without putting them in the guest environment.

Cells, control plane and host plane

The platform is organized into cells. A cell is a self-contained, region-scoped instance of the MicroVM platform with its own VPC, DigitalOcean Kubernetes cluster, managed PostgreSQL database, Spaces bucket and pool of hypervisor hosts. A region can run many cells side by side, and capacity grows by adding hosts to a cell or adding another cell.

DigitalOcean says a cell-local database or routing failure does not require other cells to share that failure. It also states that cells still depend on shared regional and platform services, so a cell limits the blast radius but does not eliminate shared dependencies.

Each cell has two parts:

• The control plane, which owns lifecycle decisions, placement and durable metadata, and runs on Kubernetes.
• The host plane, which runs Firecracker and the services for guest networking, disks and memory, on hypervisor Droplets.

PostgreSQL holds MicroVM definitions, execution state, routing and lease information, request activity and checkpoint metadata. Spaces holds the large disk and memory artifacts, which keeps snapshot size from becoming database transaction size. The activator resolves placement from a compact routing view, the controller coordinates creation, pause, resume and placement, and 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 company deploys the activator's three roles separately: dataplane replicas scale with requests, lifecycle replicas handle host heartbeats and reconciliation, and the execution role runs beside the controller. One reason is that a controller rollout should not restart the HTTP dataplane and disrupt in-flight requests such as WebSocket or SSE.

Production cells use DigitalOcean Managed PostgreSQL Advanced Edition. Application traffic goes through a transaction-mode PgBouncer pool, while schema migrations use a separate direct connection. The company says the connection pooler routes reconnecting clients to the new primary after a failover without waiting on DNS changes, though applications must still handle interrupted transactions.

How requests reach a guest

Inbound traffic must find a particular execution, possibly waking it first, while outbound traffic must respect that execution's network policy. For HTTP ingress, DigitalOcean Edge provides the routing layer. The MicroVM controller publishes routes that configure authentication and ownership checks and set internal headers carrying the execution identity and destination port, replacing any values sent by the client. A client therefore cannot steer a request to another execution by forging those headers.

The activator then picks one of two paths. On the hot path, the execution is running, its readiness flag is set and its lease is valid, so the request is forwarded to the host without a new placement decision. On the wake path, the activator asks the controller to create or resume the execution when policy permits, and the request waits for routing state to become eligible, subject to a deadline. DigitalOcean cautions that a control-plane readiness flag is not by itself proof that every application endpoint is healthy.

Host heartbeats keep the routing view current and leases limit how long it stays valid, so when a host stops reporting, its addresses stop being eligible rather than lingering as stale routes. The final hop is local: microvm-proxyd runs Envoy, microvm-d supplies its configuration over a Unix socket, and the activator connects to host Envoy over mutual TLS. Envoy strips internal routing headers and forwards HTTP to the guest. The company stresses this is not one unbroken TLS connection from client to application, since each hop has its own role and trust boundary.

The post also explains that every guest has the same IP address. A checkpoint preserves the guest kernel's view of the network, including interface configuration and cached neighbor entries, so giving a restored guest a new address would mean changing preserved state. Forking would make this harder, because every fork starts from the same configuration. The source text provided ends at this point.

What it means for users

For teams building agents, the post sets out how DigitalOcean intends to let sessions pause and resume with running state intact instead of forcing a choice between idle cost and rebuild time. Managed Agents are in public preview, and the architecture description is the company's own account of its design rather than independent testing.