Azure App Service Deployment Setup

Imagine you push code to main and within a minute it's live on production without a second of downtime. No manual FTP uploads, no 502 errors in the middle of the night. That's exactly what a properly configured Azure App Service deployment looks like. We've seen dozens of projects where small configuration errors — wrong runtime, missing environment variables, broken CI/CD — led to hours of downtime. Here's how to avoid that.

Proper Azure App Service setup involves several key components: choosing the right plan, automating builds and deployments, organizing environments via Deployment Slots, and configuring autoscaling. Below are the concrete steps we apply in every project.

Creating an App Service

The App Service Plan is the foundation. For production, we choose at least B2 tier to ensure performance headroom for PHP 8.3 or Node.js. Azure CLI command:

az group create --name myapp-rg --location westeurope
az appservice plan create \
  --name myapp-plan \
  --resource-group myapp-rg \
  --sku B2 \
  --is-linux
az webapp create \
  --name myapp-prod \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "PHP|8.3"

The first deployment can be done via FTP or zip, but we recommend setting up continuous integration immediately.

How to Set Up CI/CD with GitHub Actions?

GitHub Actions is the optimal choice for automation. We've prepared a universal workflow that we adapt to any stack:

# .github/workflows/azure-deploy.yml
name: Deploy to Azure
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader
      - name: Build frontend
        run: npm ci && npm run build
      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: myapp-prod
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: .

Important: store the publish-profile in GitHub secrets — never put passwords in the repository. The workflow runs automatically on every push to main, and within 2–3 minutes the new version is live.

Why Deployment Slots Are a Must for Production?

Deployment Slots are isolated environments inside the same App Service. You deploy a new version to staging, test it, then instantly swap to production. The swap takes seconds; users don't notice the switch. If something goes wrong, rollback is a single action.

# Create staging slot
az webapp deployment slot create \
    --name myapp-prod \
    --resource-group myapp-rg \
    --slot staging

# Deploy to staging
az webapp deploy \
    --name myapp-prod \
    --resource-group myapp-rg \
    --slot staging \
    --src-path deployment.zip

# Swap staging → production (instant, zero-downtime)
az webapp deployment slot swap \
    --name myapp-prod \
    --resource-group myapp-rg \
    --slot staging \
    --target-slot production

# Swap back if something goes wrong
az webapp deployment slot swap \
    --name myapp-prod \
    --resource-group myapp-rg \
    --slot production \
    --target-slot staging

We use this technique in all production projects. One online store after implementing slots eliminated nighttime downtime — caching and database connections are not reset during swap when configured correctly.

How to Connect a Custom Domain and SSL?

After deployment, you need to bind your own domain. Azure App Service supports free SSL certificates from Let's Encrypt or your own from Key Vault. The process:

1. In the Azure portal, add your custom domain under the 'Custom domains' section.
2. Bind an SSL certificate (free or your own).
3. Specify the TLS/SSL binding for your domain.

Tip: use Azure Key Vault to store certificates — it's more secure than storing them in files.

Autoscaling: When Your Site Grows

The App Service Plan can automatically scale based on metrics. Configuration via CLI:

az monitor autoscale create \
 --resource-group myapp-rg \
 --resource myapp-plan \
 --resource-type Microsoft.Web/serverfarms \
 --name autoscale-rule \
 --min-count 2 \
 --max-count 10 \
 --count 2
az monitor autoscale rule create \
 --autoscale-name autoscale-rule \
 --resource-group myapp-rg \
 --scale out 2 \
 --condition "Percentage CPU > 75 avg 5m"

With proper autoscaling, a project can handle a 10x traffic spike without manual intervention. For example, our client — an online booking service — handled Black Friday with a 15x traffic surge while remaining responsive.

Deployment Method Comparison

GitHub Actions is 10x faster than manual FTP deployment and completely eliminates human error. With FTP, you spend 10 minutes uploading files; with CI/CD, it's 2 seconds per commit.

Typical Mistakes and Solutions

• 502 Bad Gateway: most often due to version mismatch between PHP/Node.js runtime and the Azure environment. Check az webapp config show and compare with your local setup.
• Environment variables not picked up: set them via az webapp config appsettings set, not by including a .env file in the archive.
• SSL certificate not working: ensure you bind the certificate in the Azure portal after adding it.

What's Included in a Turnkey Setup

When you entrust us with setting up your Azure App Service deployment, we:

• Analyze your project and select the optimal plan (we've worked with Azure for over 5 years and configured deployments for 50+ projects)
• Set up CI/CD via GitHub Actions or Azure DevOps
• Connect Deployment Slots with automated swap and zero-downtime
• Bind a custom domain and SSL certificate
• Configure autoscaling and monitoring
• Document the entire configuration

We guarantee that after setup, you'll be able to deploy with a single button click. Contact us to discuss your project — we'll assess it within 1 day and propose the best solution.

Implementation Timeline

Don't delay — request a consultation, and we'll make your deployment reliable and automated.