Short answer, because this decision eats more agency hours than it deserves: if you spend under about $5,000 a month on ads, host your server-side GTM container on a managed platform like Stape — roughly $20/month for 500,000 requests, set up in an afternoon. Move to Google Cloud Run only when data residency, compliance, or contractual control forces the container into your own cloud account, because Cloud Run's realistic production floor is $90-135/month in compute before you serve a single spike. Self-hosting on your own Docker box is almost never worth it in 2026.
But price is the least interesting part of this decision, and it's the only part most comparison posts cover. The thing that actually determines whether your server-side setup earns its money is a Safari cookie rule that a default Cloud Run deployment quietly fails. More on that below, because we've now found it broken on three client accounts that were all paying for "server-side tracking" and getting 7-day cookies.
What you're actually paying for when you host sGTM
A server-side GTM container is a Node.js process in a Docker image. It sits on a subdomain of your own site, receives tracking hits from the browser, and forwards them server-to-server to Meta, Google Ads, TikTok, GA4, and anywhere else you route them.
That's it. There's no premium version of the container. Google publishes the same image to everyone, so the tracking quality is identical whether you pay $20 or $200 — what you're buying is operational time, uptime, and how the subdomain resolves.
Why bother at all? Ad blockers now strip client-side tags from over 40% of sessions in some markets, and browser-level restrictions keep tightening. We covered the click-ID side of that in the iOS 26 click-ID stripping fix, and the consent side in why GA4 conversions dropped in 2026. Server-side collection is the structural fix for both.
What Google Cloud Run really costs
This is where people get surprised. The Cloud Run marketing story is "pay per request, scale to zero" — and that story does not apply to sGTM.
Google's own Cloud Run setup guide says a zero-minimum-instance configuration is unsuitable for production, because the container scaling to zero means cold starts and dropped hits. Their recommendation is a minimum of two instances to survive a single instance failing.
Run the math at the standard config (1 vCPU, 512 MB, CPU always allocated):
- ~$45/month per instance, and Google wants two → ~$90/month floor
- Plus a preview server — exactly one always-on instance whose only job is making debug mode work → call it ~$90-135/month before anything happens
- Plus egress fees, Cloud Logging charges, and autoscaling during traffic peaks
So the honest Cloud Run number for a normal advertiser is north of $100/month, permanently, whether you get 5,000 hits or 500,000. Autoscaling 2-10 instances handles roughly 35-350 requests per second depending on how heavy your tags are, so headroom isn't the problem. Idle cost is.
What the managed hosts really cost
Managed hosts run the identical container and charge by request volume:
- Stape — free up to 10,000 requests/month, then about $20/month for 500,000, $100/month for 5 million, and $200/month for 20 million. 20% off annually. Market leader, biggest add-on ecosystem.
- TAGGRS — around €22-26/month for 750,000 requests. EU data centers, which matters if your legal team asks where the hits land.
- Addingwell — from €90/month for 1 million requests, with honest overage at €2.30 per additional 100,000. Now owned by Didomi, so it pairs naturally with a consent stack.
Notice that Stape's $20 tier costs less than one fifth of Cloud Run's idle floor and covers 500,000 requests. For the large majority of accounts we audit, the managed host is both cheaper and better. The DIY-vs-managed argument only flips at genuinely high volume or under a compliance mandate.
And if you're pricing a true self-host — your own VM, your own Docker, your own SSL — budget $50-150/month in infrastructure plus 50-120 hours of engineer time to build and harden it. At normal specialist rates that's a five-figure setup to save $80 a month. We don't recommend it, and we run our own infrastructure for plenty of other things.
The request-billing trap that blows up your first invoice
Here's the mistake we see most, and it has nothing to do with which host you pick.
Request quotas do not count conversions. They count hits. That includes gtm.js and gtag.js script loads served through your tagging subdomain, and it includes bots, crawlers, and every preview/debug session you run while building.
So an agency models a client at "we only do 3,000 conversions a month, the 500K tier is enormous" — and then the site does 120,000 monthly pageviews at three container hits each, plus a crawler wave, and the tier is gone by the middle of month one.
Size it properly instead: monthly pageviews × hits per page, then add 25-30% for bots and debugging. That's the number your plan needs to cover. It's a two-minute calculation that prevents an awkward client email.
The Safari cookie rule that matters more than the price
Now the part almost nobody prices in.
The main technical prize of server-side tagging is cookie lifetime. A cookie set server-side, over HTTP, from a properly configured first-party subdomain can live up to 400 days — the EU regulatory cap — instead of the 7 days Safari's ITP gives a JavaScript-set cookie.
But since Safari 16.4, you only get that long lifetime if your tagging subdomain's IP address shares its first 16 bits with your main domain's IP. This is Safari's IP-alignment check, and it exists precisely to stop people from renting a tracking endpoint and calling it first-party.
A default Cloud Run deployment fails that test. Your container is healthy, preview mode is green, events land in Meta and GA4, and Safari is still quietly capping your cookie at 7 days. Every returning visitor past day 8 looks like a brand-new user. Your paid channels lose credit for conversions they earned, and your reported new-vs-returning split drifts in a way that looks like a seasonality story rather than a bug.
This is the single most-missed item in server-side audits we take over. If you take one thing from this post: after you deploy, open the live site in Safari and check the actual cookie expiry. Months out, or 7 days? That one check is worth more than every dollar of hosting comparison above it.
Managed hosts sell IP alignment (or a CDN configuration that achieves it) as a headline feature, which is a large part of why the $20 option often outperforms the $100 one in practice.
So which one should you run?
The decision we walk clients through:
- Under ~$5k/month ad spend, no compliance mandate → managed host. Stape unless you need EU residency, in which case TAGGRS or Addingwell. Verify IP alignment and move on with your life.
- Data must stay in infrastructure you control, or a contract or legal team says so → Cloud Run, budgeted honestly at $100+/month, with IP alignment solved deliberately rather than assumed.
- High volume where per-request pricing overtakes flat compute → model both at your real request count. The crossover is higher than most people guess.
- Self-hosted Docker on your own VM → only if you already run production infrastructure and the ops cost is genuinely near zero for you. Otherwise it's the expensive option wearing a cheap costume.
One thing worth being clear about: hosting choice does not change your event match quality, your deduplication, or your attribution accuracy. Those come from what you route and how you enrich it. We broke that down in the 2026 Meta Conversions API guide, and the reporting side of it in why Google Ads and GA4 disagree.
Server-side GTM also isn't the whole attribution answer — it's the pipe. Knowing which channel actually drove the revenue is a separate job, which is why we still run Hyros on top for clients who need revenue truth rather than platform-reported truth. That's covered in our Hyros attribution guide for agencies.
The deploy order that avoids a broken month
- Estimate requests from pageviews, not conversions, and add margin for bots and preview sessions.
- Pick the host by constraint — compliance, residency, ops capacity — then let price break the tie.
- Stand up the tagging subdomain and confirm IP alignment before you route a single destination.
- Route one platform at a time. Verify events, parameters, and deduplication end to end before adding the next.
- Check the cookie expiry in real Safari on the live site. Not in preview mode, not in Chrome.
- Re-check after every DNS or hosting change, because that's exactly when alignment silently breaks.
Get a free automation audit
Most "our server-side tracking isn't working" calls we take aren't hosting problems. They're a 7-day cookie nobody checked, a plan sized against conversions instead of pageviews, or a container faithfully forwarding events that were already wrong client-side.
If you're paying for server-side tracking and can't confidently say what your Safari cookie lifetime is, book a free automation audit. We'll check your container config, your subdomain alignment, your request headroom, and what your tags are actually sending — then tell you whether you're on the right host or quietly overpaying for a setup that isn't doing its main job.