{"id":8828,"date":"2026-08-17T20:33:00","date_gmt":"2026-08-17T18:33:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8828"},"modified":"2026-10-24T03:24:49","modified_gmt":"2026-10-24T01:24:49","slug":"server-side-gtm-on-gcp-cloud-run-architecture-auto-scaling-and-cost","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/server-side-gtm-on-gcp-cloud-run-architecture-auto-scaling-and-cost\/","title":{"rendered":"Server-Side GTM on GCP Cloud Run: Architecture, Auto-Scaling, and Cost Optimization"},"content":{"rendered":"

Server-side Google Tag Manager (ssGTM) receives measurement requests and sends configured events to selected destinations. Cloud Run supplies the container infrastructure and adjusts the instance count to demand. Reliable operation still depends on the tags, consent rules, resource settings and monitoring. A successful browser response alone does not prove delivery to every destination.<\/p>\n

Architecture before tuning<\/h2>\n

Google’s Cloud Run setup separates a preview server from the tagging server for live traffic. The official provisioning guide covers both. A manually created tagging service needs the actual CONTAINER_CONFIG<\/code> from GTM and the correct PREVIEW_SERVER_URL<\/code>; a fabricated Base64 string is not a working configuration. Public reachability, the custom domain and the web container’s transport settings also require verification.<\/p>\n

The published server container controls which clients claim requests and which tags run. GA4, Meta and TikTok forwarding require separate configuration and applicable consent controls. Cloud Run alone adds none of these integrations. The official image’s stable<\/code> tag can change; an update needs deployment and validation, rather than an assumption that running instances automatically refresh.<\/p>\n

\"ssGTM
ssGTM on Cloud Run: measure before scaling.<\/figcaption><\/figure>\n

Warm capacity and scaling limits<\/h2>\n

Minimum instances keep capacity warm and reduce startup delays. Additional instances during a surge, replacement instances and new revisions can still start cold. Neither a fixed startup duration nor a response time below 50 ms follows from setting the minimum to one. Google’s ssGTM guide recommends at least two instances to reduce outage risk; the appropriate capacity depends on availability requirements and measured traffic.<\/p>\n

Maximum instances constrain scaling but are not a hard spending cap. The limit can be exceeded temporarily, and revision-level limits differ from a service-wide limit. A low maximum can leave requests waiting or failing during a surge. Traffic limits, downstream quotas and a billing alert therefore belong in the operating plan. An alert does not itself stop spending.<\/p>\n

CPU, memory and concurrency<\/h2>\n

The ssGTM guide describes a starting configuration with one vCPU and about 0.5 GB of memory per instance, using CPU allocation outside active requests. The corresponding --no-cpu-throttling<\/code> setting selects instance-based billing: idle time is billed too. Available background CPU does not make an outbound request durable across shutdowns or guarantee successful vendor delivery.<\/p>\n

Concurrency limits simultaneous requests per instance. A value of 80 is a ceiling, not a promise that scaling starts only at request 81. CPU utilization and concurrency both influence scaling. Higher concurrency can improve utilization, but payload size, tag execution and slow destination APIs can increase memory use and latency. CPU and memory limits need measurement; there is no basis for declaring memory the first bottleneck in every 512 MiB deployment.<\/p>\n

A practical tuning cycle<\/h2>\n
    \n
  1. Inventory: deployed image, revision, billing mode, instance limits, CPU, memory and concurrency, with preview capacity recorded separately from live tagging capacity.<\/li>\n
  2. Controlled tests: representative payloads and tags, including a slow destination and a realistic traffic spike. Synthetic purchases belong outside production reporting.<\/li>\n
  3. Evaluation: high-percentile response times, error rate, CPU, memory, instance count and destination acknowledgements. An out-of-memory termination is an infrastructure failure to investigate, not an invisible analytics discrepancy.<\/li>\n
  4. Iteration: one changed constraint, a repeated test and a comparison of total cost, including logging, networking, preview service and any load balancer. Rollback requires an available, tested previous revision.<\/li>\n<\/ol>\n
    \n

    Questions and answers<\/h2>\n

    Is lower concurrency always cheaper?<\/h3>\n

    No. Lower concurrency distributes work across more instances and can improve response time, but can raise cost. Increasing memory may be the better choice for some workloads. Representative measurements decide the trade-off.<\/p>\n

    Can minimum instances be reduced overnight?<\/h3>\n

    A schedule can reduce standing capacity, but also reduces spare capacity for unexpected traffic or restarts. Time zones, failed schedule runs and the morning increase need monitoring. The decision follows an accepted latency and availability target, rather than a blanket distinction between conversions and other events.<\/p>\n

    Does a region change require browser changes?<\/h3>\n

    A new region requires another regional deployment. A stable custom domain behind an appropriate load balancer can preserve the browser endpoint while the backend changes. Region selection should consider audience latency, data-location requirements, connected services and current network pricing. One European region alone does not determine every destination’s processing location.<\/p>\n<\/div>\n

    \n

    Sources<\/h2>\n