Dynamic Sessions and Sandboxes

Azure Container Apps includes two isolated execution models for workloads that should run outside the caller's container app, job, service, or automation process: Dynamic Sessions and Sandboxes.

Both models isolate execution, but they give you different levels of control. With Dynamic Sessions, a client uses a pool-managed execution slot behind a management endpoint. With Sandboxes, a client controls individual compute instances and their lifecycle, state, files, ports, snapshots, and policies.

Quick choice

Use Dynamic Sessions when your application or workflow wants isolated execution without managing individual compute instances. Use Sandboxes when the lifecycle of each isolated environment matters to your application or workflow.

At a glance

Need	Dynamic Sessions	Sandboxes
Status	GA (Generally available).	Preview.
Control model	Pool-managed execution slot behind a management endpoint.	Individually controlled compute instances.
Main unit	Session pool and session identifier.	Sandbox group and sandbox.
State model	Pool-managed and ephemeral.	Explicit lifecycle, suspend modes, snapshots, volumes, and files.
Best fit	Managed session execution through a pool endpoint for code interpreter or custom container workloads.	Programmable isolated environments that your workflow creates and controls.

Why isolated compute?

Use isolated compute when the work should not run inside the caller's app, job, service, or automation process. Common examples include:

• Running generated or untrusted code.
• Giving an AI agent a temporary execution environment.
• Creating a per-user or per-tenant workspace.
• Preserving or discarding state separately from the app or job that requested the work.

For a general compute-type comparison, see Use cases.

What are Dynamic Sessions?

Dynamic Sessions is a pool-managed execution model. A client sends requests to a session pool management endpoint and includes a session identifier. The pool routes work to the right session or creates capacity according to the pool configuration.

Dynamic Sessions works best when a caller wants isolated execution without managing individual compute instances.

Part	Role in the Dynamic Sessions model
Session pools	Store the configuration for Dynamic Sessions.
Session identifiers	Route related work to the right session while it exists.
Code interpreter and custom containers	Define the execution container type for the pool.

Session pools

A session pool stores the configuration for Dynamic Sessions. The portal model includes pool management type, pool management endpoint, scale configuration, lifecycle configuration, and network status.

The create flow builds session pools with settings such as maximum concurrent sessions, egress status, and timed cooldown behavior.

For setup details, see Session pools in Azure Container Apps.

Session identifiers

Requests include an identifier so the pool can route related work to the right session. The portal code execution path calls the pool management endpoint and passes the identifier on execution requests.

Use identifiers when you need repeat requests from the same user, agent, or workflow to reach the same session while it exists.

For request patterns and security guidance, see Use Dynamic Sessions.

Code interpreter and custom containers

Session pools can use built-in code interpreter container types or custom containers. The portal model includes built-in pool types for different runtimes, shell, and custom container pools.

info

For the current supported runtime list and API examples, use Code interpreter sessions.

What are Sandboxes?

info

Sandboxes is in Preview.

With Sandboxes, you can create and control isolated compute instances under sandbox groups. The feature is useful when you want to create, inspect, suspend, resume, snapshot, and delete specific environments.

Use Sandboxes when the lifecycle of each isolated environment matters to your application or workflow.

Part	Role in the Sandboxes model
Sandbox groups	Provide the management boundary for related sandbox instances.
Sandboxes	Represent individual compute instances in a group.
State, snapshots, and lifecycle control	Expose controls that Dynamic Sessions doesn't expose directly.

Sandbox groups

A sandbox group is the parent resource for sandboxes. It provides the management boundary for related sandbox instances. The portal and API model represent sandbox groups as Microsoft.App/sandboxGroups resources.

Start with a sandbox group when you want a place to create one or more sandboxes with related configuration.

Sandboxes

A sandbox is an individual compute instance in a group. The model includes explicit states and source options such as disk image, snapshot, and pod spec.

Individual sandboxes can expose ports, run commands, transfer files, use volumes, apply egress policy, and participate in lifecycle operations such as resume, stop, and delete.

For more details, see Sandboxes.

State, snapshots, and lifecycle control

With Sandboxes, you manage state controls directly. Dynamic Sessions doesn't expose those controls directly. These capabilities include:

Capability	What it enables
Lifecycle policies	Auto-suspend and auto-delete settings.
Suspend modes	Memory and disk suspend modes.
Volumes and exposed ports	Stateful storage and network access patterns.
Snapshots	Capture and restore sandbox state.
Command execution	Run commands inside a sandbox.
Lifecycle operations	Resume, stop, and delete operations.

How they overlap

Dynamic Sessions and Sandboxes both run work in an isolated place instead of inside the caller's own process. They are useful for AI, agents, code execution, automation, and tenant-isolated workloads.

These features still belong to the Container Apps family. A container app, job, service, or automation can call a session pool or manage sandbox instances when isolated work is needed.

How they differ

Question	Dynamic Sessions	Sandboxes
Who manages individual compute instances?	The session pool abstracts allocation and lifecycle.	You manage individual sandboxes.
How does the caller reach the work?	Send requests to a pool management endpoint with an identifier.	Call sandbox lifecycle, command, file, port, and related APIs.
What is the main unit?	Session pool and session identifier.	Sandbox group and sandbox.
What happens to state?	Treat sessions as pool-managed and ephemeral.	Use explicit lifecycle, suspend modes, snapshots, volumes, and files when you need control.
Best fit	Managed session execution through a pool endpoint for code interpreter or custom container workloads.	Programmable isolated environments that your workflow creates and controls.

When to choose Dynamic Sessions

Choose Dynamic Sessions when:

• The caller needs isolated code interpreter or custom container execution but should not manage each compute instance.
• A session identifier is enough to route related requests.
• Built-in code interpreter or custom container pools match the workload.
• The session can be ephemeral and governed by pool lifecycle settings.

Dynamic Sessions works well when a caller needs an execution slot for generated code, a user interaction, an agent step, or a custom container workload.

When to choose Sandboxes

Choose Sandboxes when:

• You need to create and manage individual isolated environments.
• You need suspend, resume, snapshot, files, ports, volumes, or command execution as first-class operations.
• You need state to outlive a single request and to be captured as a snapshot.
• Your workflow needs per-sandbox policy or lifecycle control.

The Sandboxes model fits agent workspaces, per-tenant environments, interactive developer environments, and workflows that need explicit state management.

How they relate to apps, jobs, and Express

Use this	For this lifecycle
Container apps	Long-running services, APIs, and workers.
Jobs	Run-to-completion tasks that start manually, on a schedule, or from events.
Express	The fastest portal path for an HTTP-first app.
Dynamic Sessions or Sandboxes	Workloads that need isolated execution outside the caller's app, job, service, or automation process.

Related content

• Dynamic Sessions: Microsoft Learn overview for Dynamic Sessions.
• Session pools: Pool setup and lifecycle configuration.
• Use Dynamic Sessions: Request routing, identifiers, and security.
• Code interpreter sessions: Built-in code execution APIs and examples.
• Sandboxes overview: Microsoft Learn overview for Sandboxes.
• Sandboxes: Sandbox overview and navigation.