It is a managed service for running containerised applications, with automatic scaling and very little infrastructure to manage.

A container is a package that holds an application together with everything it needs to run: its code, its libraries and its settings. Because the package carries its own needs, it behaves the same on a developer’s laptop, on a test server and in the cloud. This solves the old complaint “it works on my machine but not on yours”.

Running one container is easy. Running many containers reliably is harder. Someone must start them, restart them when they crash, spread them across machines, connect them to each other, update them without downtime and add more of them when traffic grows. The popular tool for this job is Kubernetes, which is very powerful but also complex to set up and operate.

Azure Container Apps gives you the benefits of containers and the scaling of Kubernetes, without asking you to manage a cluster. You give it a container image and a few settings. The service runs your containers, gives them a web address if you want one, scales the number of copies up and down based on rules, and can even scale to zero copies when nobody is using the application. You pay only for the resources used while your containers are running, with an allowance of free usage each month.

Behind the scenes, the service runs on Kubernetes and uses well-known open-source parts, but it does not give you direct access to the cluster. This is a deliberate trade: you give up some control in return for simplicity.

Words you will meet again and again

Because many teams want containers and microservices, but do not want to become Kubernetes experts.

Containers became very popular because they make applications portable and consistent. Teams started to break big applications into small services, each in its own container, which can be developed, deployed and scaled separately. This style is called microservices.

Running such systems at scale needs an orchestrator, which is a system that manages containers across many machines. Kubernetes is the best-known orchestrator, but it brings many concepts to learn, such as pods, deployments, services, ingress controllers, node pools, upgrades and security policies. A small team may spend more time operating the cluster than building the product.

Other Azure options sit at the two ends of a range. Simple web hosting services are easy but less flexible for multi-service systems. Full Kubernetes is flexible but demanding. Azure Container Apps fills the middle: easy enough for a small team, yet rich enough for microservices, background workers and event-driven systems.

Four simple objects explain almost everything you will do in Container Apps.

flowchart TD
  ENV["Environment: shared network and logs"] --> APP1["Container App: orders"]
  ENV --> APP2["Container App: payments"]
  APP1 --> R1["Revision 1"]
  APP1 --> R2["Revision 2"]
  R2 --> P1["Replica A"]
  R2 --> P2["Replica B"]
  APP2 --> R3["Revision 1"]
  R3 --> P3["Replica A"]
        

Scope-changing and non-scope-changing updates

Some changes create a new revision, such as changing the container image, the container resources or the scale rules. Other changes apply to the whole app without a new revision, such as ingress settings and secrets in many cases. Knowing the difference helps you plan updates and understand why revisions appear in your list.

Looking under the bonnet explains scaling, routing and cold starts.

Azure Container Apps runs on top of managed Kubernetes clusters that Microsoft operates for you. You never see these clusters, nodes or pods directly. The platform combines several open-source building blocks with Azure’s own control system.

sequenceDiagram
  participant U as User
  participant E as Ingress Proxy
  participant S as Scaler
  participant C as Platform Controller
  participant R as Replica
  U->>E: First request after idle period
  E->>S: Traffic detected, no replica running
  S->>C: Scale from zero to one
  C->>R: Pull image and start container
  R-->>C: Ready
  C-->>E: Replica available
  E->>R: Forward the waiting request
  R-->>U: Response
        

A container app can hold more than one container, and each has a role.

The main container runs your application. You tell the platform where to find its image, how much processor and memory it needs, which port it listens on and which environment variables to set. The image normally comes from a registry. Azure Container Registry is the natural choice inside Azure, and the platform can use a managed identity to pull from it without storing a password. Public registries are also supported.

Ingress is the front door of your container app.

When ingress is enabled, the platform gives your app a web address and routes incoming requests to its replicas. You can choose how open that front door is.

Revisions let you release new versions safely and roll back quickly.

Every revision is a frozen snapshot. In single-revision mode, which is the default, a new revision replaces the old one after it becomes healthy, and the old one is deactivated. In multiple-revision mode, several revisions can run at once, and you decide what percentage of traffic goes to each. This opens the door to safer release strategies.

flowchart LR
  U["Incoming Traffic"] --> E["Ingress with Traffic Rules"]
  E -->|"90 percent"| R1["Revision 1: stable"]
  E -->|"10 percent"| R2["Revision 2: canary"]
  R2 --> M["Watch errors and latency"]
  M -->|"healthy"| P["Increase to 100 percent"]
  M -->|"problems"| RB["Send all traffic back to Revision 1"]
        

Scaling is the heart of Container Apps, and it is controlled by simple rules.

Each revision has a minimum and a maximum number of replicas. Between those limits, scale rules decide how many replicas should run. When a rule says that more capacity is needed, the platform starts new replicas. When demand drops, it removes them. If the minimum is zero and there is no work, the app scales to zero and costs nothing in consumption mode.

flowchart TD
  Q["Messages waiting in a queue"] --> K["Scaler checks the length regularly"]
  K --> D{"More messages per replica than target?"}
  D -->|"Yes"| UP["Add replicas up to maximum"]
  D -->|"No"| DOWN["Remove replicas down to minimum"]
  DOWN --> Z["Zero messages and minimum zero: scale to zero"]
        

Choosing good scale settings

Container Apps lets you choose between pay-per-use capacity and dedicated capacity, and you can mix them.

An environment can offer different workload profiles. A workload profile is a type of hardware capacity on which apps run. The platform has a consumption profile, where you pay for what your replicas use, and dedicated profiles, where you reserve machines of a chosen size for your apps and pay for them while they exist.

Not every workload is a service that waits for requests. Some tasks start, do their work and stop.

A container app job runs a container to completion. Unlike a normal app, which keeps running, a job starts when triggered, finishes its task and exits. You pay only for the time it runs. Jobs are ideal for batch processing, scheduled tasks and one-off operations.

Small services must find and talk to each other, and Container Apps offers help.

When an application is split into many services, a new set of problems appears. How does one service find another? How do you handle temporary failures? How do services send messages or share state? Dapr, the Distributed Application Runtime, is an open-source project that offers common building blocks for these problems. Container Apps can run a Dapr helper process beside your container, so your code calls simple local endpoints instead of learning each Azure service’s own interface.

flowchart LR
  O["Orders Service + Dapr helper"] -->|"service call by name"| I["Inventory Service + Dapr helper"]
  O -->|"publish event"| B["Message Broker"]
  B -->|"subscribe"| N["Notifications Service + Dapr helper"]
  I --> S["State Store"]
        

Even without Dapr

Apps need settings and secrets, and they must reach the container safely.

An environment variable is a named setting passed to a container, such as the address of a database. Container Apps supports plain environment variables and secret-backed variables. A secret is a value, such as a password or an access token, that is stored securely by the platform and passed to the container only when needed.

The environment decides how your apps connect to the world and to your private networks.

Containers are temporary, so think carefully about where data lives.

Containers are designed to be replaced at any time. When a replica stops, anything written inside its own file system disappears. Good container designs keep data outside the container.

Because the platform is managed, security is a shared job with clear boundaries.

Without clear signals, a scaling system of small services is hard to understand.

Container Apps sends logs and metrics to Azure Monitor. Each environment is linked to a log destination, usually a Log Analytics workspace, where console output and system messages are stored and can be searched.

A good pipeline turns a code change into a safe release without manual steps.

Azure has several ways to run containers, and each fits a different situation.

flowchart TD
  Q1{"Need direct Kubernetes API or custom operators?"} -->|"Yes"| AKS["Azure Kubernetes Service"]
  Q1 -->|"No"| Q2{"Single simple web app?"}
  Q2 -->|"Yes"| AS["App Service"]
  Q2 -->|"No"| Q3{"Microservices, workers, jobs, event-driven scale?"}
  Q3 -->|"Yes"| ACA["Azure Container Apps"]
  Q3 -->|"Short function-style code"| FN["Azure Functions"]
        

These layouts appear again and again in successful Container Apps systems.

Container Apps suits many everyday systems, particularly those with uneven traffic.

These habits regularly cause outages, leaks and surprise bills.

Walk through these steps whenever you plan a new Container Apps workload.

No. It runs on Kubernetes behind the scenes, but you do not manage or access the cluster. You work with simple concepts such as apps, revisions and scale rules, and the platform handles the rest.

When there is no traffic or work, the platform can reduce the replicas of an app to zero, so that you pay nothing for compute on the consumption profile. When a request or event arrives, a replica starts, which causes a short delay known as a cold start.

A revision is an unchangeable snapshot of a version of your container app, including its image and key settings. New versions create new revisions, and you can route traffic between revisions or roll back to an older one.

Container Apps is a higher-level, simpler service with built-in scaling and no cluster access. Kubernetes Service gives full control of the Kubernetes API and cluster, with more flexibility and much more to operate.

KEDA is an open-source tool for event-driven autoscaling. In Container Apps it allows apps to scale on many signals, such as queue length, stream lag and custom sources, and to scale to zero when idle.

Use jobs for tasks that start, finish and exit, such as batch processing, scheduled work and one-off operations. Use apps for services that stay available to handle requests or continuous streams of messages.

Yes, if you create the environment with virtual network integration, so that apps run inside your own network and can use private connections. Decide this when you create the environment, as it is hard to change later.

Deploying a new image creates a new revision. The platform starts the new replicas, checks their health and then shifts traffic, and with multiple-revision mode you can control the shift gradually and roll back if problems appear.

Use the consumption profile by default, scale to zero where cold starts are acceptable, set sensible maximum replicas, deactivate unused revisions, keep log volume reasonable and use dedicated profiles only when you need their size or hardware.

Use Dapr when its building blocks, such as service invocation, pub-sub messaging and state management, solve real problems in your microservices. For simple systems, built-in service discovery and direct service calls are often enough.

Azure Container Apps lets you run containers and microservices on a serverless platform that hides the complexity of Kubernetes. You create an environment, deploy container apps made of revisions and replicas, expose them through ingress when needed and scale them with simple rules powered by KEDA, even down to zero. Jobs handle tasks that run and finish, Dapr helps services work together, and workload profiles let you choose between pay-per-use and dedicated capacity. With stateless design, careful network and security choices, safe releases through revisions and clear observability, you can build flexible and economical systems, while remembering that the platform trades some control for simplicity.