Custom container web app - Azure Glossary

Understand the concept

In plain English

Custom container web app is an Azure App Service web app that runs a team-supplied container image instead of a built-in runtime stack. In plain English, it helps teams host web workloads with custom runtimes, dependencies, agents, or framework versions while still using App Service operations using container settings, registry access, and startup logs. You see it during App Service container settings, Azure Container Registry deployments, managed identity pull configuration, release slots, and startup log investigations. Check that ownership, access, configuration, evidence, and runbook steps match the workload.

Why it matters

Custom container web app matters because some applications need dependencies or runtime versions that do not fit the standard App Service platform stacks. If it is ignored, teams can create failed image pulls, slow startup, exposed registry credentials, stale tags, broken health checks, and production downtime during container swaps. Handled well, it gives architects, developers, finance owners, and operators a shared way to connect Azure settings, CLI output, dashboards, alerts, and incident notes. This is especially important when one misread signal affects budgets, customer experience, compliance evidence, or release timing. The practical value is simple: the term turns a hidden platform detail into a measured operating decision that someone can own, test, and explain.

Official wording and source

Custom container web app is an Azure App Service web app that runs a team-supplied container image instead of a built-in runtime stack. Microsoft Learn places it in Configure a custom container for Azure App Service; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Custom container web app is an App Service configuration where the site pulls a container image from a registry and runs it under the selected App Service plan. Inspect image name, tag, registry source, identity, startup command, app settings, port mapping, plan SKU, and container logs. Validate that the image starts locally, exposes the expected port, has approved dependencies, and can be pulled by the web app identity. Review network-protected registries, slot swaps, health checks, scale settings, and rollback tags; it influences deployment reliability, startup time, dependency control, registry security, and web application cost.

Exam context

Compare with

Container Apps Azure Functions App Service Linux worker Multi-container web app App Service Web App

Where it is used

Where you see it

In the portal, Custom container web app appears near App Service container settings, deployment center, where owners confirm scope, state, activity, and review evidence during audits, planning, and change reviews.
In CLI or IaC, Custom container web app appears as siteConfig LinuxFxVersion, container image tags, identity settings, helping reviewers compare documented intent with live Azure state before approved production changes.
In operations, Custom container web app appears beside startup logs, image pull events, health probes, where support teams separate configuration, use, ownership, and platform behavior during incidents and monthly reviews.

Common situations

Design or review production work where Custom container web app affects cost, performance, ownership, or reliability.
Troubleshoot an incident, report variance, or release concern using evidence tied to Custom container web app.
Create architecture, audit, or operations evidence for a change involving Custom container web app.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Legacy runtime modernization Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Horizon Claims, a insurance technology organization, needed to move a claims portal with a custom PDF library into Azure without waiting for the built-in runtime stack to match every dependency. The team used Custom container web app to deploy a controlled container while preserving App Service operations while protecting production evidence and keeping ownership clear.

Goals

Move the portal to Azure within one quarter
Keep claims-page P95 latency below 500 milliseconds
Avoid storing registry passwords in app settings
Enable rollback to the prior image tag within ten minutes

Approach using Custom container web app

Architects designed the approach around Custom container web app by building a hardened container image, storing it in Azure Container Registry, configuring App Service container settings, and using deployment slots for validation. They integrated Azure App Service, Azure Container Registry, managed identity, Application Insights, Key Vault, and Azure DevOps pipelines so support, security, finance, and engineering teams worked from the same facts. Operators captured read-only Azure CLI output, portal screenshots, dashboard links, and change records before any production adjustment. Security reviewers checked least-privilege access, data exposure, and retention rules. The rollout included owner tags, alert thresholds, a rollback or cleanup step, and a weekly review of the first production signals. This kept the work practical: one named term, one measurable operating control, and one accountable owner for follow-up.

Potential outcomes

The portal migrated three weeks ahead of the deadline
P95 latency measured 410 milliseconds after image tuning
Managed identity removed static registry credentials
Rollback testing restored the prior tag in six minutes

What to learn

Custom container web app is valuable when teams connect Azure configuration to measurable business outcomes, ownership, and operational proof.

Scenario 02 Private registry rollout Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Kestrel Media, a digital publishing organization, needed to host a custom rendering service from a network-protected registry without exposing image pulls publicly. The team used Custom container web app to secure container deployment for production editors while protecting production evidence and keeping ownership clear.

Goals

Keep image pulls inside approved network boundaries
Reduce failed startup incidents by 40 percent
Complete slot swaps without editor downtime
Capture registry and identity evidence for audit

Approach using Custom container web app

Architects designed the approach around Custom container web app by granting the web app identity AcrPull, enabling registry access through approved network paths, and checking container startup logs before slot swap. They integrated App Service, Azure Container Registry private endpoint, virtual network integration, Azure Monitor, and deployment slots so support, security, finance, and engineering teams worked from the same facts. Operators captured read-only Azure CLI output, portal screenshots, dashboard links, and change records before any production adjustment. Security reviewers checked least-privilege access, data exposure, and retention rules. The rollout included owner tags, alert thresholds, a rollback or cleanup step, and a weekly review of the first production signals. This kept the work practical: one named term, one measurable operating control, and one accountable owner for follow-up.

Potential outcomes

Image pulls succeeded through the approved network path
Failed startup incidents dropped 46 percent after log-based checks
Editors saw no downtime during the first three swaps
Audit records included identity, ACR role, and container settings evidence

What to learn

Custom container web app is valuable when teams connect Azure configuration to measurable business outcomes, ownership, and operational proof.

Scenario 03 Seasonal campaign API Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Vista Gardens, a consumer retail organization, needed to launch a containerized promotional API that required a custom native dependency for inventory recommendations. The team used Custom container web app to scale campaign traffic without redesigning the service while protecting production evidence and keeping ownership clear.

Goals

Support 3,000 requests per minute during launch day
Keep startup time under 90 seconds
Limit campaign hosting cost to the approved budget
Provide a clean rollback path for failed images

Approach using Custom container web app

Architects designed the approach around Custom container web app by deploying the campaign API as a custom container, sizing the App Service plan, and tagging images for blue-green rollback. They integrated App Service Plan autoscale, Azure Container Registry, Azure Front Door, Application Insights, and budget alerts so support, security, finance, and engineering teams worked from the same facts. Operators captured read-only Azure CLI output, portal screenshots, dashboard links, and change records before any production adjustment. Security reviewers checked least-privilege access, data exposure, and retention rules. The rollout included owner tags, alert thresholds, a rollback or cleanup step, and a weekly review of the first production signals. This kept the work practical: one named term, one measurable operating control, and one accountable owner for follow-up.

Potential outcomes

The API sustained 3,400 requests per minute in load testing
Startup time fell to 62 seconds after image slimming
Hosting cost stayed 11 percent under the campaign budget
The team rolled back one defective image tag in eight minutes

What to learn

Custom container web app is valuable when teams connect Azure configuration to measurable business outcomes, ownership, and operational proof.

Azure CLI

Use Azure CLI for Custom container web app to capture repeatable evidence, compare live settings with documented intent, and investigate production questions without changing the JSON engine.

Useful for

Confirm the active scope, owner, and live Azure configuration before approving a change involving Custom container web app.
Export current evidence for incident timelines, audit records, pull requests, and architecture or finance reviews.
Compare development, staging, and production when cost, performance, access, or monitoring behavior differs unexpectedly.

Before you run a command

Confirm the active tenant, subscription, management group or resource group, and exact resource names before running commands.
Start with read-only commands and avoid mutating, cost-impacting, or security-impacting changes unless a ticket approves them.
Capture expected state, business owner, evidence window, rollback path, and maintenance constraints before modifying production resources.

What the output tells you

It shows where Custom container web app is configured, observed, or missing and whether live Azure state matches the intended design.
It exposes scope, resource, metric, tag, policy, identity, endpoint, or status values needed for troubleshooting.
It creates repeatable evidence that can be pasted into runbooks, incident summaries, audit records, and release reviews.

Mapped commands

Custom container web app operations

direct

az webapp config container show --name <app-name> --resource-group <resource-group>

az webapp config containerdiscoverWeb

az webapp config container set --name <app-name> --resource-group <resource-group> --container-image-name <registry>/<image>:<tag>

az webapp config containerconfigureWeb

az webapp identity assign --name <app-name> --resource-group <resource-group>

az webapp identitysecureWeb

az acr repository show-tags --name <registry-name> --repository <repository> --output table

az acr repositorydiscoverContainers

Architecture context

Technically, Custom container web app is an App Service configuration where the site pulls a container image from a registry and runs it under the selected App Service plan. Inspect image name, tag, registry source, identity, startup command, app settings, port mapping, plan SKU, and container logs. Validate that the image starts locally, exposes the expected port, has approved dependencies, and can be pulled by the web app identity. Review network-protected registries, slot swaps, health checks, scale settings, and rollback tags; it influences deployment reliability, startup time, dependency control, registry security, and web application cost.

Security: Security for Custom container web app starts with knowing who can view, change, export, or act on the evidence. Use least-privilege Azure RBAC, Microsoft Entra identities, managed identities where relevant, private or restricted data paths, and logged approval workflows. Avoid exposing registry URLs, image tags, pull credentials, environment variables, connection strings, startup logs, and private endpoint names in dashboards, tickets, exports, repositories, or scripts. For Custom container web app, registry access should use managed identity when possible, and secrets should stay out of images, logs, and app settings exports. A secure design records owner, scope, allowed readers, change authority, retention expectations, break-glass path, and review cadence so troubleshooting does not become a reason for broad access or unmanaged data sharing.
Cost: Cost for Custom container web app shows up through App Service plan size, always-on behavior, extra slots, registry storage, image pulls, idle capacity, and troubleshooting time for failed startups. Measure the signal before changing the setting or blaming the platform, and track ownership, exceptions, and review dates. A cheap configuration for one workload can be expensive for another when traffic patterns, retention, tagging, query shape, or ownership boundaries change. Use tags, budgets, alerts, exports, and per-scope dashboards so product owners can see which behavior drives spend. The strongest cost review connects dollars to a real behavior, such as requests, storage, idle capacity, alerts, shared services, or untagged resources.
Reliability: Reliability for Custom container web app depends on predictable behavior during spikes, month-end processes, deployment changes, regional events, or dependency failures. Test image availability, registry authentication, startup probes, slot warm-up, rollback tags, scale limits, and platform maintenance behavior with production-shaped data, realistic time windows, and documented recovery steps. Operators should know which symptoms indicate stale data, missing tags, throttling, bad filters, alert noise, or resource pressure. Include rollback or mitigation steps before changing production resources or cost controls, because the setting often affects more than one team. Review the runbook during planned tests. The goal is not only availability; users need correct signals, acceptable response time, and a known path when conditions change.
Performance: Performance for Custom container web app is measured through container cold start, image size, startup command duration, port readiness, CPU and memory pressure, scale-out timing, and request latency. Review the signal with production-shaped data instead of tiny development samples or one-day cost snapshots. Azure Monitor metrics, Cost Management views, CLI output, SDK diagnostics, and portal evidence should tell the same story. Tune the design only after separating application delays, billing latency, tagging gaps, and configuration drift. A good performance fix reduces latency, noise, or operator effort without weakening security, correctness, allocation accuracy, or recovery. Capture baseline, change, and rollback evidence together. Re-test after deployments because traffic, tags, indexes, and usage patterns can shift the result.
Operations: Operations for Custom container web app should be repeatable enough that a second engineer can verify the same facts without tribal knowledge. Keep container settings, image tags, deployment slots, log streams, identity assignments, ACR permissions, health checks, and rollback instructions documented with deployment source, owner, change history, dashboard links, and escalation contacts. Use read-only Azure CLI checks, portal review, Azure Monitor or Cost Management views, and export evidence to compare intended state with live behavior. Runbooks should say what is safe to inspect, what requires approval, and what evidence must be captured before and after a change. Review the record after each production change. Good operations make the term a checked production control, not a hidden implementation choice.

Common mistakes

Treating Custom container web app as a label instead of checking the Azure scope, owner, access path, and evidence source.
Relying on one portal screenshot without confirming the active subscription, time range, filters, and resource scope.
Running a mutating or cost-impacting command before confirming permissions, rollback steps, and stakeholder approval.