Server-side GTM hosting: Cloud Run vs Stape vs self-hosted

Short answer: if you're spending under roughly £5k/month on ads, a managed host (Stape, Addingwell, TAGGRS) is the right call — it costs less than Cloud Run's idle bill and takes an afternoon instead of a week. Above that, or if your legal team cares who holds the data, run it on Cloud Run yourself. Self-hosting on your own Docker infrastructure is supported by Google but only pays off if you already run Kubernetes and have someone who'll own it.

That's the whole recommendation. The rest of this post is why, what it actually costs, and the part that gets left out of every comparison written by someone who sells one of these.

What you're actually paying for

A server-side GTM container is a Node.js process in a Docker image that receives tracking hits from the browser and forwards them server-to-server to Google, Meta and everyone else. Google publishes the image and the setup docs; where it runs is your choice.

Three things drive the cost, and only one of them is the software:

• Always-on compute. A tagging server can't cold-start — a request that arrives while the container is booting is a lost conversion. So you pay for idle capacity, not usage.
• A first-party subdomain. Google's documentation is explicit that your tagging server and your website "have to run on the same domain" for the first-party benefits to apply. A run.app URL is third-party and gets treated as such.
• A separate preview server. This is the line item people forget. Google's docs: "You must deploy exactly 1 preview server. Do not configure autoscaling beyond 1 instance." It's a second always-on instance that exists purely so debug mode works.

The three options, priced

Managed hosts (verified July 2026): Stape runs a free tier at 10K requests/month, then $20/month for 500K and $100/month for 5M. TAGGRS starts around €22–26/month for 750K. Addingwell — now owned by Didomi — starts at €90/month for 1M requests, with genuine overage billing at €2.30 per additional 100K.

That last difference matters more than the headline price. Stape and TAGGRS don't bill overage — they stop. Stape pauses the container at 110% of quota, at which point it drops all requests as though it were disabled; Business and Enterprise plans get one 30-day grace period, Pro doesn't. TAGGRS puts it plainly: exceed the limit and "the data flowing through TAGGRS from that point on can no longer be sent." If you have a seasonal spike, a cheap plan doesn't degrade — it silently deletes your peak trading week.

Cloud Run: Google's own setup guide states each server "costs approximately $45/month (USD)" at 1 vCPU and 0.5GB with CPU always allocated. Run the recommended two, add the mandatory preview server, and you're at roughly $145/month before load balancing and egress — neither of which Google includes in that figure. There's no free-tier rescue here: always-allocated CPU burns through the monthly allowance in days.

Google's own documentation contradicts itself

Here's something worth knowing before you size your cluster. Google publishes two different minimums.

The Cloud Run setup guide, updated 12 May 2026, says: "We recommend running a minimum of 2 instances" and that "autoscaling 2-10 servers will handle 35-350 requests per second."

The server-side tagging fundamentals course, last updated 9 January 2026, still says "a minimum of 3 instances… autoscaling from a minimum of 3 to a maximum of 6" and quotes 50–200 requests per second.

We size against the newer guide and scale on observed traffic. But the honest position is that Google has left two live recommendations in place, and anyone quoting either one at you with confidence hasn't checked the other.

The ROI question nobody answers honestly

Every server-side pitch leans on a number: recovers 20–40% of lost conversions, improves match rates, beats ad-blockers. We went looking for the source of those numbers.

There isn't one. As of July 2026, no independent, methodologically transparent study quantifying conversion recovery from server-side tagging has been published. Everything traces back to one of two places:

1. A vendor selling server-side tagging. The widely shared "2026 Server-Side Tracking Benchmark Report" is published by a company selling the service, aggregates third-party figures with no stated sample size or confidence intervals, and has never been independently audited.
2. The ad platform whose product benefits. Meta's frequently quoted 17.8% lower cost per result is Meta's own figure, unaudited, with no breakdown by vertical, region or advertiser size.

The genuinely independent academic work — SST-Guard (arXiv 2604.27497, April 2026) and the PETS 2024 paper on server-side tracking — measures how prevalent and detectable server-side tracking is, not what it recovers. SST-Guard found server-side Google Analytics on 4.02% of the top 10,000 sites. Neither paper measures conversion lift, because that's extremely hard to measure without a controlled holdout that no advertiser wants to run.

This does not mean server-side tagging doesn't work. It means the number in the pitch deck is not evidence, and you should be suspicious of anyone — including us — who quotes a precise recovery percentage at you. The defensible case for server-side is mechanical, not statistical: first-party cookies set server-side survive ITP's 7-day cap, requests to your own subdomain aren't on filter lists, and you control what leaves your infrastructure. Those are architectural facts. The percentage they're worth to your business is something you measure after, not before.

Consent doesn't get simpler, it moves

A common misreading: that moving tags server-side reduces your consent obligations. It does the opposite of what people expect in one specific way.

Google's server-side consent documentation is clear that "you only need to set up consent mode in the web container" — consent state travels with the hit as request parameters, and Google's own server tags respect it. Fine. But two things follow that catch people out:

• Google Ads Remarketing does not support URL passthrough server-side. Ads Conversions and Floodlight both require the Conversion Linker tag present in the server container.
• Non-Google tags are entirely your problem. Meta CAPI, TikTok Events API and the rest are not covered by Google's consent architecture. If you forward a hit to Meta from your server, nothing in the platform stops you doing that without consent. A server container makes it easier to leak data, not harder, because the browser-level blocking everyone relies on no longer applies.

That's the compliance trade the vendor pages skip: server-side tagging is a first-party power tool, and consent enforcement becomes something you implement deliberately rather than something the browser does for you.

When not to do this

Server-side tagging is genuinely oversold to businesses that don't need it. Skip it, for now, if:

• Your client-side tracking is broken. Server-side won't fix a mis-fired purchase event; it'll forward the same wrong data more reliably. Fix the container you have first.
• You have no consent layer worth preserving. If tags currently fire before consent, you have a compliance problem, and server-side makes the data flow harder to inspect, not easier.
• Nobody will own it. A tagging server is infrastructure. It needs someone watching the bill, the error rate and the container version. An unowned sGTM setup fails silently and expensively.
• Your ad spend doesn't justify the floor. At $145/month plus the setup, you need enough spend for a few percent of recovered signal to matter.

If you're already running clean client-side tracking with Consent Mode v2 wired properly, and you're losing measurable signal to ITP and ad-blockers, then it's worth it — and the honest way to find out is to measure your own before-and-after, not to trust anyone's benchmark. That's how we scope it: server-side GTM, done properly.