Deploy Docker to Azure: Container Apps, ACI or App Service?

Deploying a Docker container to Azure is not one decision. You must choose where the image is stored, which Azure service runs it, how traffic reaches it, how secrets are supplied, how updates are released and how costs behave when traffic is low. For small teams, the platform choice matters more than the first successful command.

This guide compares Azure Container Apps, Azure Container Instances and Azure App Service for Containers, then walks through a practical Azure Container Apps deployment using Azure Container Registry. It is based on official Microsoft documentation and public pricing information checked on 12 October 2026. No vendor paid for inclusion, and no benchmark was performed; command outputs and final costs depend on your subscription, region, image and workload.

Quick answer: which Azure container service should you choose?

Service	Best fit	Scaling and operations	Cost pattern
Container Apps	HTTP APIs, event-driven apps, microservices and background jobs	Managed serverless platform with revisions, ingress and scale rules	Consumption or dedicated options; can scale to zero
Container Instances	Short jobs, demos, automation and isolated one-off containers	Direct container groups without a full orchestrator	Per-second resources while the group runs
App Service	Traditional web apps and APIs that need familiar web hosting features	App Service plan, deployment slots, domains and platform integration	Provisioned plan capacity shared by apps
AKS	Complex Kubernetes platforms requiring cluster control	Full Kubernetes operations and ecosystem	Cluster and supporting-resource costs plus operational effort

For a new small-team API with variable traffic, Container Apps is usually the strongest starting point. Use Container Instances when you need a simple container or task without a long-running application platform. Use App Service when the organization already operates App Service plans and values its web-app workflow. Choose Azure Kubernetes Service only when Kubernetes capabilities justify cluster complexity.

Understand the deployment architecture

A production-minded flow has four parts. Docker builds an immutable image. Azure Container Registry stores versioned images. The runtime service pulls a selected image. Azure Monitor and application telemetry help the team observe health after deployment. Configuration, secrets and identity stay outside the image.

• Source code and Dockerfile describe the application and runtime.

• A versioned image such as neo-api:1.0 is built and tested locally or in CI.

• Azure Container Registry stores the image close to the Azure runtime.

• Container Apps, ACI or App Service pulls the approved tag or digest.

• Managed identity and role-based access reduce the need for registry passwords.

• Logs, metrics, traces and alerts reveal whether the release works for users.

If Docker concepts are still new, read NeoAI Tech’s Docker beginner guide before deploying. It explains images, containers, ports, volumes and registries without mixing them with cloud-specific steps.

Step 1: prepare and test a small container locally

The example assumes a web application listens on port 8000 and exposes a health endpoint. Your application must listen on 0.0.0.0 inside the container. Binding only to 127.0.0.1 makes the process unreachable through the platform ingress even when the container starts successfully.

Create a Dockerfile with a small trusted base image, copy dependency metadata before source code for better build caching, run as a non-root user where practical and keep credentials out of the image. Pin important runtime versions and scan the final image in CI.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Build and run the image locally. Use a version tag instead of relying only on latest. Confirm the application route, health endpoint, logs and shutdown behavior before creating cloud resources.

docker build -t neo-api:1.0 .
docker run --rm -p 8080:8000 --name neo-api neo-api:1.0
docker logs neo-api

This guide does not claim that these commands were executed against your subscription. Treat resource names and regions as examples, review them, and verify every command in a non-production resource group first.

Step 2: sign in and select the correct Azure subscription

Install or update the Azure CLI using the official Azure CLI installation guidance. Sign in, list subscriptions and explicitly select the intended one. A common deployment mistake is creating resources in the wrong tenant or subscription.

az login
az account list --output table
az account set --subscription "<subscription-name-or-id>"
az account show --output table

Create a dedicated resource group in a supported region. Keeping tutorial resources together makes ownership, access control and cleanup easier.

az group create --name neo-container-rg --location centralindia

Step 3: create Azure Container Registry and push the image

Azure Container Registry provides a private registry for container images and artifacts. Registry names must be globally unique. The Basic tier is often sufficient for a learning deployment, but production requirements may need higher throughput, geo-replication or private networking available in other tiers.

az acr create --resource-group neo-container-rg --name <uniqueRegistryName> --sku Basic
az acr login --name <uniqueRegistryName>
docker tag neo-api:1.0 <uniqueRegistryName>.azurecr.io/neo-api:1.0
docker push <uniqueRegistryName>.azurecr.io/neo-api:1.0
az acr repository show-tags --name <uniqueRegistryName> --repository neo-api --output table

For automated builds, prefer workload identity, managed identity or a narrowly scoped service connection over long-lived administrator credentials. Use immutable tags or image digests for controlled releases. A mutable latest tag makes rollback and incident investigation harder because the same label can point to different content.

Step 4: deploy to Azure Container Apps

Microsoft’s Container Apps existing-image quickstart describes the current CLI setup. Install or update the Container Apps extension, register required providers, create an environment and deploy the image with external ingress.

az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights
az containerapp env create --name neo-apps-env --resource-group neo-container-rg --location centralindia
az containerapp create --name neo-api --resource-group neo-container-rg --environment neo-apps-env --image <uniqueRegistryName>.azurecr.io/neo-api:1.0 --target-port 8000 --ingress external --min-replicas 0 --max-replicas 3

A private registry also requires authentication. Avoid copying an administrator password into scripts or application settings. Microsoft documents managed identity for Container Apps image pulls; grant only the required pull role and test that an unauthorized identity cannot read the registry.

Review the official managed-identity image-pull guidance before production. User-assigned identities can be reused across resources, while system-assigned identities follow the lifecycle of one container app.

Retrieve the application URL and inspect the deployed revision. Send a request to the health endpoint, check application logs and confirm the replica range matches your intent.

az containerapp show --name neo-api --resource-group neo-container-rg --query properties.configuration.ingress.fqdn --output tsv
az containerapp revision list --name neo-api --resource-group neo-container-rg --output table
az containerapp logs show --name neo-api --resource-group neo-container-rg --follow

Step 5: update safely and keep rollback possible

Build every release with a new tag, push it, then update the app. Container Apps creates a new revision when revision-scoped properties change. Test the new revision before sending all production traffic. Keep at least one known-good image available until the release has passed health, error-rate and latency checks.

docker build -t neo-api:1.1 .
docker tag neo-api:1.1 <uniqueRegistryName>.azurecr.io/neo-api:1.1
docker push <uniqueRegistryName>.azurecr.io/neo-api:1.1
az containerapp update --name neo-api --resource-group neo-container-rg --image <uniqueRegistryName>.azurecr.io/neo-api:1.1

Do not treat a successful CLI response as proof that the application works. Validate the public route, health endpoint, logs, dependencies, configuration and a representative user transaction. Roll back by selecting the known-good image or revision when acceptance checks fail.

When Azure Container Instances is the better choice

Azure Container Instances is designed for running containers without managing virtual machines or a full orchestrator. The official ACI quickstart uses az container create to deploy an isolated container and expose it through a DNS label.

az container create --resource-group neo-container-rg --name neo-job --image mcr.microsoft.com/azuredocs/aci-helloworld --dns-name-label <unique-dns-label> --ports 80 --os-type Linux --cpu 1 --memory 1.5

ACI is useful for short jobs, burst processing, build agents, demos and simple isolated workloads. It is less suitable when you need revision traffic splitting, rich autoscaling rules, a broader application platform or the operational ecosystem of Kubernetes. Charges are based on allocated resources and runtime, so delete finished container groups and verify that scheduled jobs actually stop.

When App Service for Containers is the better choice

App Service is a mature managed web-hosting platform with custom domains, certificates, deployment slots, authentication options and integration with App Service plans. It can be efficient when a team already hosts web applications on a plan and wants containers to follow the same operational model.

Microsoft’s custom-container quickstart shows how App Service pulls a custom image from a registry. The custom-container CI/CD guidance explains registry configuration and push-triggered deployment options.

App Service plans reserve capacity whether or not a particular application receives traffic. That can be an advantage when several predictable apps share a plan, but it is different from scale-to-zero consumption behavior. Confirm container port settings, startup time, health checks, storage expectations and plan limits before migrating.

Cost, security and reliability checklist

Azure prices vary by region, currency and agreement. The official Container Apps pricing page states that the Consumption plan is billed by allocated vCPU-seconds, GiB-seconds and requests, with monthly free grants and no usage charge when an app is scaled to zero. App Service uses plan capacity, while ACI uses per-second resource billing. Include registry, networking, log ingestion, data transfer and monitoring in the estimate.

• Use unique version tags or digests and preserve a known-good rollback image.

• Use managed identity and least-privilege roles instead of registry administrator credentials.

• Store secrets in an approved secret store or platform secret feature, never in the image.

• Set CPU, memory and replica limits deliberately; defaults are not a cost strategy.

• Configure health probes that reflect application readiness, not only process existence.

• Collect useful logs and metrics, but control retention and noisy telemetry.

• Restrict ingress and use HTTPS, authentication and network controls for sensitive APIs.

• Delete the tutorial resource group after learning if nothing else depends on it.

For observability design, use the OpenTelemetry Flask guide and the cloud monitoring tools comparison to decide what telemetry should be collected and where it should be analyzed.

Common deployment problems

The container starts but the URL fails

Confirm the process listens on 0.0.0.0, the target port matches the application port, ingress is external when public access is intended, and the health endpoint does not depend on unavailable services.

The runtime cannot pull the image

Check the full registry hostname, repository name and tag. Verify that the runtime identity has permission to pull from the registry. Do not solve every authentication error by enabling the registry administrator account.

A new deployment still shows old behavior

Confirm that a new image tag was pushed and the runtime references it. Mutable tags and client caching can hide what changed. Inspect the active revision and image digest instead of assuming the build replaced the running artifact.

The application works locally but exits in Azure

Inspect startup logs, required environment variables, CPU architecture, file-system assumptions and dependency availability. Containers should write persistent business data to an external service, not depend on the writable container layer surviving replacement.

Frequently asked questions

What is the easiest Azure service for a Docker container?

Azure Container Instances is simplest for a one-off container. For a small web API that needs managed ingress, revisions and autoscaling, Azure Container Apps is usually the more complete starting point.

Should a beginner use AKS to deploy one container?

Usually no. AKS is valuable when Kubernetes control and ecosystem features are required, but one small container rarely justifies cluster operations. Learn Container Apps, ACI or App Service first unless Kubernetes itself is the learning goal.

Do I need Azure Container Registry?

No. Azure services can pull from supported public or private registries, but ACR integrates closely with Azure identity, networking and deployment workflows. A private registry is recommended for proprietary production images.

Can Azure Container Apps scale to zero?

Yes, the Consumption plan can scale an application to zero when configured for it and when no requests or events require replicas. Check latency expectations because the first request after zero replicas may experience startup delay.

How should I deploy updates without losing rollback?

Build an immutable versioned image, push it, create or update to a new revision, run acceptance checks and retain the previous known-good revision or image until the release is stable.

Build a repeatable Azure container workflow

A successful deployment is repeatable, observable and reversible. Begin with one tested image, one registry, one managed runtime and one clear health check. Add CI/CD, private networking, autoscaling rules and advanced traffic management only when the workload requires them.

NeoAI Tech provides practical technology programs covering Docker and Azure monitoring. Teams that need help planning container architecture, deployment automation or a production readiness review can explore NeoAI Tech’s cloud engineering services.

Discuss Your Azure Deployment