Dilshat Rakhimov
July 2026 · 9 min read
Every sGTM pricing post quotes a monthly figure, and almost none of them show the arithmetic. The gap between the two is where the interesting information lives - the preview server nobody counts, the egress line, the BigQuery streaming that appears in month three, and the fact that the compute is the cheapest thing in the entire arrangement.
Everything below is built from published rates and each vendor's own sizing guidance, with the working shown, so you can re-run it against your own numbers rather than trusting mine. Where I'm modelling rather than reporting, I say so.
First, what you're actually renting
Server-side GTM is a Node application distributed as a Docker image. Google publishes the reference:
with CONTAINER_CONFIG for the container config string and PREVIEW_SERVER_URL pointing at a separate preview instance.¹
That one fact explains the entire pricing landscape. You are not buying a product from Google - the container is free and lives in your normal GTM account. You are renting somewhere to run a container image, and every provider below is charging you for compute plus some amount of convenience. Which is also why the price range is so wide: a managed host and a €5 VPS run the identical binary.
Google Cloud Run: Google's own arithmetic
I'll be explicit that I have not run sGTM on Cloud Run in production, so this section is Google's published figures rather than my invoice.
From Google's Cloud Run setup guide:²
- Each server is a Cloud Run instance with 1 vCPU and 0.5 GB memory, using the CPU always allocated pricing model
- "In this Cloud Run configuration, each server costs approximately $45/month (USD)."
- "We recommend running a minimum of 2 instances to reduce the risk of data loss in case of a server outage."
- "We expect that autoscaling 2-10 servers will handle 35-350 requests per second, though the performance will vary with the number of tags."
And from the manual setup guide: *"You must deploy exactly 1 preview server. Do not configure autoscaling beyond 1 instance."*¹
Do the arithmetic Google is implying and the production floor is 2 tagging instances plus 1 preview instance ≈ $135/month, before a single byte of egress, before BigQuery, before any traffic spike. The commonly-cited "$120/month Cloud Run floor" is the same estimate with slightly friendlier rounding; either way, the number is three instances, not one.
The reason it isn't cheaper is CPU always allocated. That's Google's recommendation and it's the right one - a tagging server that scales to zero drops hits on the cold start, and a dropped hit is a conversion you never see. You are paying for idle capacity on purpose. Anyone quoting $10-25/month for Cloud Run sGTM is quoting a request-billed, scale-to-zero configuration that Google's own guide advises against for production.
Stape: the published price list
Stape's list prices, as of July 2026:³
| Plan | Monthly | Annual | Requests/month |
|---|---|---|---|
| Free | $0 | — | 10K |
| Pro | $17 | $200/yr | 500K |
| Business | $83 | $1,000/yr | 5M |
| Enterprise | $167 | $2,000/yr | 20M |
| Custom | contact | — | unlimited |
Two details in the small print that change the comparison more than the headline price does.
One container equals one site. Each site needs its own subscription; you can't spread a Business plan across five clients' containers. If you're an agency, multiply.
Requests means incoming requests only. One page view that fans out to GA4, Meta CAPI and TikTok Events API inside the container is one billable request on Stape and three outbound calls. On your own infrastructure it's one inbound request and three outbound calls you pay egress on. This is the detail that makes Stape's request quotas look tighter than they are, and it's why "500K requests" goes considerably further than "500K events" would.
There's also an auto-upgrade toggle that moves you up a tier when you cross the limit.³ Leave it on and you won't lose data; leave it on without an alert and you'll find out about the tier change on the invoice. Set a billing notification either way.
And the plan is not the bill. The tier above buys the container. Gateway and Signals add-ons - dedicated gateways for Meta CAPI, TikTok eAPI, Snapchat CAPI - are priced separately, from around $10 per pixel per month, and they stack. That's the line I actually watch on my own account: the container tier is stable and predictable, and the add-ons are what creep, because each one attaches to a pixel and nobody decommissions a pixel. A container plan plus three gateways is a different number from the one on the pricing page, and it's the number an agency running several brands should be modelling.
Self-hosted on a VPS
This is where the arithmetic gets uncomfortable for everyone else, so it's worth being careful about what it does and doesn't include.
Start with Google's own sizing, since it's the only vendor-neutral capacity figure published: one instance is 1 vCPU and 0.5 GB memory, and 2-10 of them handle 35-350 requests per second.² Call it roughly 35 rps per vCPU with a moderate tag load. That's on the order of 90 million requests a month from a single core - two orders of magnitude past Stape's Business tier.
Which means the box is small, and small boxes are cheap. Mine is a VPS at a Kazakhstani provider billed quarterly at 20,000 KZT - about 6,700 KZT a month, roughly $14 at the ~475 KZT/USD rate of late July 2026.⁷ That box also serves other things, so treat it as a ceiling on what the tagging server costs rather than a clean per-service figure - which is itself the point: at this size you don't provision a machine per service, you put the container on a box you already run.
European equivalents land in the same band: a 2 vCPU / 4 GB shared-vCPU machine at Hetzner lists in single-digit euros, though they applied a cloud price adjustment in June 2026, so check the current figure rather than the one in older tutorials.⁸
So the honest comparison, for a workload Stape would bill at $83:
| Monthly | |
|---|---|
| Cloud Run, Google's recommended production config | ~$135 |
| Stape Business, before add-ons | $83 |
| Self-hosted VPS, shared with other services | ~$14 |
And the honest caveat, which is the entire reason the cheap column isn't obviously correct: that VPS number buys you compute and nothing else. It does not include TLS on a first-party subdomain, a monitoring setup that tells you when the container stopped answering, periodic restarts to pick up runtime updates (Google recommends them, and a container untouched for a year is running a year-old runtime¹), or the person who does all of that. Those aren't hypothetical - they're the actual work, and they're why the €5 box does not beat the $83 plan for most teams. See the last section.
Cloudflare: the answer changed in April 2026
Most write-ups still say Cloudflare can't host sGTM. That was true, and it isn't any more, so it's worth being precise about what changed.
Workers still can't host it. Workers is a V8 isolate runtime - it runs JavaScript, not container images. sGTM ships as a Docker image running Node. A Worker in front of your tagging server is genuinely useful: a first-party endpoint, a custom loader, a place to rewrite requests before they hit the container. It is a proxy, not a host.
Cloudflare Containers can. Containers and the Sandbox SDK went generally available on 13 April 2026 on the Workers Paid plan, and run any Docker image, including from Docker Hub.⁴ There's no technical reason the sGTM image won't run there.
The published rates, on Workers Paid at $5/month:⁵
| Resource | Included | Overage |
|---|---|---|
| Memory | 25 GiB-hours/mo | $0.0000025 / GiB-second |
| CPU | 375 vCPU-minutes/mo | $0.000020 / vCPU-second |
| Disk | 200 GB-hours/mo | $0.00000007 / GB-second |
Billing is per 10ms of active runtime, CPU is billed on active CPU only, and containers scale to zero.
The billing model is the thing to understand here. CPU billed on active cycles is very cheap for a tagging server, which spends most of its life waiting on I/O rather than computing. Memory and disk bill while the instance is awake, and for a tagging server you want it awake permanently - scale-to-zero means cold starts, and cold starts mean dropped hits, the same reason Cloud Run needs CPU always allocated.
So model an always-awake basic instance (1/4 vCPU, 1 GiB memory, 4 GB disk) over a 730-hour month:
- Memory: 730 GiB-hours − 25 included = 705 GiB-hours ≈ $6.35
- Disk: 2,920 GB-hours − 200 included = 2,720 GB-hours ≈ $0.69
- CPU: active only, and low for I/O-bound work
- Plus the $5 Workers Paid plan
That lands somewhere in the low tens of dollars for a permanently-awake instance, against roughly $45 for the equivalent Cloud Run instance. That is list-price arithmetic, not an invoice - I've run Workers in front of a tagging pipeline, but not sGTM on Cloudflare Containers in production. Check it against Cloudflare's own calculator before you plan a migration around it, and be aware you'd be early: there's very little operational experience published on this configuration yet.
The line items nobody quotes
This is the part that turns a $17 estimate into a $60 bill.
The preview server. It's a second instance, it runs continuously, and it is absent from roughly every cost comparison I've read. On Cloud Run that's a third of your floor.
Egress. Every outbound call to Meta, TikTok, Google and Snapchat is billed bandwidth on infrastructure you own. It's small per event and it is not small at 5M events.
BigQuery streaming. Streaming raw event data out of the server container into BigQuery is the single most common "why did the bill triple" story I hear. It's a separate product with separate billing, and nobody adds it to the sGTM line when they budget.
Bot traffic. Your tagging endpoint is a public first-party URL. Scanners, scrapers and junk traffic hit it, and on a request-billed plan you pay for every one. Check what share of your inbound requests are real before you size a plan.
Requests versus events. Already covered above, and worth re-reading whichever pricing page you're on - "requests", "events" and "hits" mean three different things across three vendors, and the difference can be an order of magnitude.
Domain, TLS, DNS. Trivial money, non-trivial to forget. A first-party subdomain with a valid certificate is a hard requirement, not an optimisation.
Maintenance. The image updates. The container config changes when the GTM container changes. Someone owns the restarts and the monitoring, and if nobody does, you'll find out during a campaign.
The engineer. Here's the real number. At any consulting or in-house rate you like, one day of an analytics engineer costs more than a year of Stape Pro. Hosting is not where sGTM is expensive. Choosing a host on price alone and then spending three days debugging your own Docker setup is a straightforwardly bad trade, and it's the most common mistake I see in this decision.
How to choose
- Under ~500K requests/month, no dedicated infra team: managed. The price difference against self-hosting is smaller than one afternoon of your time.
- Millions of requests, an existing GCP footprint, someone who already owns Cloud Run: Cloud Run, with the three-instance floor budgeted honestly.
- Multiple containers across multiple clients or brands: self-hosted starts winning, because the per-container pricing on managed platforms multiplies and your box doesn't.
- Strict data-residency requirements: this decides it before price does. Check where the provider actually terminates requests, not where its head office is.
- Any of the above, if sGTM isn't already paying for itself: don't. The published rule of thumb - that sGTM's complexity earns out above roughly $5,000/month in paid media⁶ - is about right in my experience. Below that, fix your client-side tagging first.
The takeaway
The compute is not the expensive part. Cloud Run's floor is around $135/month by Google's own numbers, Stape's mid-tier is $83, a VPS is less than either, and the difference between all three is roughly one hour of engineering time per month.
What's actually expensive is a tagging server nobody owns: unrestarted, unmonitored, silently dropping hits during your highest-traffic week, with a BigQuery export nobody remembered to budget. Pick the host that means the fewest hours of your team's attention, budget the preview server and the egress, and spend the argument you saved on the container configuration instead.
Dilshat Rakhimov
Growth Analytics & Digital Architecture
¹ Manually set up server-side tagging — Google for Developers
² Set up server-side tagging on Cloud Run — Google for Developers
³ Stape pricing
⁴ Containers and Sandboxes are now generally available — Cloudflare changelog, 13 April 2026
⁵ Cloudflare Containers pricing
⁶ GTM server-side tagging — ceaksan.com
⁷ USD/KZT reference rate, late July 2026 — exchangerates.org.uk
⁸ Hetzner price adjustment, 15 June 2026 — Hetzner Docs