Running code you do not trust is one of those problems that sounds solved until you actually have to do it. If you build agentic applications, multi-tenant platforms, or CI/CD systems, the options have traditionally been roll your own microVM fleet, bolt together gVisor or Firecracker yourself, or accept the blast radius. This week Microsoft moved the goalposts: Azure Container Apps Sandboxes is now generally available, after sitting in preview since June.
What actually shipped
Sandboxes land as a first-class resource type in Container Apps, Microsoft.App/SandboxGroups, sitting alongside apps, jobs, and dynamic sessions. That matters more than it sounds. When something is a first-class ARM resource, it gets RBAC, Bicep templates, CLI support, and audit logs for free, instead of living as a hidden flag on some other service.
Each sandbox is an ephemeral microVM with its own hardware isolation boundary. You bring a standard OCI container image, so there is no special build pipeline to learn, and sandboxes start in sub-second time from prewarmed pools. Microsoft also points out that this is the same compute foundation behind GitHub’s sandbox environments in Copilot, hosted agents in Foundry Agent Service, and Azure Container Apps Express. The isolation fabric those products run on is now a public API rather than internal plumbing.
Why this exists
LLM-generated code changed the threat model for a lot of teams. A chatbot that runs generated Python snippets needs isolation, certainly, but the harder case is the agent that works for hours: installs packages, writes files, runs tests, gets interrupted, resumes tomorrow. For that you need isolation that also keeps state, and that combination is genuinely rare as a managed offering.
This is where the suspend and resume story earns its keep. A sandbox can snapshot memory, disk, and preloaded libraries, suspend, then resume later with everything intact. No reinstalling the toolchain on every run, no re-downloading dependencies, no warming caches for the tenth time. For CI pipelines and agent workspaces that churn constantly, that is the difference between a sandbox you actually use and one you demo once.
Sizing and billing
Resource tiers run from XS at 0.25 cores and 0.5 GB up to XL at 4 cores, 8 GB, and 80 GB of disk. M is the default tier at 1 core, 2 GB, and 20 GB disk, which is enough for most code execution and test workloads. Full tier specs are in the sandbox overview documentation.
Billing follows the Container Apps Consumption plan model: per-second billing for vCPU and memory, and stopped sandboxes cost nothing. Every subscription also gets a monthly free grant of 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests, per the Container Apps pricing page. A side project running a few builds a day will likely never see a bill. Scale to zero means an idle sandbox fleet costs nothing, which makes ephemeral CI runners much easier to justify than a always-on build server.
Network and data
Each sandbox carries its own egress policy: domain allow and deny lists, CIDR rules, or full VNet integration. If you are running generated code, set the egress allow list before the first run, not after the first surprise. Agent workloads that fetch packages from the internet are exactly the workloads where an unlisted domain means exfiltration.
Volumes come in two shapes. Azure Blob volumes are shared across sandboxes, and Data Disk volumes mount into a single sandbox. Lifecycle policies cover auto-suspend and auto-delete, so a sandbox that a user abandoned last Tuesday can clean itself up without a cron job on your side.
Sandboxes versus dynamic sessions
If you have used Container Apps dynamic sessions, the overlap looks confusing. The distinction comes down to lifecycle. Dynamic sessions are pool-managed, HTTP-routed, and destroyed after a cooldown period, built for request-response code execution. Sandboxes give you programmatic lifecycle control, egress policy, volumes, and persistence across suspend and resume. For a chatbot executing short snippets, sessions remain the simpler choice. For a development environment or a CI runner that needs to survive between steps, a sandbox is the better fit, and the getting started guide walks through both paths.
Getting started, and the two things that will bite
The portal path lives at sandboxes.azure.com, with the Azure Container Apps CLI, a Python SDK, Bicep templates, and agent skills for Copilot CLI and Claude Code as alternatives. Two setup details trip people up. First, management requires the Container Apps SandboxGroup Data Owner role, so assign it at resource group scope rather than subscription scope unless you enjoy over-provisioned identities. Second, only Entra ID accounts work here, so personal Microsoft accounts are out.
My take: the GA itself is not the headline. The headline is that the microVM engineering that used to take a platform team a year is now a CLI call with a per-second meter. If you have been stitching together Firecracker or gVisor for untrusted code, it is worth an afternoon to compare your setup against this before building anything new on the old stack.