GTM Server-Side Hosting on Azure

Azure App Service provides a lower-friction setup path for GTM Server-Side than AWS ECS Fargate, according to GTM community practitioners including Simo Ahava, who described it as “the smoothest and the fastest” among the three major cloud providers.

The GTM Server-Side container image (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) runs unchanged on Azure with the same environment variables as a Cloud Run deployment. The Azure hosting layer wraps the same container.

App Service: The Primary Option

App Service is Azure’s managed platform for hosting web applications and containers. For GTM Server-Side, you deploy two App Service instances — one for the tagging server, one for the preview server — using Docker container configuration.

Required App Services

Tagging server — receives incoming hits and routes to vendor endpoints:

# App Service configuration
Name: gtm-tagging-server
Publish: Docker Container
Operating System: Linux
Region: westeurope  # or your preferred region

Container settings:
  Image Source: Docker Hub
  Image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
  Tag: stable

Application settings (environment variables):
  CONTAINER_CONFIG: [your GTM container config string]
  PREVIEW_SERVER_URL: https://gtm-preview.yourdomain.com

Preview server — the debug interface used during container development:

Name: gtm-preview-server
Container: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Application settings:
  CONTAINER_CONFIG: [same config string]
  RUN_AS_PREVIEW_SERVER: "true"

The preview server can run on a lower-cost tier since it only receives traffic from developers using GTM’s preview mode, not from production web traffic.

Service Plan Tiers

App Service pricing is tier-based, not consumption-based. You select a plan and pay for it regardless of actual usage:

Tier	Monthly cost	Best for
B1 (Basic)	~$13	Testing and development only
S1 (Standard)	~$69	Production — minimum viable
P1V3 (Premium)	~$124	Production with auto-scaling
P2V3 (Premium)	~$248	Higher traffic workloads

The B1 tier is underpowered for production — it has limited CPU and memory that causes timeouts under real traffic load. For production, start at S1.

The S1 tier at ~$69/month for a single instance is competitive with Cloud Run at comparable traffic volumes. Two instances (tagging + preview) at S1 comes to ~$138/month — reasonable for organizations already paying for Azure infrastructure.

The Premium tiers (P1V3 and above) enable auto-scaling, letting App Service add instances when traffic increases and scale down during quiet periods. For sites with significant traffic variation between peak and off-peak hours, auto-scaling on Premium can be more cost-efficient than paying for always-on capacity.

SSL and Custom Domains

Azure App Service has good managed SSL support for subdomain configurations. The process:

Add your custom domain in the App Service “Custom domains” settings
Create a CNAME record: gtm.yourdomain.com → [your-app-service].azurewebsites.net
Enable Azure’s managed certificate (free, auto-renewed)
Set the SSL binding to SNI SSL

One limitation: managed SSL certificates work straightforwardly for subdomains but require additional configuration for apex domains (the root domain without www). For a tagging server, you’re almost always using a subdomain, so this isn’t a practical constraint.

Deployment from Azure CLI

# Create resource group
az group create \
  --name gtm-server-side \
  --location westeurope

# Create App Service plan (Standard tier)
az appservice plan create \
  --name gtm-plan \
  --resource-group gtm-server-side \
  --is-linux \
  --sku S1

# Create tagging server app
az webapp create \
  --resource-group gtm-server-side \
  --plan gtm-plan \
  --name gtm-tagging-server \
  --deployment-container-image-name gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

# Set environment variables
az webapp config appsettings set \
  --resource-group gtm-server-side \
  --name gtm-tagging-server \
  --settings \
    CONTAINER_CONFIG="[your-container-config]" \
    PREVIEW_SERVER_URL="https://gtm-preview.yourdomain.com"

# Enable continuous deployment from Docker Hub
az webapp config container set \
  --name gtm-tagging-server \
  --resource-group gtm-server-side \
  --docker-custom-image-name gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --enable-cd true

The --enable-cd true flag configures a webhook so the container updates automatically when Google publishes a new stable image — equivalent to Cloud Run’s automatic image updates.

Container Apps: The Cloud Run-Like Alternative

Azure Container Apps is Azure’s serverless container platform — closer to Cloud Run’s execution model than App Service. It scales based on HTTP traffic (including scale-to-zero), with consumption-based pricing.

For GTM Server-Side, Container Apps offers a more Cloud Run-like experience:

Scales automatically based on incoming request volume
Scales to zero during no-traffic periods (though this means cold starts — use minimum replicas to avoid lost events)
Per-request pricing rather than fixed tier costs

The configuration follows the same pattern — same Docker image, same environment variables — just deployed through the Container Apps resource type rather than App Service.

Container Apps is a better fit than App Service if:

Your traffic has significant variation and you want consumption-based pricing
You prefer the serverless mental model over managed plans
You want to avoid paying for idle capacity on low-traffic sites

App Service is a better fit if:

You want predictable monthly costs regardless of traffic variation
Your organization already uses App Service for other workloads and prefers consistency
You’re more familiar with the App Service configuration model

Azure Functions Doesn’t Work

Like AWS Lambda, Azure Functions is designed for short-lived, event-driven workloads. The GTM Server-Side image runs a persistent Node.js HTTP server — a model incompatible with Functions’ invocation architecture.

Don’t try to run the tagging server container through Functions. The persistent HTTP server won’t start correctly in the Functions execution environment, and even if it did, Functions has execution time limits (10 minutes on Consumption plan, 60 minutes on Premium) that don’t affect a typical tagging server but create an unnecessary constraint.

Multi-Region on Azure

Azure’s multi-region deployment model uses Traffic Manager or Azure Front Door for global routing:

Deploy App Service instances in each target region (e.g., westeurope and eastus)
Create an App Service plan in each region
Use Azure Traffic Manager (DNS-based routing) or Azure Front Door (anycast CDN routing) to direct users to the nearest region

Azure Front Door is the more capable option — it operates as a global CDN with built-in WAF, DDoS protection, and routing intelligence. For a GTM Server-Side deployment that also needs geo-routing and performance optimization, Front Door adds value beyond just traffic distribution.

Traffic Manager is simpler and cheaper for pure geo-routing without CDN capabilities.

The Decision Point

Choose Azure App Service when the organization already runs on Azure: the team knows the platform, billing goes through existing Azure accounts, and adding a GCP account creates overhead. The technical capability is comparable to Cloud Run; the practical friction differs.

For organizations evaluating Azure specifically for GTM Server-Side hosting without existing Azure infrastructure, Cloud Run or a managed provider like Stape is a simpler starting point.