Use cases
Use Azure Container Apps when you need serverless container compute for API endpoints, background processing jobs, event-driven processing, or microservices. Apps can scale on HTTP traffic, event-driven processing, CPU or memory load, or any KEDA-supported scaler. Most apps can scale to zero.
For HTTP-first apps, Express is a streamlined path to production. It uses minimal configuration and scale-to-zero defaults.
Azure Container Apps includes four compute types:
When you create a sandbox, choose a public disk image, disk image, or snapshot as the source, and optionally configure network egress policy in advanced mode.
Choose the right compute option
| Compute type | Best for | Lifecycle | State |
|---|---|---|---|
| Apps | Long-running services, APIs, web apps | Continuous | Stateless with external state stores |
| Jobs | Run-to-completion tasks, batch processing | Start -> run -> complete | Stateless |
| Dynamic sessions | Managed code execution, LLM-generated scripts | Managed by session pool | Ephemeral |
| Sandboxes | Programmable isolated compute with lifecycle control | You manage create, suspend, resume, and delete actions | Stateful with memory or disk suspend modes |
Match a scenario to a compute type
Use this section to match what you are building to the Azure Container Apps compute type that fits it best.
API endpoints and HTTP web apps
Recommended: App with Express. Use for REST APIs and other HTTP-first services that need a streamlined route to production with minimal configuration and scale-to-zero defaults.
Microservices with Dapr and service discovery
Recommended: App in a standard environment. Use when your services need Dapr, service discovery, and internal networking inside a full Container Apps environment.
Event or queue processing
Recommended: App. Use when an app should respond continuously to events from a queue, stream, or other event source. Configure a custom KEDA scale rule for each event source.
Scheduled, manual, or event-triggered tasks
Recommended: Job. Use when a task runs from a cron schedule, starts from an API call, or runs after an event, then stops.
Untrusted or LLM-generated code execution
Recommended: Dynamic session or Sandbox. Use for untrusted or LLM-generated code where isolation contains what the code can do. Choose Dynamic sessions for managed code execution, or a Sandbox when you need isolated compute that you manage.
Agentic workspaces and parallel workers
Recommended: Sandbox. Use when each worker should run as its own sandbox with a selected source image, optional egress policy, and pause and resume controls.
Multi-tenant SaaS platforms and per-customer workspaces
Recommended: Sandbox. Use when each tenant or customer needs an isolated sandbox with pause and resume controls for longer-running work.
Ephemeral build-and-test and per-user development environments
Recommended: Sandbox. Use for temporary build-and-test runs or per-user development environments wired into CI/CD.
Event-driven automation
Recommended: Sandbox. Use when MCP connectors pair with triggers, such as email triage or document automation.
GPU workloads
Recommended: App. Use when an app needs GPU-backed compute. Confirm the current support matrix for environment type and workload profile requirements.
TCP-based services
Recommended: App in a standard environment. Use when a service uses TCP instead of HTTP. Express supports HTTP workloads only, so use a standard environment.
Related content
- Express overview: The fastest way to deploy HTTP-first web apps.
- Jobs: Run-to-completion tasks that start manually, on a schedule, or from events.
- Sandboxes overview: Programmable isolated compute with suspend and resume.
- Dynamic sessions: Managed code execution through a session pool endpoint.