Tag Manager Server Container Hosting
A server container needs somewhere to actually run
A client-side GTM container is just JavaScript served to the browser — no hosting decision required. A server-side GTM (sGTM) container is a real Node.js application that must run somewhere continuously (or on-demand), receive HTTP traffic on a custom domain, and scale with your site's traffic. Google officially supports two hosting paths: automatic provisioning on Google Cloud Run, and manual App Engine deployment for teams wanting more infrastructure control. Everything else (custom containers on Kubernetes, Fargate, etc.) is possible since it's just a container image, but unsupported by Google directly.
Cloud Run automatic provisioning: the default choice
From the GTM server container setup flow, choosing 'automatically provision' spins up a Cloud Run service, a load balancer, and the necessary IAM roles with minimal manual configuration — you provide a GCP project and billing account, and Google handles scaling, container updates, and most operational concerns. This is the right default for the overwhelming majority of implementations: it scales to zero when idle (reducing cost for low-traffic sites) and scales up automatically under load without capacity planning.
# Manual deployment path (when not using GTM's auto-provisioning UI),
# useful for teams managing infra as code via Terraform/CI pipelines.
gcloud run deploy sgtm-container \
--image=gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
--platform=managed \
--region=us-central1 \
--allow-unauthenticated \
--set-env-vars="CONTAINER_CONFIG=<your_container_config_string>" \
--min-instances=1 \
--max-instances=10Custom domains are not optional in practice
Running sGTM on the default *.run.app Cloud Run URL works technically, but defeats much of the purpose: a visibly third-party domain is easy for ad blockers and browser privacy features to fingerprint and block, exactly the problem server-side tagging exists to route around. Mapping a first-party subdomain (e.g. metrics.yourdomain.com) to the Cloud Run service via Cloud Load Balancing and a managed SSL certificate is a required step for sGTM to deliver its core benefit — first-party-looking endpoints that aren't trivially blocklisted.
Cloud Run vs. App Engine for sGTM
| Dimension | Cloud Run (auto-provisioned) | App Engine (manual) |
|---|---|---|
| Setup complexity | Low — handled by GTM's provisioning wizard | Higher — manual GCP configuration |
| Scale-to-zero | Yes, reduces idle cost | Limited; App Engine instances behave differently |
| Infra-as-code friendliness | Good, works well with Terraform/CI | Possible but less common in modern setups |
| Google's current recommendation | Default/preferred path | Legacy-supported, still valid for existing setups |
min-instances=0 means a cold-start tax on the first request
min-instances to at least 1 trades a small continuous cost for consistently low latency.Billing is yours, not Google's
Unlike client-side GTM, which is free because the browser does the work, a server container runs on infrastructure you pay for directly via your GCP billing account — Cloud Run compute time, the load balancer, and egress. Costs are usually modest for small-to-medium sites but scale with request volume, so it's worth monitoring GCP billing alerts on the project rather than assuming server-side tagging is cost-neutral the way client-side GTM is.
What's Next?
Hosting is the infrastructure layer; once a server container is live and reachable on a first-party domain, the next decisions are about how Cloud Run itself should be tuned for cost, latency, and resilience as traffic grows.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.