Avrea Sandboxes: computers should be forkable

Creating a virtual machine is easy but getting it to do useful work is often the hard part.

You need to clone a git repository, install dependencies, configure your environment, and get everything needed running. If you want to experiment with a different approach, you might need to repeat much of that setup. And when you’re finished, you either keep paying for the machine or throw away the environment you’ve just prepared.

Developers have already been dealing with this for years, autonomous agents just make the problem more glaring.

An agent might need a computer for five minutes to run tests, several hours to work on a codebase, or days to complete a larger task. It needs a filesystem, processes, networking, and the freedom to install and run software. It also needs somewhere to do all of this without unrestricted access to your laptop or production infrastructure.

We think the right abstraction is surprisingly simple: a real computer that you can create, use, fork, and discard as easily as any other cloud resource.

That’s the idea behind Avrea Sandboxes.

A sandbox should be a real computer

A lot of sandbox infrastructure is designed around executing a command or running a short-lived task. That’s useful, but sometimes you need more than an execution API, you’d actually want an entire machine.

One where you can install arbitrary software, run development servers, maintain files across sessions, and use a normal operating system. One that works equally well when controlled by a human over RDP or SSH or by an autonomous agent.

Avrea Sandboxes are full virtual machines, with hardware virtualization providing the isolation boundary.

We’ve made a few deliberate choices about the underlying infrastructure.

First, we don’t oversubscribe CPUs. If you provision a machine with a certain number of vCPUs, you shouldn’t have to wonder how many other workloads are competing for the same physical resources. Predictable performance matters, especially for compilation, testing, and workloads that run without human supervision.

This isn’t a new idea. AWS Nitro is a good example of an architecture built around hardware-assisted virtualization and strong isolation. We think those properties should be the baseline for a cloud computer, not something users have to think about.

Second, we use the highest-performance hardware available: Apple M5 Max for Linux arm64, and highest base clock AMD Zen 5 EPYCs for Linux amd64 and Windows.

These are the same hardware platforms we’ve been optimizing for our CI infrastructure.

The performance is measurable. In RunsOn’s independent ARM runner benchmarks, Avrea’s M5 Max machines finished first among the tested configurations at 2, 4, and 8 vCPUs. On x86, Avrea also led the 4-vCPU combined build benchmark, completing the tested workloads in 6m58s compared with 18m18s on GitHub-hosted runners.

Different workloads will see different results, but the underlying point is that we’re not building sandboxes on a separate, lower-performance compute tier.

We’re taking the infrastructure we’ve already optimized for running demanding CI workloads and making it available as general-purpose computers.

Fast to boot is not the same as fast to work

There’s a tendency to measure how quickly a VM can start. That’s useful, but it’s only part of the story.

Imagine creating a fresh machine to work on a repository. The VM might boot quickly, but then you need to fetch Git objects, download dependencies, install tools, and build the project.

For a short-lived environment, those steps can take longer than the actual task. This is particularly relevant for agents. If an agent creates a new environment for every task, or several environments to explore different approaches, repeatedly downloading the same dependencies becomes a substantial waste of time.

We’ve already spent a lot of effort solving this problem for CI, and Avrea Sandboxes benefit from the same acceleration infrastructure.

For Git, we maintain datacenter-local mirrors to reduce the cost of fetching repositories. Sandboxes can initialize a repository during creation, so the code is already there when you connect, provided the preload succeeds.

For dependencies, we provide colocated package caches for npm, pnpm, pip, Cargo, Go, Maven, Gradle, and many other ecosystems. Repeated downloads can be served locally rather than fetched from upstream registries.

And for build outputs, repository-connected sandboxes can inherit the same configured caches used by CI workloads.

We’ve written about these mechanisms in more detail in our guide to GitHub Actions caching.

The impact can be substantial. In our Next.js benchmark, faster hardware reduced a cold build from 3m23s to 1m23s. With a warm Turborepo cache, the measured build step took just 1.4 seconds.

These figures compare specific CI build configurations and cache states; individual workload results vary. The same acceleration mechanisms are available to sandbox workloads.

Fast infrastructure isn’t just about fast CPUs. It’s about eliminating unnecessary work.

We care about time to useful work, not just time to boot.

Computers should be forkable

We branch source code all the time. We create a new branch to experiment, try an alternative implementation, or preserve something before making a risky change.

Why shouldn’t we be able to do something similar with an entire computer?

Suppose you’ve spent half an hour reproducing a difficult bug. You’ve installed the right dependencies, configured the environment, and finally reached the failing state. Now you want to try two different fixes.

Normally, you’d either modify the environment in place or recreate it somewhere else. Neither is particularly appealing.

With Avrea Sandboxes, you can pause and fork an eligible VM, creating an independent copy of its disk and machine configuration.

You can then experiment with the copy while leaving the original untouched. The same approach works for automated workflows. Prepare an environment once, then fork it for separate experiments or parallel tasks. A human can inspect one copy while an agent works on another.

Forking is to computers what branching is to source code.

There are differences, of course. A VM contains more than source files. It can contain credentials, installed software, configuration, and other sensitive state. Forking copies disk contents, not external side effects or running process memory. You still need to manage credentials and access appropriately.

Currently, forking requires a supported paused sandbox; Linux amd64 is the platform with pause/resume support. Avrea’s dedicated ephemeral agent-sandbox service has a different lifecycle and doesn’t currently support forking.

But the broader idea is interesting: a computer no longer has to be a unique environment that you carefully maintain or rebuild from scratch. It can be something you copy as part of normal work.

Computers don’t need to run forever

The traditional cloud VM model is oriented around servers. You provision a machine, configure it, and keep it running until you no longer need it.

But a development environment isn’t necessarily a server. You might need a computer for ten minutes to compile something, an hour to investigate a bug, or an afternoon to try a new framework.

Avrea Sandboxes are billed by the second, so you don’t need to commit to a long-running machine just to perform a short task. Networking is included in the price, without separate bandwidth metering.

And for supported Linux amd64 sandboxes, you can pause and resume the environment instead of starting from scratch. A normal pause preserves the disk; an optional memory-preserving pause can also retain running process state.

Sandboxes have configurable time limits and retention rules, so they aren’t intended to become permanent, forgotten servers.

Create a computer when you need it. Fork it when you want to experiment. Pause it when you want to come back. Delete it when you’re done.

Real networking, without the infrastructure work

A computer is much more useful when it can participate in the network normally.

You might want to run a development server, expose a webhook endpoint, test an API, or share a preview with someone. These are common requirements for developers, but they’re equally relevant to agents that need to interact with external services or host temporary applications.

Avrea Sandboxes support public HTTPS endpoints for services running inside the VM.

You can publish a port and receive an HTTPS URL with Avrea-managed TLS termination. The implementation supports HTTP/2, WebSockets, and streaming responses, with normal service limits.

No separate reverse proxy or certificate management is required. Published URLs are publicly reachable, so applications containing sensitive data should still implement authentication.

The goal isn’t to replace every networking primitive with a proprietary abstraction. It’s to make ordinary networking convenient enough that you don’t have to think about infrastructure for a temporary development environment.

A computer in a few commands

Here’s what a typical workflow looks like with the Avrea CLI.

avr vm create \
  --name dev \
  --os linux \
  --size 2-vcpu \
  --ssh-key @~/.ssh/id_ed25519.pub \
  --repo owner/repository \
  --ref main \
  --wait

Connect to it:

avr vm ssh dev

Or run a command directly:

avr vm ssh dev -- npm test

You can also publish an application port during creation using --https-port 3000, making a development server accessible over HTTPS.

On a supported Linux amd64 sandbox, you can preserve the environment and fork it:

avr vm pause dev --wait
avr vm fork dev --name experiment --wait
avr vm resume dev --wait

The commands are intentionally ordinary. Behind them is a complete virtual machine, predictable compute capacity, accelerated repository access, nearby caches, and a managed lifecycle.

The interesting part isn’t any individual command. It’s that you can create and manipulate whole computers without having to assemble an infrastructure stack around them.

The same computer, different operators

AI agents are an obvious use case for this kind of infrastructure.

An agent that can write code but has nowhere to execute it isn’t particularly useful. And giving autonomous software unrestricted access to a user’s machine is rarely a good default.

A separate VM gives the agent its own filesystem, processes, tools, and operating system, with a clear isolation boundary.

But we don’t think the underlying infrastructure should be designed exclusively for agents.

A developer debugging a failing test and an agent attempting to fix it need essentially the same computing resources. The developer might interact through SSH, a terminal, or a remote desktop. The agent might interact through an API or command execution interface.

The computer itself doesn’t need to care who’s operating it.

We’ve also introduced dedicated agent sandboxes for coding-agent sessions. These are intentionally ephemeral and have different lifecycle rules from user-created sandboxes, but they build on the same general idea: give autonomous software an isolated place to work.

Need a clean environment to reproduce a bug? Create one. Want to test a risky dependency upgrade? Fork one. Need an agent to investigate something without touching your local machine? Give it a separate environment. Finished with the task? Delete it.

A better abstraction for temporary computing

Cloud infrastructure has made compute programmable, but it hasn’t always made computers convenient.

Making that practical requires more than fast VM startup. It requires predictable hardware, efficient repository access, colocated caches, ordinary networking, and lifecycle operations that make environments easy to preserve or copy.

We’ve already built much of that infrastructure for the fastest CI service. Avrea Sandboxes just make it available for more general use.

For developers, they’re powerful temporary workspaces. For agents, they’re isolated execution environments. For both, they’re simply computers that can be created when needed and discarded when they’re no longer useful.

Computers should be easy to create. They should be ready for work. And they should be forkable.

Get started with Avrea Sandboxes.