Skip to main content

Container apps

Azure Container Apps is a serverless platform where you can run containerized applications without requiring you to manage the underlying cloud infrastructure. Instead of configuring servers, orchestrating containers, and handling deployment details yourself, Container Apps keeps your environment up-to-date for you automatically.

When you deploy an app, you are running an individual container app. To create a container app, you provide a container image and describe how it should run, and Azure Container Apps runs it for you.

Your app runs in a managed environment where changes to the revision template are tracked as revisions, and the app scales out or scales in by changing the number of running replicas to match demand. With a container app, you don't manage Kubernetes or the servers underneath. Instead, you configure the app, and the platform runs everything on your behalf.

tip

Want the fastest portal path for an HTTP-first app? Start with Express. With Express, you can create a container app with opinionated defaults so you can skip most of the upfront decisions. This article explains the general app model that works behind that experience.

How the app model fits together​

Every container app is built from the same set of parts:

  • Container image to run
  • App configuration that tells the platform how to run it
  • Environment that surrounds the app
  • Revisions that capture its history
  • Replicas that do the actual work

Understanding how these pieces interact together helps you build out your app.

It starts with a container image​

The container image is what's running in the Container Apps platform. It's your application packaged with everything it needs to execute, from your code to its runtime dependencies. It can live in a public registry or a private one. A private registry requires credentials to pull the image, which your app configuration provides.

For image requirements and registry setup, see Containers in Azure Container Apps.

Configuration tells the platform how to run it​

An image on its own doesn't specify how much memory to use, which container port ingress should route to, or whether it should accept public traffic. App configuration supplies those instructions. It's the set of settings the platform follows to run your image the way you intend.

Common settings include:

  • Environment variables and secret references, so your app reads its settings and credentials at runtime.
  • CPU and memory for each replica, which shapes both performance and cost.
  • Ingress, including whether the app accepts traffic and which target port ingress routes to.
  • Scale settings, such as the minimum and maximum number of replicas.
  • Registry settings, so the platform can pull the image when it needs to.
note

Not every setting behaves the same way when you change it. Application-scope changes such as ingress, secrets, registries, Dapr settings, and revision mode apply to the app resource as a whole. Changes to the revision template—including the image, environment variables, resources, and scale rules—create a new revision instead of altering the running one in place.

The environment is the boundary around your app​

Your app doesn't run in isolation. It lives inside a Container Apps environment, the boundary that groups related apps and jobs and gives them shared networking, logging integration, and platform configuration. Apps in the same environment can reach each other and share those capabilities, and the environment boundary keeps one group of workloads separate from another.

Every container app belongs to an environment. In the portal, environment setup is handled as part of creating the app: Express uses curated environment defaults, while Standard uses a Workload Profiles environment. Both App Types offer Advanced settings for additional configuration. Turn to the deeper environment details—networking, workload profiles, and logging—when a specific need calls for them.

Revisions capture template changes​

When you change revision-scope settings, such as shipping a bug fix in a new image or adjusting an environment variable, the platform doesn't quietly mutate the running app. Instead, it creates a revision, or a versioned snapshot of the parts of your app that affect how replicas run. Your first revision is created when you deploy, and every template change after that produces a new one.

Revisions are what make safe rollouts possible. As each version is captured, every edit builds on your app's history rather than replacing what is already there. Depending on your app's revision mode, you can keep a single active revision or run several at once. Running several revisions supports patterns like splitting traffic between an old version and a new one while you observe how the new one behaves.

For the full lifecycle, see Application lifecycle management and Revisions in Azure Container Apps.

Replicas do the work, and scale decides how many​

A revision describes your app, but a replica is a running instance of it, the instance actually serving requests or processing events. Your scale settings determine how many replicas run at any moment, moving between the minimum and maximum you set.

Scale-to-zero is one end of that range. Set the minimum to 0, and when there's no traffic, your app scales to zero replicas, so you don't pay to keep idle replicas running. The trade-off is a slight cold start, since the next request has to wait for a replica to start. As demand rises, the platform scales back out to meet it.

Your app's scaling behavior responds to triggers. Apps use built-in triggers for HTTP and TCP traffic, and you can add custom KEDA-based triggers to react to other event sources, such as a queue filling up. For trigger rule syntax and examples, see Set scaling rules in Azure Container Apps.

When a container app is the right choice​

Choose a container app when the workload behaves like a service, something that stays up and responds over time rather than running once and stopping.

It's the right fit when:

  • An HTTP API or web app needs to accept requests as they come.
  • A microservice needs to talk to other services inside an environment.
  • A worker needs to keep processing events or queue messages.
  • A service needs revision-based rollouts and scale rules.
info

If the lifecycle is different, another Azure Container Apps option likely fits better. For finite work that starts, runs, and stops, use a job. To run code in isolation outside your main app process, see Dynamic Sessions or Sandboxes.

Apps versus jobs, side by side​

Apps and jobs both run containers on Azure Container Apps. What separates them is the lifecycle. An app is a service that stays available, while a job is a task that runs to completion and stops.

Use this comparison to help you decide between them:

Use an app when...Use a job when...
The workload is a service that should be available over time.The workload is a task that should run to completion.
You want revision-based updates and traffic management.You want each run to be a discrete job execution.
Scale reacts to service demand such as HTTP traffic, TCP connections, or custom (KEDA-based) triggers.Runs start manually, on a schedule, or in response to an event.

For the jobs model in full, see Jobs.

Where Express fits in​

Express is a streamlined way to create an HTTP-first container app. It reduces the upfront decisions by choosing sensible defaults for the image, ingress, port, and scale. The app it produces is an ordinary container app, built on everything described above.

The App Type choice comes down to which environment mode and capabilities you need:

App TypeUse it when...
ExpressThe curated defaults fit and you want the fastest path for an HTTP-first app.
StandardYou need the Workload Profiles environment path or capabilities that are currently unavailable for Express.

Both App Types expose an Advanced settings accordion for additional configuration, including environment variables, command and arguments, scaling, networking, and environment options. See Express for its defaults and current capability differences.

Related content​

Last updated on