# MicroVM vs Docker for AI Agent Hosting

> Containers share the host kernel; Firecracker microVMs don't. Why sub-$5 agent hosting can't include a kernel boundary, and when that trade matters.

- Published: 2026-07-17 · Updated: 2026-07-17 · jurniti
- Canonical: https://www.jurniti.com/blog/microvm-vs-docker-agent-hosting

An AI agent is a process that executes code nobody reviewed, steered by input you don't fully control, with your API keys sitting in its environment. Where you run that process is a security decision wearing a hosting decision's clothes. This post walks the isolation ladder from shared container to Firecracker microVM, then does the arithmetic on why Docker-density pricing and a kernel boundary can't coexist on the same invoice. No vendor scare stories — just what each boundary is made of and what it costs.

## The isolation ladder

From weakest to strongest, the realistic options for running an agent:

1. **A bare process** on a box you also use for other things. The agent has whatever your user has. This is how most people run agents on laptops, and it's how a runaway `rm -rf` or a prompt injection gets your SSH keys.
2. **A container.** Namespaces and cgroups, drawn and enforced by the host kernel — which every container on the machine shares. The boundary is the kernel's syscall surface: enormous, written in C, and common to all tenants.
3. **A hardened container** — seccomp profiles, user namespaces, or a user-space kernel like gVisor intercepting syscalls. Meaningfully better, still ultimately mediated by software sharing the host.
4. **A microVM.** Each workload gets its own guest kernel behind KVM hardware virtualization, run by a deliberately minimal VMM. Firecracker — built by AWS to run Lambda — boots one in about 124ms. An escape here means defeating the hardware virtualization layer, not finding one kernel bug.
5. **Dedicated hardware.** The strongest boundary and the least practical below serious budgets.

Rungs 2 and 4 are where the agent-hosting market actually lives, and the gap between them is the entire subject of this post.

## Why the kernel boundary matters for agents specifically

Three properties, individually manageable, combine badly:

**Agents run arbitrary code.** Not "arbitrary" as hyperbole — the model writes shell commands and programs, and the point of an autonomous agent is executing them without a human reviewing each one.

**Agents read untrusted input.** Web pages, emails, documents, messages. Prompt injection means that input can steer what the agent does next — researchers demonstrated in January 2026 that hidden text in a `.docx` could trick a coding agent into exfiltrating files. The workload isn't just untrusted code; it's code an attacker can influence remotely, through content.

**Agents hold credentials.** Model API keys at minimum; often messaging tokens, repo access, or payment rails. Long-lived, valuable, and sitting in the environment of the process described above.

On a shared kernel, the boundary between that process and every other tenant is the container stack — over 200 known weaknesses, and one exploitable bug or misconfiguration away from the neighbor's workload. The honest version of this claim is not "containers get escaped daily." It's that the boundary is software the size of Linux, and the workload on the other side of it is the most adversarial one in mainstream computing right now. A microVM changes the boundary's *class*: your agent gets its own kernel, and the host's exposed surface shrinks to a minimal VMM plus the hardware virtualization interface.

Two second-order effects ride along. **Noisy neighbors:** aggressive container packing shares the scheduler, page cache, and IO with everyone on the host, so your always-on agent competes for everything; a microVM with dedicated CPU and RAM doesn't. **Key custody:** platforms at the cheap end often bundle model credits or route your traffic through their proxy, which puts a middleman on your keys. That one's a business-model choice rather than a physics constraint, but it correlates hard with the same economics — which brings us to the arithmetic.

## The arithmetic of sub-$5 agent hosting

No FUD required here; division suffices.

A container platform can oversubscribe aggressively. An idle container costs the host almost nothing — shared kernel, shared page cache, memory reclaimed to near zero — so hundreds of tenants fit on one machine, and a $3–5/mo sticker price divides out fine.

A microVM cannot be packed that way. Each tenant carries its own guest kernel and reserved memory. When we priced jurniti, our planning math put microVM density at roughly **5× lower** than container packing on the same hardware. Same box, 5× fewer tenants, so the per-tenant floor cost is roughly 5× higher before anyone takes margin.

That's the whole argument: **Docker-density pricing and a kernel boundary are mutually exclusive on the same P&L.** A sub-$5 agent plan isn't evidence of a clever platform; it's evidence of a shared kernel, because that's the only way the division works. We priced our Starter at $25/mo because that's what one-tenant-per-kernel costs with a sustainable margin — the price *is* the isolation disclosure, on both ends of the market.

Questions that cut through any hosting page in about a minute:

- Does my agent get its own kernel, or a share of yours?
- Who holds my model API keys, and does my model traffic proxy through you?
- What CPU and RAM are reserved for me versus best-effort?
- What happens to my disk across a restart?

## When a shared container is fine

The ladder is about matching the boundary to the trust profile, not about maximal isolation everywhere. A container is a perfectly good home for: code you wrote and reviewed, jobs with no long-lived secrets in the environment, ephemeral batch work, and internal tooling on infrastructure where you're the only tenant anyway. If your "agent" is a cron job calling an API with a scoped key you rotate, a container is the right rung and paying for a microVM is waste.

The low-trust end — an autonomous agent with your keys, reading the open internet, running whatever it writes — is where the kernel boundary earns its cost.

## Shared container vs Firecracker microVM, side by side

| | Shared container (Docker-density platform) | Firecracker microVM (jurniti) |
|---|---|---|
| Kernel | Shared with every tenant on the host | Your own, behind a KVM boundary |
| Escape requires | One kernel bug or misconfiguration | Defeating hardware virtualization |
| Neighbors | Share scheduler, cache, IO | Dedicated CPU / RAM per VM |
| Model keys | Often bundled credits or proxied | BYOK inside your VM, never proxied |
| Density economics | Hundreds per host → $3–5/mo possible | ~5× lower density → $25/mo floor |
| Boot | Fast | ~124ms — density, not speed, is the cost |

## What jurniti does with this

Every plan is one Firecracker microVM per tenant: your own kernel, dedicated CPU and RAM, a persistent home that survives restarts, and BYOK by architecture — your model key lives inside your VM and traffic goes straight to your provider, unproxied and unmarked-up. Flat [$25 / $49 / $99 per month](/pricing) (annual is two months free), provisioned automatically about 3 minutes after payment, with a 30-day money-back guarantee on your first purchase. Snapshot a configured agent into a [template](/templates) and fork it when you need a second one.

See it applied to a specific agent: [Claude Code hosting](/blog/claude-code-hosting), [self-hosted vs managed Claude Code](/blog/self-hosted-vs-managed-claude-code), or [Hermes Agent hosting](/blog/hermes-agent-hosting).

## Frequently asked questions

### What is the difference between a Docker container and a microVM?

A container is process isolation: namespaces and cgroups drawn by the host kernel, which every container on the machine shares. A microVM is hardware virtualization: each workload gets its own guest kernel behind a KVM boundary, managed by a deliberately small virtual machine monitor like Firecracker. A container escape requires one kernel bug or misconfiguration; a microVM escape requires defeating the hardware virtualization layer — a different class of boundary.

### Why does isolation matter more for AI agents than for web apps?

An AI agent executes code no human reviewed, processes untrusted input that can steer it (prompt injection), and holds long-lived credentials — model API keys, messaging tokens, sometimes payment access. That combination means the workload itself can be turned hostile by its input. A web app you wrote is trusted code; an agent is, by construction, not.

### Can an AI agent actually escape a Docker container?

Escapes aren't trivial, but the boundary is software the size of the Linux kernel — there are over 200 known weaknesses in the container stack, and one exploitable bug or misconfiguration exposes every tenant on the host. The honest framing isn't 'containers get escaped daily'; it's that a shared kernel is the wrong default boundary for a process that runs attacker-influenceable code next to your credentials.

### Why is microVM hosting more expensive than container hosting?

Density. Idle containers cost a host almost nothing, so a container platform can pack very aggressively and hit a $3–5/mo sticker price. A microVM needs its own kernel and reserved memory per tenant — roughly 5× lower density on the same hardware. Divide one real server's cost by 5× fewer tenants and the floor price is structurally higher. A sub-$5 plan is only reachable by sharing the kernel.

### Are microVMs slow?

No. Firecracker boots a microVM in about 124ms with tiny overhead, and it's the same isolation primitive AWS runs under Lambda at enormous scale. The cost of a microVM is density (fewer tenants per host), not speed.

### When is a container good enough for an agent?

When the trust profile allows it: code you wrote and reviewed, no long-lived secrets in the environment, ephemeral batch jobs, or infrastructure where you're the only tenant anyway. The point of the isolation ladder is matching the boundary to the trust level — an agent holding your API keys and reading untrusted input sits at the low-trust end, which is where the kernel boundary earns its cost.