Azure Container Apps Sandboxes

Isolated microVMs,
on demand.

Start with CLIClone samplesOpen portal

Secure egress. Built-in egress proxy with configurable deny policies, host allowlists, and credential injection.

Strong isolation. Each sandbox runs in its own secure boundary with its own kernel. Safe for untrusted code.

Built for AI Apps & Agents. Programmable from CLI, Python SDK, or REST - the shape AI workloads need.

Sub-second startup. Boot, execute, and discard a sandbox in seconds.

Suspend and resume. Snapshot full memory and disk state. Resume in sub-second, scale to zero between.

Bring your own images. Create sandboxes from container images you already use.

Anatomy of a sandbox

There are multiple ways to create and manage sandboxes: using the Portal, the ACA CLI, or SDKs.

A sandbox group is a regional Azure Resource Manager (ARM) resource that can contain thousands of sandboxes. Each sandbox starts from a disk image, can mount data volumes, and has one of two lifecycle states: Running or Stopped. Stopped sandboxes don't incur compute charges. Snapshots capture memory and disk so you can clone a sandbox or restore its state. Public ingress routes each port-specific hostname through an ingress proxy to one sandbox and can wake a stopped sandbox on request. Sandboxes use Microsoft Entra managed identities and reach external services through an egress proxy with host allowlists, deny policies, and credential injection. Both directions can be private: a sandbox group can join an Azure virtual network (VNet) so sandboxes reach private resources over your subnet, and it can accept inbound traffic through a private endpoint in your VNet instead of the public internet.

What you can build

AI Apps & Agents. Persistent, isolated workspaces that survive across task boundaries. Suspend between turns, resume with full context.

Code execution. Run untrusted code in seconds with strong isolation. Capture state with snapshots, replay deterministically.

Dev environments. Per-user compute that scales from zero to thousands on demand and preserves state across sessions.

Traditional Apps. Lift and shift workloads that need stateful compute and long-running sessions without rewriting your application.

Secure Multi-Tenant Compute. Run untrusted workloads from multiple tenants with strong isolation between them.

Many more… CI runners, browser automation, data prep, reproducible experiments - anywhere a fast, isolated VM helps.

Building blocks

Sandbox groups. Regional ARM resource that contains your sandboxes and the VNet, identity, and quota they share.

Sandboxes. Start, run commands, label, tune CPU and memory, suspend, resume, and delete individual microVMs.

Disk images. Import OCI container images and use them as the root filesystem for new sandboxes.

Volumes. Azure Blob for shared, multi-attach data. Azure Data Disk for high-performance single-attach.

Secrets. Inject configuration and credentials into a sandbox as environment variables at boot.

Identity. Attach managed identities at the group level for token-broker access to Azure services.

Boot, suspend, resume. Bring up a sandbox in under a second. Suspend full memory and disk, then resume in place.

Snapshots. Fork a primed sandbox into many replicas, restoring full memory and disk in under a second.

Exec & interactive shell. Run commands inside a sandbox over the data plane, stream stdout/stderr, and attach a PTY.

File access. Upload, download, and stream files in and out of a running sandbox over the data plane.

Ports. Expose HTTP ports from a sandbox for inbound connections and previews.

Egress proxy. Control outbound traffic with deny policies, host allowlists, and credential injection - no secrets inside the sandbox.

Labels & metadata. Tag sandboxes for routing, billing, and per-tenant filtering when you list or query them.

Monitoring. Export logs, OpenTelemetry signals, operational metrics, and network egress decisions to your observability backends.

Virtual networks. Connect sandbox groups to delegated subnets so sandboxes can reach private resources in your VNet.

Sandboxes or dynamic sessions?

Dynamic sessions route HTTP requests through a managed pool - best for stateless code execution at request scope. Sandboxes give you direct CLI / SDK control over individual microVMs, with suspend, snapshots, persistent volumes, and egress policy. Reach for sandboxes anytime state, lifecycle, or networking control matters.

Get started

Quickstart: Portal

Use the portal to provision a group and launch your first sandbox.

Learn more →

Quickstart: CLI

Sign in, create a group, and start your first sandbox in under five minutes.

Learn more →

Quickstart: Python

Boot, exec, snapshot, and tear down from a script.

Learn more →

Quickstart: Agent Skills

Connect sandboxes to Copilot, Claude Code, or any agent.

Learn more →