Cloud
Cloud stands up the Google Cloud infrastructure that hosts your GTM server container: a GCP project with the required APIs enabled, two Cloud Run services (preview + tagging) running Google's official gtm-cloud-image:stable, and a custom domain attached to the tagging service so first-party traffic flows through your subdomain instead of *.run.app.
Decisions made here persist across cascades — Cloud Run bindings and the custom-domain config are explicitly excluded from the Tier 2 reset that fires on Audit changes. Once Cloud Run is deployed and DNS is propagated, you typically don't redo this stage even if you change other parts of the build.
Stage path: GCP Project → Tagging Services → Tagging Endpoint
Region Selection
Both Cloud Run services run in a single GCP region. Default is us-central1. Pick a region close to where most of your traffic originates — every event has to travel to the tagging service before reaching GA4, so latency is a real cost.
- Both services must be in the same region. Cloud Run domain mappings are region-scoped; the custom domain attaches to a specific service in a specific region.
- Region change requires re-deployment. Cloud Run services can't be moved between regions; switching means recreating the services. The tagging endpoint's custom-domain mapping needs to be recreated too.
- Cost is roughly region-neutral. A few cents per month delta between regions; pick on latency, not price.
Service Profile
Each of the two services has a different scaling profile baked in by the Create flow. These are intentional, not arbitrary defaults.
| Service | Min instances | Max instances | Why |
|---|---|---|---|
| Preview | 0 (default) | 1 | GTM Preview / Tag Assistant sessions are single-user. Capping at 1 ensures preview requests land on the same instance for session continuity. |
| Tagging | 1 (always-warm) | unlimited | Production traffic. Always-warm avoids 200–800ms cold-start latency on the first request after a quiet period — bad for tags that fire on user pageloads. |
Cost Framing
Cloud Run is billed per 100ms of active instance time, with a generous free tier. Server-side tagging is one of the cheapest things you can run on Cloud Run.
- Free tier: ~2M requests/month + ~360k vCPU-seconds + ~180k GiB-seconds. Most small/medium sites stay inside the free tier.
- Above free tier: typical $5–$50/month at moderate traffic, driven mostly by min-instances on the tagging service (always-warm = always paying for that one instance).
- Cost spike sources: very high event volume (DDoS or runaway integrations), misconfigured routing that sends every event multiple times, or accidentally publishing the preview service to traffic.
Set up monitoring (covered in Monitoring) to alert on traffic anomalies before they become billing surprises. Cloud Run has built-in cost controls; use them.
Why These Bindings Persist
gcp_project, cloudrun_preview, cloudrun_tagging, and the profile_config custom-domain fields are explicitly excluded from the Tier 2 cascade that fires on Audit primary changes. The reasoning: Cloud Run services aren't derived from GA4/GTM primaries, and re-deploying every time someone tweaks an upstream binding would be expensive and pointless. Only check_run rows for this stage clear on cascade — re-running Validate after a cascade is a quick fix, no redeployment needed.