Deploying a Simple App on Azure

For a simple web app — a Node.js, Python, .NET, or static frontend project without heavy custom infrastructure needs — Azure App Service is almost always the right starting point: it's a fully managed platform-as-a-service that handles the OS, runtime patching, load balancing, and TLS certificates for you, so you deploy just your code. If your app is already containerized, Azure Container Apps is a strong alternative that adds built-in autoscaling (including scale-to-zero) and Dapr integration for microservices patterns without you managing Kubernetes directly. Reaching for a full Azure Kubernetes Service (AKS) cluster or a raw Virtual Machine only makes sense once you have specific needs — a complex multi-container orchestration requirement, or OS-level customization — that a managed PaaS option can't satisfy; starting there for a simple app adds operational overhead with no corresponding benefit.

The fastest path from local code to a running Azure app is the Azure CLI's az webapp up command: run it from your project's root directory and it inspects your code, detects the runtime (Node, Python, .NET, PHP, Java), creates a resource group, an App Service Plan, and a Web App if they don't already exist, and deploys your code as a ZIP package — all in a single command. For more control, you separate the steps explicitly: az group create for the resource group, az appservice plan create to define the compute tier (and OS — Linux is generally cheaper and preferred for most modern stacks), az webapp create to provision the app, and then az webapp deploy or a ZIP-deploy command to push your build artifacts. Once deployed, az webapp log tail streams live logs directly to your terminal, which is often faster for debugging a startup failure than navigating to the portal.

Manual CLI deploys are fine for a first push, but any app you plan to iterate on should be deployed through a pipeline. Azure's Deployment Center feature on an App Service can auto-generate a GitHub Actions workflow that builds your code and deploys it on every push to a chosen branch, authenticating via either a downloaded publish profile (simplest, but a long-lived secret) or federated OpenID Connect credentials tied to a Microsoft Entra app registration (the current best practice, since it avoids storing any long-lived secret in GitHub at all). A typical workflow has two jobs: a build job that installs dependencies, runs tests, and produces an artifact, and a deploy job that downloads that artifact and calls the azure/webapps-deploy action — separating build from deploy means a failing test blocks the deployment automatically, before broken code ever reaches production.

App Service configuration — connection strings, API keys, feature flags — belongs in Application Settings, which are injected as environment variables at runtime and can be marked 'slot sticky' so they don't swap with a deployment slot (useful for keeping a staging slot pointed at a staging database). For real secrets, the better practice is to store them in Azure Key Vault and reference them from App Service using Key Vault references (@Microsoft.KeyVault(SecretUri=...)), so the secret value never actually lives in the App Service configuration blob, and access is governed by the app's managed identity rather than a shared key. Scaling has two independent dimensions: scale up (a bigger App Service Plan tier, for more CPU/memory per instance) and scale out (more instances behind the built-in load balancer, configured either on a schedule or reactively via autoscale rules watching a metric like CPU percentage or HTTP queue length).