gVisor: Isolation, Compatibility and Agent Hosting Costs

Do not index

gVisor is an application kernel that puts an extra boundary between a Linux workload and its host. It is a useful option for running agent-generated code, provided your dependencies work with its Linux interfaces. Agent37 offers standard gVisor sandboxes and full VMs, so you can choose the runtime your agent needs and compare the actual hosting bill.

That choice matters once an agent can install packages, execute shell commands, or process files supplied by someone else. A successful demo shows that the code runs. It does not establish what the code can reach, what happens after a restart, or whether an expensive dependency requires a different environment.

This guide explains the boundary, the compatibility checks, and the costs to measure before putting customer workloads into production. Product details were checked on November 11, 2026.

How gVisor changes the execution boundary

A conventional Linux container relies on the host kernel to service its system calls, with controls such as namespaces and system-call filters restricting access. gVisor adds a separate application kernel for the sandbox. Its OCI runtime, runsc, integrates with container tooling such as Docker and Kubernetes. See the project overview.

The central component is the Sentry. It handles the workload's Linux system-call interface in userspace. The host still supplies underlying resources, but the workload's system calls are not simply forwarded one-for-one to the host kernel. Some requests require services from a companion process called the Gofer. The architecture introduction describes these boundaries.

For an agent platform, the practical benefit is another barrier between code you did not write and the machine running other work. The operational consequence is that Linux compatibility depends on what the application kernel implements.

Do not confuse the architecture with a guarantee about the entire application. You still decide which files enter a workspace, which credentials it receives, and where its traffic can go.

Containers, gVisor and VMs answer different questions

These environments differ in the interface presented to the workload. Their names alone do not tell you which provider has the best price or whether a particular dependency runs.

Environment	Workload boundary
Native container	Host Linux kernel with isolation controls
gVisor sandbox	Separate application kernel
Virtual machine	Guest kernel and virtualization boundary

There is a nuance behind the VM comparison: gVisor itself supports different platforms for intercepting system calls. Systrap works without hardware virtualization, while its KVM platform uses virtualization support. Using KVM internally does not turn gVisor into a conventional VM containing a general-purpose guest Linux kernel. The platform guide explains the distinction.

Choose based on a requirement you can name. An agent editing Python files and calling external APIs may fit a compatible gVisor environment. A workflow that needs kernel features absent from that environment needs another runtime. An organization requiring a hardware virtualization boundary should evaluate products against that requirement explicitly.

Our microVM versus container guide covers that broader architecture decision. Here, the narrower question is whether gVisor runs your specific agent workload with the controls and operating cost you need.

Isolation still needs a credential and network policy

A sandbox can limit a host escape without stopping a harmful action that its permissions allow. Code with access to a writable repository can corrupt that repository. Code holding a production token can attempt the operations that token permits. gVisor's security model describes its focus on reducing exposure to exploitation; it does not make the contents of an authorized workspace untouchable.

For a hosted agent, keep the coordinator that owns broad account permissions outside the execution workspace. Give each job the smallest input set and credentials it needs. Use a disposable checkout for proposed edits, and validate output before promoting it into a trusted system. These are application design choices, independent of the runtime brand.

Apply the same discipline to outbound traffic. An allowlist should follow the task: model endpoint, package registry, and approved source repository, with unrelated destinations denied. Test denied destinations as well as allowed ones. A configuration file is weaker evidence than an observed connection failure.

On Agent37, public internet access is allowed by default. The network controls support deny-all or a list of allowed domains and IPv4 addresses. Managed models and tools also need network access: under deny-all they are unavailable; an allowlist must include api.agent37.com to retain them.

Keep service exposure separate from egress. That policy controls outbound connections; it does not close the instance's own URLs or replace authentication on a service you publish. For the surrounding controls, see our agent sandboxing guide.

Check the dependencies that make your agent useful

Start with the actual repository and dependency lockfile. An empty shell or a language-version check will miss failures in native extensions, file watchers, subprocesses, networking, and test tools.

The gVisor compatibility documentation reports regression testing for common language runtimes, including Python, Java, Node.js, PHP, and Go. It also documents incomplete Linux interfaces. Applications can sometimes use a supported fallback, so counting missing syscalls is not a reliable pass-or-fail test for a whole application.

Run dependency installation, a representative edit, the full relevant test command, and artifact retrieval. Record image and package versions with the result. Repeat after upgrading the base image or adding a dependency that touches the operating system.

Resource control deserves its own check. The current compatibility page distinguishes host cgroups limiting a whole sandbox from cgroups inside it: internal resource accounting exists, but resource limits between competing processes within that sandbox are not enforced. Do not assume an internal limit separates mutually untrusted jobs. Prefer separate execution environments when jobs need separate resource and trust boundaries.

Also distinguish upstream capability from a hosted service's configuration. Upstream documents Docker inside gVisor, with required flags and networking and storage limitations. That does not mean every hosted gVisor sandbox supports it. Agent37's standard runtime cannot run a Docker daemon; use its full VM offering for Docker and Compose workloads.

Measure a complete task before trusting a speed claim

gVisor introduces overhead through additional system-call handling and runtime state. Filesystem and networking behavior can matter more than a small CPU calculation. The performance guide explains why the effect varies by workload, and why pure computation does not carry the same overhead as frequent crossings of the execution boundary.

Its published benchmark methodology also includes older machines and, for many examples, the ptrace platform. Those results explain mechanisms; they are not a measurement of your current hosted sandbox. This article makes no throughput or startup benchmark claim.

Measure the user-visible path in separate stages: environment readiness, dependency setup, tool execution, artifact upload, and cleanup. For an agent waiting on a remote model, model latency can hide infrastructure differences. For a repository with thousands of small files, installation or test discovery may dominate instead.

Use the same input and dependency versions across candidates. Compare a cold workspace and a prepared workspace. Repeat enough times to notice failures and outliers, then divide the total infrastructure bill by successfully completed jobs. A cheaper minute is less useful if retries consume several of them.

Set your acceptance threshold before testing. For example, define the maximum completion time, required test results, and permitted destinations. This keeps a convenient demo from quietly becoming the production standard.

Price compute and retained storage separately

Architecture does not set the invoice. Agent37 provides standard gVisor instances with shared host resources, plus full VMs at a different compute rate. Model and tool usage sits outside the infrastructure figures below.

At the current published rates, standard compute is $0.80 per vCPU plus $0.70 per GB RAM per 730-hour month. Disk is $0.09 per GB over the same period. Full VM compute is 2.5 times the standard compute rate; disk pricing is unchanged. Usage is metered by the minute.

Consider one instance with 2 vCPU, 4 GB RAM, and 4 GB disk. Standard compute is $4.40 for 730 running hours. VM compute is $11.00. Keeping the disk for 730 hours adds $0.36 in either case.

Usage and retention	Standard	Full VM
60 hours, then delete	$0.39	$0.93
60 hours, disk kept 730 hours	$0.72	$1.26
730 hours, then delete	$4.76	$11.36

These rounded estimates assume the same resource shape throughout. The middle row includes stopped or sleeping time with the disk retained for the rest of the month. An awake instance still bills compute while its CPU is idle. Enable auto-sleep or stop it to pause compute billing; deletion stops the instance meter.

The full VM example explicitly selects 4 GB disk. The agent37-ubuntu template defaults to 12 GB disk when resources are omitted, making its 2 vCPU and 4 GB RAM configuration $12.08 for 730 running hours. Check the VM reference before using the smaller estimate in a budget.

These are infrastructure calculations, not equivalent-throughput benchmarks or complete application invoices. Include model calls, paid tools, external services, retries, and your own operating effort when comparing the total cost of a job.

Run a small deployment and recovery trial

Use one representative workload before expanding to a fleet. The instance documentation is the starting point for creating an Agent37 environment, selecting a template, and configuring its lifecycle.

First, write down the requirements: language and package versions, disk space, network destinations, credentials, and whether the job needs Docker or kernel-dependent tooling. Pick standard gVisor only when those requirements fit. Full VMs have their own Linux kernel and KVM access, but still check their documented constraints. Agent37 VM entrypoints do not run a systemd init system.

Next, run a complete task with non-sensitive inputs. Capture readiness time, command exit codes, test results, and saved artifacts. Exercise a deliberate timeout and confirm the coordinator records a failed job without treating partial output as success.

Finally, test recovery. Save durable work on persistent disk, stop and start the instance, and confirm the next job can continue from files. If using auto-sleep, test a wake and a cold start too. Agent37's VM memory restore can fall back to a cold boot; a live process is not your only durable record.

Keep the resulting evidence with the deployment configuration. A reproducible failure tells you what to change: dependencies, permissions, resource sizing, or runtime. When the task passes, create the sandbox configuration you tested and expand from that known result.

Frequently asked questions

Is gVisor a virtual machine?

It is an application kernel with a container runtime. One of its execution platforms uses KVM, but it does not provide the conventional guest Linux environment offered by a full VM.

Does using Docker mean a container uses gVisor?

No. Docker can integrate with runsc, but the runtime must be installed and selected. Follow the current installation instructions; current releases include companion binaries, so older instructions that copy only runsc can be incomplete.

Is gVisor enough to protect agent credentials?

No runtime can prevent code from using credentials it is intentionally given. Scope credentials, limit outbound access, separate trusted coordination from execution, and validate artifacts before accepting them.

When should I choose an Agent37 full VM?

Choose it when the workload requires supported capabilities absent from the standard runtime, such as a Docker daemon, or when your isolation requirements call for a VM. Budget the VM compute rate and selected disk size, then verify the complete workload.

gVisor: How to Choose Isolation for Hosted AI Agents