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.

We regularly encounter a situation: "The site is not opening" at 3 a.m. — and it turns out that the VPS disk is full because nginx logs haven't been rotated for six months. Or the server went down under load on the day of an advertising campaign launch because the shared hosting had a limit of 50 concurrent connections. Setting up hosting and deployment is not about "where it's cheaper" but about what happens when something goes wrong. Our team helps avoid such incidents by designing infrastructure that accounts for real load patterns.

When to choose Vercel and Netlify?

Vercel is built for Next.js — deploy in one push, preview deployments for every PR, automatic CDN, Edge Functions, ISR without configuration. For frontend projects and JAMstack, it's the optimal choice: no operational overhead, time-to-deploy measured in minutes.

Real limitations: Vercel Serverless Functions run in us-east-1 by default (latency for Europe +80–100ms), Function timeout 300 seconds on Pro, Bandwidth 1TB/month on Pro. For heavy backend, you need workers or a separate server.

Netlify is closer to static sites and Edge Functions based on Deno Deploy. Build minutes are the main limitation on the free tier.

Why is Docker the foundation of predictable deployment?

"It works on my machine" — classic. Docker solves this through environment containerization. But a bad Dockerfile creates new problems.

A typical mistake: copying everything into the image without .dockerignore, resulting in an 800MB image instead of 80MB. node_modules inside the image weighs as much. Correct approach: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Final image: 180MB instead of 1.2GB. CI build time is reduced due to layer caching — if package.json hasn't changed, the layer with npm ci is taken from cache.

Docker Compose for local development and simple production scenarios: application + PostgreSQL + Redis in one configuration. For production on a single server, it's a perfectly viable option if there's no requirement for horizontal scaling.

More about containerization — Wikipedia: Docker.

How to set up Nginx as a reverse proxy?

Nginx in front of the application is standard for VPS and dedicated servers. Main functions: SSL termination, gzip, static files, rate limiting, upstream load balancing.

A configuration often done incorrectly: worker_processes auto — number of processes equals CPU count. worker_connections 1024 — that's 1024 per worker process. With 4 CPUs and 1024 connections = 4096 concurrent connections. For a high-traffic site, you need worker_connections 4096 and set keepalive_timeout 65.

For static assets with hash in the filename:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable tells the browser: don't revalidate this file even on hard refresh. This only works correctly with content-hashed filenames (which Vite/webpack do by default). Documentation — Wikipedia: Nginx.

AWS: flexibility and complexity

EC2 + Auto Scaling Group — classic for horizontal scaling. AMI with pre-installed application, Launch Template, ASG with min/desired/max instances, Application Load Balancer. When CPU > 70% for 3 minutes — scale out, when CPU < 30% for 15 minutes — scale in. Health check via ALB removes unhealthy instances from rotation.

ECS Fargate — containers without managing EC2. Deploy a Docker image, specify CPU/memory (512 CPU units = 0.5 vCPU, from 512MB memory), Fargate launches it. More expensive than Lambda, but no cold start and no timeout limitations. Suitable for long-running processes, WebSocket servers, heavy workers.

RDS for PostgreSQL with Multi-AZ: automatic failover in 1–2 minutes when primary fails. Read Replicas for scaling reads. RDS Proxy for connection pooling — Lambda functions cannot hold long-term connections, the proxy buffers this.

Kubernetes: when it is justified

K8s adds significant operational complexity. Justified when: multiple teams deploy independent services, fine-grained resource allocation per service is needed, canary deployments and blue/green without downtime are required.

AWS EKS, GKE, or managed k8s from Hetzner (cheaper). Helm charts for standard services. Horizontal Pod Autoscaler based on CPU and custom metrics (RPS via Prometheus).

For most startups and medium-sized projects, Kubernetes is overkill. ECS or Fly.io provide 80% of the capabilities with 20% of the operational complexity.

Monitoring and alerting

A server without monitoring is waiting for an incident. Minimal stack: Prometheus + Grafana (or Grafana Cloud for managed), alerting on disk > 80%, memory > 85%, CPU > 90% over 5 minutes, error rate > 1%. Uptime via Better Uptime or Upptime (self-hosted).

Logs: Loki + Grafana or CloudWatch Logs Insights. Structured JSON logs (winston, pino) are mandatory — otherwise, log searching becomes a pain.

What is included in hosting setup

• Audit of current infrastructure and load profiling
• Selection of target architecture (VPS, AWS, serverless, Kubernetes)
• Setting up CI/CD pipeline (GitHub Actions, GitLab CI) with automatic deployment
• IaC via Terraform or Pulumi (infrastructure as code)
• Configuration of Nginx, SSL certificates, HTTP/2, brotli
• Monitoring and alerting (Prometheus + Grafana, PagerDuty)
• Documentation of runbooks and team training

Additionally, contact us if you need migration from current hosting or integration with external services.

Work process

1. Audit of current infrastructure (2–5 days)
2. Selection of target architecture with load and budget justification (1–3 days)
3. Setting up CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 days)
4. IaC via Terraform or Pulumi (3–10 days)
5. Setting up monitoring and alerting (2–5 days)
6. Documentation of runbooks and team training (1–3 days)

Our experience — 7 years on the market, over 50 projects, guarantee of operability after deployment.

Timeline

• Basic deployment on VPS with Docker + Nginx + CI/CD: 1–2 weeks.
• Setting up AWS infrastructure with Auto Scaling, RDS, CDN: 3–6 weeks.
• Migration to EKS from scratch: 6–12 weeks.
• Setting up Vercel/Netlify for JAMstack: 3–5 days.

The cost is calculated individually depending on complexity and scope of work. Get a consultation — we'll evaluate your architecture in one day.