15. Hosting Your Server Container

GCP, managed hosts, or your own servers — the real costs, the ops burden, and the trade-offs of each way to run a server GTM container.

Chapter 10 established that the server container is just an application image. This chapter is about the decision Google left you with: where it runs. Three paths exist — Google Cloud, a managed sGTM host, or your own infrastructure — and the right answer is a cost/control/operations triangle, not a universal best.

Know the workload first

Sizing decisions get easy once you know what the app actually does:

  • Stateless and CPU-light. Each request is: claim, parse, fire a few outbound HTTP calls, respond. No sessions, no disk. Horizontal scaling is trivial (Chapter 10), and modest instances go far.
  • Traffic follows events, not pageviews alone. Estimate requests/month ≈ pageviews + tracked events (+ script serving if you serve the container first-party, Chapter 11). An online store with 200k pageviews and rich ecommerce events might produce 600k–1M monthly requests.
  • Availability is the real constraint. Chapter 9's single-point-of-failure warning becomes a hosting requirement: if the container is down, every platform goes blind simultaneously. Production means redundancy (multiple instances or fast restart), TLS, monitoring, and a health endpoint wired into whatever supervises the process.
  • The preview server (one small always-on instance, Chapter 10) tags along in every scenario; it costs almost nothing but must exist.

Path 1: Google Cloud — the official default

The GTM console offers near-one-click provisioning into your GCP project — historically App Engine, now Cloud Run as the recommended target.

The cost reality is the famous catch. Google's production guidance has long recommended running multiple instances for availability (the classic App Engine recommendation was a minimum of ~3), which lands a typical production setup around $100–150+/month before traffic grows. Cloud Run is more cost-flexible — it can scale to zero — but scale-to-zero means cold starts, and a cold start on a tracking endpoint is dropped or delayed events at the exact moment a campaign spikes. Production Cloud Run setups keep minimum instances warm, which re-introduces a cost floor.

Take it when: you're already a GCP shop (the logs land in Cloud Logging, IAM is your IAM, Firestore for Chapter 14 lookups is next door), compliance wants a Google-supported reference path, or enterprise scale makes autoscaling economics work in your favor. The price: GCP literacy becomes part of your tracking stack, and region choice is now a data- residency decision you're making explicitly (EU traffic → EU region).

Path 2: managed sGTM hosting

An entire vendor category exists to undercut that cost floor: Stape (the giant, Chapter 16), Addingwell, Taggrs, and a steady tail of newer entrants. They run the same official image on their infrastructure, wrap it in a dashboard, and charge by request volume — entry tiers from free/€20-ish per month, an order of magnitude under the GCP floor.

Take it when: you want zero ops and fast time-to-live, volumes are small-to-mid, and the convenience layer (custom loaders, cookie tooling — Chapter 16) is worth renting. The price: a vendor inside your data path (a processor agreement and a trust decision — they terminate TLS for your tracking subdomain), per-request pricing that compounds at scale, DNS shapes that matter (Chapter 11: insist on the dedicated-IP / A-record option), and a soft lock-in via the convenience features themselves.

Path 3: your own infrastructure

The image is public; Docker is Docker:

docker run -d \
  -e CONTAINER_CONFIG=<token from the GTM console> \
  -e PREVIEW_SERVER_URL=https://debug.pulse.shop.example \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image       # tagging server
 
docker run -d \
  -e CONTAINER_CONFIG=<same token> \
  -e RUN_AS_PREVIEW_SERVER=true \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image       # preview server

Put a reverse proxy (Traefik, nginx, Caddy) in front for TLS and routing, point an A record at it — the Chapter 11 gold standard, free of charge — and a €10–20 VPS comfortably runs small-to-mid workloads, with several client stacks fitting on one box for an agency.

Take it when: you want full control of the data path and DNS, EU data locality on infrastructure you choose, agency economics (many containers, one host), or the durability-maximal Safari posture. The price is the honest one: you are now the SRE. Image updates, certificate renewals, monitoring, capacity, incident response at 2 a.m. — Google supports the container, not your deployment of it.

This third path's economics with the second path's convenience is exactly the gap our Pixel Logic Server productizes: dedicated per-client stacks (first-party edge + tagging + preview, Chapter 10's anatomy) on infrastructure we operate, provisioned and monitored from a dashboard. The point of these docs isn't to pretend the trade-offs away — it's that we've made them deliberately.

The triangle, tabulated

                    GCP (Cloud Run)     managed (Stape…)    self-hosted VPS
─────────────────   ─────────────────   ─────────────────   ─────────────────
cost floor /mo      ~$100–150 (warm     free–€50 entry,     €10–20 hardware,
                    instances)          grows w/ volume     your time on top
ops burden          medium (GCP         ~zero               full — you're
                    skills)                                 the SRE
data path           Google's cloud,     vendor in the       yours end to end
                    your project        middle
DNS / cookies       A records to        depends — demand    A records native;
(Ch. 11 lens)       your LB; clean      dedicated IPs       maximal posture
scaling             excellent, auto     theirs to worry     manual; plan
                                        about               headroom
support             Google path         vendor support      community + you
fits                GCP shops,          SMBs, fast starts,  agencies, EU data
                    enterprise scale    no-ops teams        control, volume

Operational notes that apply everywhere

  • Two tagging instances or a hard restart story. Whatever the host, a single instance with no supervision is a measurement outage waiting for a deploy.
  • Health checks: the image exposes a health endpoint — wire it into the load balancer / orchestrator probes rather than probing / (which a client might claim).
  • Keep the image fresh. CONTAINER_CONFIG refetching updates your container config automatically (Chapter 10) — it does not update the image. Schedule pulls; release notes occasionally matter (protocol and template-API changes).
  • Logs are your wire-layer. In production, the container's stdout (and your proxy's access log) replaces DevTools as the place you confirm events arrived — retention and searchability are part of the design, not an afterthought.
  • Region ≈ latency ≈ data residency. Place the container near your users for beacon round-trips, and know which jurisdiction it processes in — Chapter 17 makes that question legal, not just technical.

With the "where" settled, one vendor deserves its own chapter — partly because you'll meet it constantly, mostly because explaining what it sells is the best final exam this guide has for Chapters 9–14: Chapter 16 — How Stape Works.