DigitalOcean MicroVMs: price the idle time before moving agent sessions

Disclosure: Tylor.nz has a DigitalOcean affiliate relationship. This guide uses direct documentation links, with no commission-bearing signup link. It is a documentation-based evaluation plan, not a hands-on benchmark. Availability and prices were checked October 10, 2026.

A coding session can spend a lot of its life waiting for someone to read the result. Paying for a machine throughout that wait is worth examining. But a service that stops compute billing while paused is not automatically the cheapest place to run your application.

DigitalOcean announced MicroVMs in public preview on October 9, 2026, following its October 1 private-preview announcement. Each runs a container in a separate virtual machine; the product combines isolated execution with saved state and pause/resume behavior. This is a new availability milestone, not a general-availability release. Launch announcement

My recommendation: evaluate it for disposable development sessions and agent sandboxes with genuine idle gaps. Keep an established production system where it is until the preview's constraints and your own measurements support a move.

First check the reasons you might reject it

The current preview is MKC1-only and accepts linux/amd64 images. Available CPU/memory pairs are 1/2 GiB, 2/4 GiB, 8/16 GiB and 16/32 GiB, with plan-dependent access. Paused instances still count against the team's MicroVM limit. Configuration is fixed at creation, including the image, environment, networking and idle timeout. There is no swap. DigitalOcean explicitly discourages production workloads during public preview. Limits and sizes

Remote exec also has a 60-second command limit, 32 concurrent commands and 60 commands per minute per team, plus 4 MiB combined output truncation. A long test suite needs an application-level job interface or another suitable execution path; do not assume a single remote command can run indefinitely. Command limits

Treat those as purchasing gates. An ARM-only toolchain needs work before migration. A hard residency requirement outside MKC1 rules out this version. A workload that needs frequent in-place resizing needs a different operating model. None of these trade-offs becomes irrelevant because a startup demonstration looks fast.

Separate execution cost from keeping the session

Published rates are $0.022 per vCPU-hour and $0.0085 per GiB-hour, charged per second while running. A 2-vCPU/4-GiB instance therefore costs $0.078 per running hour. Disk and checkpoint storage cost $0.05 per used GiB-month; retained checkpoints continue billing after the originating instance is destroyed. Public outbound traffic is $0.01/GiB without a free allowance. VPC internet access requires a separately billed NAT gateway. Current pricing

Here is an illustrative budget, not an observed workload:

100 sessions, each running 15 minutes	Estimated USD
25 aggregate running hours at $0.078/hour	$1.95
20 GiB of aggregate disk and checkpoint storage for a full month	$1.00
10 GiB of public outbound transfer	$0.10
Subtotal before model calls, registries, NAT or other services	$3.05

If those same sessions each run for an hour, compute becomes $7.80. A five-minute idle tail adds $0.0065 per session at this size. Measure actual running time, including these delays. Do not treat user interaction time as billed running time or multiply an instance's maximum disk capacity into storage usage.

The practical question is how much of your existing bill is avoidable. Compare this estimate with the capacity you actually pay for today, including spare headroom, operations and migration work. A cheap session can still be an expensive product if it triggers large model bills or requires a new control plane.

Design the pause experiment around your workload

The default idle timeout is five minutes, with a four-hour maximum; auto-pause cannot be disabled. Pausing preserves memory, files and processes. With auto-resume enabled, an endpoint request, command or console can resume the machine. Paused instances do not expire automatically. Lifecycle behavior

Test three situations separately:

1. A short editing session followed by a long idle gap.
2. A continuously busy session that offers little chance to pause.
3. A session with background work after the last interactive request.

For each, record application completion, time to a usable response, actual state transitions and running time. Especially for the third case, establish whether the documented traffic-driven lifecycle suits the work. Avoid converting a vendor's startup claim into your own latency guarantee.

Also test your largest ordinary workload. Choose memory from peak usage rather than average usage, then deliberately test how your application reports a failed operation. The outcome should tell a user whether to retry; it should not silently lose work.

Keep the endpoint credential out of the client

MicroVM endpoints require a DigitalOcean token with microvm:access. That scope reaches every MicroVM in the team; it cannot be restricted to one instance. The endpoint exposes the selected HTTP port. Cloud Firewalls are unsupported. VPC networking controls outbound connectivity, and an attached VPC needs NAT for internet access. Networking and access

For a multi-user product, put your own authenticated backend between the user's browser and these endpoints. Authorize the user's access to the specific session there. Do not hand a team-wide token to a customer and assume the VM boundary also enforces your application's tenant permissions.

This is an architecture recommendation, not a claim that DigitalOcean supplies that application authorization layer for you. Review where secrets, uploaded code and logs can travel before testing representative customer data.

A small, documented evaluation path

The official quickstart requires doctl 1.173.0 or later and appropriate API-token scopes. It uses a separate endpoint-only token for HTTP requests. Begin with the documented sample before moving your own image; its purpose is to isolate platform setup errors from application errors. Quickstart and prerequisites

Before provisioning anything, approve a test budget and use synthetic data. In a sandbox team:

1. Inspect the options available to that team, including limits and sizes.
2. Create one sample instance with the documented region and HTTP port.
3. Wait for the running state and confirm an authenticated request succeeds.
4. Observe an idle pause and the subsequent resume, recording timings yourself.
5. Repeat with your own container, a realistic request and a controlled failure.
6. Export anything you need, then remove disposable resources and separately review retained checkpoints.

For your own image, the creation guide documents public images and private images in DigitalOcean Container Registry. It also documents specifying the listening port and selecting public or VPC networking. Match those settings before creation rather than planning to fix them in place. Creation workflow

Checkpoint carefully before calling it reusable

A checkpoint captures memory and disk. Clones inherit the original region, size, image and environment variables. Networking, auto-resume, idle timeout and tags instead require explicit choices or receive defaults; networking defaults to public. Checkpoint behavior

Build a clean reusable base before injecting customer-specific data or credentials. Keep a record of what a checkpoint contains and who can launch it. Include a test that a cloned session cannot see another customer's files. Fast cloning is useful only if the starting state is appropriate to share.

Compare alternatives against the job to be done

An ordinary Droplet is a sensible comparison when a service is always busy or you need conventional server control. Use its current plan and transfer costs, rather than assuming equivalent CPU counts mean equivalent performance. Droplet pricing

For an existing Kubernetes or hosted-sandbox deployment, compare against the real incremental cost of adding sessions there. Do not count infrastructure you already need as fully avoidable savings. If the missing piece is agent orchestration rather than isolated compute, evaluate DigitalOcean Managed Agents separately: the launch distinguishes its higher-level runtime from MicroVM lifecycle primitives. Product boundary

Make the decision after a budgeted test shows correct tenant boundaries, acceptable recovery, useful end-to-end latency and an all-in cost advantage. Until then, MicroVMs are a promising preview to evaluate, not a reason to migrate a working production service overnight.