Fast Open-Source Infrastructure for AI Agents to Access the Internet

kernel · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Browser infrastructure for AI agents

Kernel needed browser infrastructure that lets AI agents access the internet at high concurrency and long lifecycle durations, but ordinary Dockerized Chromium, warm pools, and human-speed web infrastructure were too slow, costly, and stateful to scale.

Constraints:

Agents use tools designed for human-speed interactions but now generate far more concurrent internet activity.
Chromium in Docker can take 10 to 40 seconds to boot.
Thousands of parallel browser sessions make boot delay and warm-pool cost painful.
Agent browser workflows can remain alive for minutes, hours, or days.
Browsers are stateful and need lifecycle management, health checks, wake-up, and sometimes GPU passthrough.
Kernel wanted open-source infrastructure with simple API access.

Architecture

Kernel iterated from Chromium-in-Docker to Unikraft unikernels with standby/resume and then to QEMU/GPU-backed VMs managed by a control plane called Hypeman. Temporal orchestrates browser lifecycles: cold pools, health checks, state persistence, delayed wake-up, and browser sessions that can run for minutes, hours, or days. The result is sub-30ms wake-up for prepared browsers, 6x faster cold starts than Docker, and nearly 4x faster end-to-end runtime than competitors.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  agent-browser-api["Agent browser API"] --> browser-lifecycle-orchestrator["Browser lifecycle orchestrator"]
  docker-browser-implementation["Docker browser implementation"] --> browser-lifecycle-orchestrator
  browser-lifecycle-orchestrator --> unikraft-unikernel-browser["Unikraft unikernel browser"]
  unikraft-unikernel-browser --> disk-snapshot-store["Disk snapshot store"]
  disk-snapshot-store --> browser-lifecycle-orchestrator
  browser-lifecycle-orchestrator --> hypeman-control-plane["Hypeman control plane"]
  hypeman-control-plane --> qemu-gpu-browser["QEMU GPU browser"]
  browser-lifecycle-orchestrator --> health-check-workers["Health-check workers"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Agent browser API`	Gives AI agents a simple API for browser access and anti-detection infrastructure.	`Browser lifecycle orchestrator`
`Docker browser implementation`	Initial Chromium-in-Docker implementation used as the baseline.	`Browser lifecycle orchestrator`
`Unikraft unikernel browser`	Uses Firecracker-like standby and resume to decouple browser boot from customer request time.	`Browser lifecycle orchestrator`, `Disk snapshot store`
`Disk snapshot store`	Stores prebooted browser VM state for later fast wake-up.	`Unikraft unikernel browser`, `Browser lifecycle orchestrator`
`Hypeman control plane`	Manages Cloud Hypervisor, QEMU, and Firecracker VM implementations.	`QEMU GPU browser`, `Browser lifecycle orchestrator`
`QEMU GPU browser`	Runs GPU-accelerated cloud browsers through QEMU VM passthrough.	`Hypeman control plane`
`Browser lifecycle orchestrator`	Uses Temporal to coordinate cold pools, health checks, state, and wake-up over long-lived sessions.	`Agent browser API`, `Unikraft unikernel browser`, `Hypeman control plane`, `Health-check workers`
`Health-check workers`	Verify that browser instances remain in a good state before or after wake-up.	`Browser lifecycle orchestrator`

Data flow

A customer requests a browser through Kernel's API. Kernel may preboot a browser in a VM, write it to disk, wake it with standby/resume when requested, attach CPU or GPU-backed browser execution, and use Temporal to manage health checks, state, long-running lifecycle, and wake-up days later.

“when a customer requests our browser, we'll wake that browser back up um from the VM and serve it under 30 milliseconds.”transcript, stated

“Temporal is critical to us doing all of that and we manage everything from that cold pool”transcript, stated

Why this architecture

Kernel chose snapshot/resume, VM orchestration, and Temporal because browser sessions are both latency-sensitive and stateful. Docker is simple but too slow at scale, warm pools become costly, Firecracker-like unikernels deliver fast wake-up, and QEMU/GPU passthrough handles browser workloads needing local-machine-like graphics behavior.

“if you want to do thousands at scale in parallel, um that boot up time is going to be pretty annoying to deal with.”transcript, stated

“the life cycle of browsers are incredibly stateful and then increasingly can run indefinitely.”transcript, stated

Models used: Temporal · Docker · Chromium · Unikraft unikernels · Firecracker · QEMU VMs · Cloud Hypervisor · GPU passthrough · Hypeman control plane

Scale

Chromium in Docker boot time ranged from 10 to 40 seconds.
“it takes several seconds to to boot up. That can range from anywhere from 10 to 40 seconds.”transcript, stated
Prepared browser VMs can be served under 30 milliseconds.
“serve it under 30 milliseconds.”transcript, stated
Agent browser workflows can run for minutes, hours, or days.
“The browser might be alive for on the order of minutes, hours, or even days”transcript, stated
Kernel reports 6x faster cold starts than Chrome-in-Docker.
“deliver uh 6x faster cold starts than the initial naive implementation of of uh Chrome and Docker containers.”transcript, stated
Kernel benchmarked nearly four times faster end-to-end runtime than competitors.
“benchmark at nearly four times faster end-to-end at run time than some of our nearest competitors”transcript, stated

Alternatives considered (roads not taken)

Chromium in Docker containers.

Rejected because: Docker was obvious and open-source, but Chromium startup latency becomes painful for thousands of parallel agent sessions.

“the most obvious approach, which is you put Docker in a uh sorry, Chromium in a Docker container.”transcript, stated

Warm pools of Docker browsers.

Rejected because: Warm pools add operational complexity and become cost-ineffective at scale, especially for long-running sessions.

“you're very quickly managing a lot of complexity. Um and the other problem with that is that at scale, um that becomes incredibly cost-ineffective.”transcript, stated

Only Unikraft/Firecracker-style VMs.

Rejected because: They cannot support GPU passthrough, live migration, and some stateful browser requirements.

“that's not possible with uh Unikraft unikernels. Um Firecracker VMs were simply not designed to kind of have device passthrough”transcript, stated

Patterns

`durable-execution` (browser lifecycle management)

Temporal orchestrates stateful browser lifecycles, cold pools, health checks, wake-up, and long-running sessions.

“Temporal has made it super easy for us to do all of that, um, even across the different implementations that we've had.”transcript, stated

`latency-optimization` (browser provisioning)

Kernel decouples browser boot from request time and wakes prebooted VM state in under 30ms.

“decouple that from the the runtime in which a user requests the browser.”transcript, stated

`tool-use-orchestration` (internet access for agents)

The platform exposes browsers as infrastructure tools AI agents can use through an API.

“just solving the infrastructure problems for AI agents to access the internet”transcript, stated

`cost-aware-routing` (warm-pool avoidance)

Kernel avoids warm-pool-heavy designs because they become cost-ineffective at high parallel scale.

“at scale, um that becomes incredibly cost-ineffective.”transcript, stated

Tradeoffs

How to reduce browser startup latency.

Chose Unikraft/Firecracker-style standby and resume over Docker-only browser startup.

Rationale: Snapshotting pays the full boot time ahead of request time and enables sub-30ms wake-up.

“with standby and resume, we're able to spin up the browser, um eat the full kind of the eat the full time that it takes to load that browser”transcript, stated

How to support browser graphics and local-machine-like experience.

Chose QEMU VMs with GPU passthrough over Unikraft-only deployment.

Rationale: GPU passthrough provides a better browser experience and supports workloads Unikraft could not.

“If we can uh enable GPU passthrough, we can give uh we can give the browser in the cloud a really great experience”transcript, stated

Gotchas (what bit them)

Browser boot times that are fine for CI become bad for agent-scale parallelism.

Root cause: Chromium can take 10-40 seconds to boot, and thousands of parallel agent sessions amplify that delay.

Resolution: Use standby/resume VM snapshots so boot time is paid before customer request time.

“In the context of like a one-off CI CI/CD run, that's not a big deal, but if you want to do thousands at scale in parallel”transcript, stated

Warm pools do not solve long-lived browser sessions cleanly.

Root cause: Agent browser workflows can be alive for minutes, hours, or days, making pool management complex.

Resolution: Temporal-managed browser lifecycles track state, health, and wake-up over long durations.

“that problem becomes pretty intractable if the way that you're solving that is through warm pools.”transcript, stated

Firecracker-style VMs are a poor fit for GPU browser passthrough.

Root cause: Firecracker was designed for stateless applications and not device passthrough or memory hot swapping.

Resolution: Add QEMU VM support through Hypeman for GPU-accelerated browsers.

“Firecracker was made designed for stateless applications, whereas our browsers are fully stateful”transcript, stated

Evaluation

Kernel evaluates the infrastructure through cold-start speed, end-to-end runtime benchmarks, GPU browser stress testing, frame-rate comparisons, and lifecycle reliability under Temporal.

Metrics: Sub-30ms browser wake-up · 6x faster cold starts · Nearly 4x faster end-to-end runtime · 10 FPS CPU-only baseline versus smoother GPU passthrough · Health checks and wake-up days later

“right-hand side you can see our CPU only browsers at 10 frames per second. Left-hand side when we did the GPU pass-through”transcript, stated

“doing health checks on our browsers, making sure that they're still in a good state.”transcript, stated

Outcomes

Kernel moved from Docker browsers to Unikraft snapshot/resume and QEMU/GPU browser infrastructure.
Prepared browsers can be served under 30ms.
Kernel reports 6x faster cold starts than its initial Docker implementation.
Kernel reports nearly 4x faster end-to-end runtime than competitors.
Temporal now coordinates long-lived browser lifecycle management.

The system is designed for thousands of parallel browser sessions and browser lifetimes from minutes to days.

“All of that is open source today, so if you're interested you can check it out.”transcript, stated

“we've already iterated a few times despite this being a fairly new company.”transcript, stated