Google Agent Runtime vs Azure Container Apps Sandboxes
Google Agent Runtime hosts the agent code you build with ADK or LangGraph and runs its tools in locked containers where commands have no root or Docker. Azure Container Apps Sandboxes gives each agent a microVM with its own kernel and root, which can suspend with its memory and wake on traffic.
The companies and products
Google Agent Runtime
Google Agent Runtime is the agent hosting part of Gemini Enterprise Agent Platform on Google Cloud, renamed from Vertex AI Agent Engine in April 2026.
It is a hyperscaler service, not a sandbox company. Agent Runtime deploys agents you build with ADK, LangGraph, LangChain, AG2 or LlamaIndex and bills them only while they work on a turn. Next to it, Agent Sandbox gives those agents a place to run code: a Code Execution sandbox, a shell or custom container sandbox, and a Computer Use browser. All of them run as secure containers inside your Google Cloud project.
Azure Container Apps Sandboxes
Azure Container Apps Sandboxes is a service inside Microsoft Azure that gives each agent or user an isolated microVM you create, suspend and resume through an SDK.
It is part of Azure Container Apps, the hyperscaler's serverless container platform, and lives in your Azure subscription as a sandbox group resource. Each sandbox boots from an OCI image or a snapshot, has its own kernel, and can be suspended with its memory and resumed in under a second. It is built for teams already on Azure that want stateful code execution with Azure networking, identity and billing.
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “28th cheapest of 366” means 27 of the other 365 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Google Agent Runtime: price rank | Azure Container Apps Sandboxes: price rank | boat: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Google's sandboxes have no root or Docker and Azure's have no documented nested virtualization or SSH, so both are a compromise here; boat gives each agent root, Docker, /dev/kvm and SSH on a full VM. | 295th of 367, with limits $5,801 a month | 288th of 367, with limits $5,276 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Google ranks 28th and fits this one fully, while Azure ranks 302nd; boat ranks 5th and also gives the assistant a desktop, a browser and SSH. | 28th cheapest of 366 $7,519 a month | 302nd of 366, with limits $6,544 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Azure is the better fit of the two for short code runs: its sandboxes suspend with their memory and resume in under a second, and Azure ranks 34th against Google's 254th. | 254th of 345, with limits $275 a month | 34th cheapest of 345 $354 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Azure ranks 22nd here, far ahead of Google at 280th, since it can publish HTTPS ports for each user sandbox; boat ranks 1st with HTTPS on up to 50 ports per sandbox. | 280th of 361, with limits $1,916 a month | 22nd cheapest of 361 $2,260 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 128th of 360, with limits $8,240 a month | 153rd of 360, with limits $10,740 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 79th cheapest of 364 $2,060 a month | 75th cheapest of 364 $1,728 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month The two sit close together for CI; jobs that build containers need Docker, which Google's sandboxes do not offer and Azure offers only in images like azure-dev. | 98th cheapest of 377 $989 a month | 103rd cheapest of 377 $1,046 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Neither gives you SSH: Google runs each command in a new shell through its API and Azure gives a shell through its own CLI and portal; boat gives you SSH and a desktop. | 311th of 368, with limits $241 a month | 322nd of 368, with limits $262 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Google gives a browser with a VNC view and a click and type API, and Azure's sandboxes are headless; boat streams a full Linux desktop at 60fps. | 283rd of 369, with limits $1,648 a month | 279th of 369, with limits $1,573 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month Google ships a Chromium you can drive over CDP with Playwright, while on Azure you install a headless browser yourself; boat ships Chromium on a desktop in every sandbox. | 102nd of 367, with limits $824 a month | 288th of 367, with limits $795 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 53rd cheapest of 346 $515 a month | 284th of 346, with limits $561 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 210th of 338, with limits $8,240 a month | 239th of 338, with limits $10,956 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 260th of 360, with limits $412 a month | 278th of 360, with limits $517 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month | Can't run it | Can't run it | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Google Agent Runtime | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| Isolation | Secure container sandboxing inside your Google Cloud project | MicroVM per sandbox with its own kernel | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Root, Docker and /dev/kvm | Runs as appuser with no sudo; images must not need root; no Docker or /dev/kvm documented | Root; Docker depends on the image (azure-dev ships it, the default ubuntu image has only Buildah); nested virtualization not documented | Root, systemd, Docker and /dev/kvm on every machine |
| Getting a shell | execute_bash() API calls; each command runs in a new shell; no SSH | Interactive shell through the aca CLI, SDK or portal; no SSH | SSH, plus CLI and API exec |
| Desktop, browser and computer use | A browser in a container with a VNC live view, a click, type and screenshot API, and CDP | Headless; no desktop or managed browser | Linux desktop streamed at 60fps, Chromium and computer-use tools preinstalled |
| Inbound access | Through Google's API or a private endpoint in your VPC; no public URL documented | Public HTTPS routes per published port; private endpoint from your VNet; no public IP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6 |
| Memory snapshots and forks | Snapshots keep memory and files; start many sandboxes from one snapshot | Suspend with memory and resume in under a second; snapshot a running sandbox to seed new ones | Fork a running sandbox with its disk; resume reboots from disk |
| Idle handling | Sandboxes are billed while they exist; pause keeps files at a lower, unpublished rate | Auto-suspend after an idle timeout (5 minutes by default); traffic or a start command wakes it | Auto-stop timer you set; disk saved every minute and on stop; a stopped sandbox costs nothing |
| How long a sandbox lives | TTL of up to 7 days for a custom container and 14 days for Code Execution | No maximum runtime documented | No session cap on paid plans |
| Outbound internet | Off unless the template turns it on; route through your VPC with Cloud NAT, a static IP, Cloud NGFW or Secure Web Proxy | Egress policy with allow, deny, rewrite and header rules by host, path and method; VNet integration | Open internet on every plan; no provider-side allowlist |
| Coding agents | Managed Agents API (Preview) runs Google's Antigravity harness | Copilot CLI and Claude Code images, run through the exec API | Seven agents preinstalled, including Claude Code and Codex, with a prompt, steer and events API |
| Keeping AI keys out of the sandbox | You provision and scope the credentials the agent uses | Group secrets usable in egress header rules; Copilot and Anthropic tokens injected into the sandbox at startup | Credentials proxy for model providers and any HTTPS API you register; switch to another account when credits run out |
| Hosting your agent code | Agent Runtime deploys ADK, LangGraph, LangChain, AG2 and LlamaIndex agents; idle time between turns is not billed | No agent hosting service; you run your code inside sandboxes | You run your own agent loop inside a sandbox |
| Scaling up a fleet | Runtime scales from 1 to 1,000 instances; sandboxes need project quota | 500 concurrent active cores by default; more by Azure support request | Concurrency set by plan, up to 2,000 sandboxes, self-serve |
| Regions | 23 locations in the US, Europe, Asia, Canada, Australia and Brazil | 40 Azure regions, 9 of them in the EU | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Google Agent Runtime | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | No | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | No | Yes | Yes |
| Systemd | Not published | Yes | Yes |
| Desktop GUI | No | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | No | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Yes | Yes |
| Memory fork | Yes | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | No | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | No | Yes | Yes |
| Raw TCP inbound | Not published | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | No | Yes | Yes |
| Secret proxy for any API | No | Yes | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | Yes | No | Yes |
| MCP server | No | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | Yes | No | No |
| Self-hosting | No | No | No |
| BYOC | No | No | No |
| Open source | No | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | Yes | Yes | Yes |
| Audit logs | Not published | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable CPU measurement for Google Agent Runtime or Azure Container Apps Sandboxes, so this page makes no speed claim between them. boat did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in StarSling's public run of 2026-09-29, a test neither of the other two was part of.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Google Agent Runtime and Azure Container Apps Sandboxes have no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Google Agent Runtime, a month | Azure Container Apps Sandboxes, a month | boat, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $73 · Pay as you go | $68 · Pay-as-you-go | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $301 · Pay as you go | $262 · Pay-as-you-go · with limits | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $3,626 · Pay as you go · with limits | $3,421 · Pay-as-you-go | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $1,030 · Pay as you go | $989 · Pay-as-you-go | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $2,060 · Pay as you go | $2,148 · Pay-as-you-go | $2,000 · $2000/mo · with limits |
Google Agent Runtime: Google bills $0.085 per vCPU-hour and $0.009 per GiB-hour allocated, with the first 50 vCPU-hours and 100 GiB-hours free each month. Runtime skips idle time between turns, but sandboxes are billed while they exist, and disk and egress rates are not published.
Azure Container Apps Sandboxes: Azure bills per second on the Container Apps Consumption meters for the vCPU and memory of the sandbox's tier while it runs, idle time before auto-suspend included. There is no plan fee, and some regions such as West Europe and UK South charge more.
Azure Container Apps Sandboxes: Plans start at $20 a month, and the whole fee is usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
On Google, a sandbox is deleted when its TTL ends, 7 days at most for a custom container, and the 50-agent fleet does not fit because there is no Docker inside. On Azure, the always-on agent only gets close with a 3-year commitment, and a default quota of 500 active cores caps a fleet until support raises it. boat's start limits are the tight ones for the 1,000-job burst: the $2,000 plan queues starts above 90 a minute.
| Scenario | Google Agent Runtime | Azure Container Apps Sandboxes | boat |
|---|---|---|---|
| One coding agent, workdays |
| None that bite | None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
| None that bite | None that bite |
| Sandboxes for your users |
| None that bite | None that bite |
| 1,000 short jobs at once |
| None that bite |
|
Which one should you use?
Use Google Agent Runtime when
you build agents with ADK or LangGraph on Google Cloud and want them hosted in your own project, with short code runs and a browser in a locked sandbox behind your network rules.
- A managed home for your agent code. If you build agents with ADK or LangGraph, Agent Runtime hosts them and does not bill idle time between turns.
- A browser agents can drive. Its Computer Use sandbox gives agents a browser with a VNC live view, a click and type API, and CDP for Playwright.
- Egress locked down by default. Outbound internet is off unless a template turns it on, and it can leave through your VPC with a static IP.
Use Azure Container Apps Sandboxes when
your team already runs on Azure and wants microVMs with root that suspend with their memory, wake on traffic and sit behind fine-grained egress rules.
- A microVM with root. Each sandbox has its own kernel and root, and images like azure-dev ship Docker on systemd.
- Memory suspend and wake on traffic. Idle sandboxes suspend with their memory and resume in under a second when traffic or a start command arrives.
- No session cap and public ports. A sandbox runs until you stop it or it goes idle, and it can publish HTTPS routes per port.
Where boat fits
Google and Azure both run agents inside a hyperscaler account, and both are built for short tool calls more than for agents that work like a person at a computer. If your agents install tools, run Docker and emulators, open a browser on a screen or serve what they build, boat gives each one a full VM that keeps its disk.
Root, Docker and /dev/kvm on every VM
Google runs commands as appuser with no sudo or Docker, so the 50-agent fleet does not fit there. On Azure, Docker means picking an image like azure-dev, and nested virtualization for Android emulators is not documented.
A screen, SSH and public ports
Google gives only a browser and no public URL; Azure is headless with HTTPS routes and no SSH. Each needs work around it: a VPC endpoint or tunnel on Google, your own display and streaming stack on Azure.
Coding agents driven from outside, keys kept out
Google's Managed Agents API is in Preview and runs only Antigravity. Azure's Claude Code image runs through raw exec with tokens injected into the sandbox, where prompt injection can read them. boat's proxy keeps keys outside.
Use boat when your agents need a whole computer: root, Docker, /dev/kvm, SSH, a 60fps desktop and public ports on a full VM that keeps its disk, with coding agents and a credentials proxy built in. Compare it one to one: boat vs Google Agent Runtime and boat vs Azure Container Apps Sandboxes.
Questions people ask
Is Google Agent Runtime cheaper than Azure Container Apps Sandboxes?
They are close. Azure comes out a little lower in most of our scenarios: one coding agent on workdays is $68 a month on Azure and $73 on Google, and sandboxes for your users are $989 against $1,030. For 1,000 short jobs at once Google is lower, $2,060 against $2,148. boat comes to $20 a month and $200 a month for those first two.
Which is faster?
Neither Google Agent Runtime nor Azure Container Apps Sandboxes has a comparable CPU measurement, so we cannot say. boat did 26.69 runs per second on StarSling's Node.js build-and-test loop at 4 vCPU / 8 GB.
Can Google Agent Runtime or Azure Container Apps Sandboxes run Docker?
Google's sandboxes cannot: commands run as appuser with no sudo, and images must not need root. On Azure it depends on the image: azure-dev ships Docker on systemd, while the default ubuntu image has only Buildah. boat runs Docker and /dev/kvm on every sandbox.
Can I SSH into either one?
No. Google runs each command in a new shell through its execute_bash() API, and Azure gives an interactive shell through the aca CLI, the SDK or the portal. Every boat sandbox has SSH.
Can a sandbox keep its memory when it stops?
Both can. Google snapshots keep memory and files, and Azure suspends a sandbox with its memory and resumes it in under a second, waking on traffic. boat saves the disk every minute and on stop, but resuming boots the machine again.
Where do they run?
Google runs in 23 locations across the US, Europe, Asia, Canada, Australia and Brazil, and Azure in 40 regions, 9 of them in the EU. boat runs only in the EU, in Germany, Finland and France.
Try boat
Install the CLI, then run boat new.
7-day free trial
More comparisons
- boat vs Google Agent Runtime
- boat vs Azure Container Apps Sandboxes
- E2B vs Google Agent Runtime
- Daytona vs Google Agent Runtime
- Modal vs Google Agent Runtime
- Vercel Sandbox vs Google Agent Runtime
- Cloudflare Sandbox vs Google Agent Runtime
- Blaxel vs Google Agent Runtime
- Runloop vs Google Agent Runtime
- Tensorlake vs Google Agent Runtime
- Morph Cloud vs Google Agent Runtime
- CodeSandbox SDK vs Google Agent Runtime