Where to host server-side GTM: Cloud Run, Stape, and the trade-offs

Server-side GTM needs somewhere to run, and the choice is essentially between hosting it yourself on Google Cloud Run, paying a managed provider such as Stape to run it for you, or running it on your own infrastructure. The decision is less about cost than about who gets paged when it breaks — a server container is production infrastructure sitting directly in your conversion path.

The three options

Google Cloud Run

Google's documented deployment path. You deploy the tagging server image, configure autoscaling, map a subdomain, and manage it like any other cloud service.

Good: full control, no third party in your data path, cost scales with actual usage, and integrates with the Google Cloud tooling you may already use.

Less good: you own the operations — monitoring, scaling configuration, certificate management, updates. Scaling misconfiguration is the classic failure, either paying for idle instances or dropping requests under load.

Managed providers

Stape and similar services run the container for you, typically with a subdomain setup wizard, monitoring, and useful extras such as cookie-lifetime handling.

Good: running in an afternoon, no infrastructure ownership, support when something breaks, and features layered on top of stock server-side GTM.

Less good: a recurring cost that scales with volume, and a third party in your data path — which matters for some compliance postures and is a question your legal team may ask.

Self-hosted on your own infrastructure

If you already run Kubernetes or equivalent, the tagging server is just another container.

Good: maximum control, no new vendor, data never leaves infrastructure you already govern.

Less good: you own everything, and your platform team may reasonably ask why analytics is now their on-call responsibility.

	Cloud Run	Managed	Self-hosted
Setup effort	Moderate	Low	High
Ongoing ops	Yours	Theirs	Yours
Cost shape	Usage-based cloud bill	Subscription	Existing infrastructure
Third party in data path	No	Yes	No
Best for	Teams with cloud capability	Teams without	Teams with a platform function

What actually drives cost

Server-side GTM cost is driven by request volume, not by page views. Every event you route through the container is a request, so a site sending eight events per session costs roughly eight times a site sending one.

Three things move the bill materially:

• Minimum instances. Keeping instances warm avoids cold-start latency and costs money continuously. Setting this to zero is cheap and adds latency to the first request after idle.
• Event volume per session. Worth auditing before you migrate — many containers send events nobody uses.
• Region choice. Run close to your users, but consolidating regions reduces cost and complexity.

The honest summary: for a low-traffic site, hosting costs more than the measurement improvement is worth. For a high-traffic site, the per-event cost is trivial. That crossover, rather than any technical argument, is usually what should decide whether you do this at all — when to move server-side covers the decision.

The parts everyone underestimates

The subdomain and DNS setup. The container must run on your own domain — something like sst.example.com — for the first-party cookie benefit to exist at all. Running it on a provider's domain gives up most of the reason to do it.

Certificate management. Handled for you on managed platforms, your job on Cloud Run.

Monitoring. A server container sits in your conversion path. If it goes down, you lose conversions, silently, until someone notices a chart. Uptime and error-rate alerting is not optional, and it is the step most often skipped.

Debugging is harder. Two containers to inspect, and the server-side preview experience is less immediate than client-side. Budget more time than you expect for the first month.

Consent still applies. Nothing about server hosting changes your obligations — consent governs processing, not transport.

Latency, and why it is worth measuring

A server container adds a hop between the browser and each vendor. In practice the added latency is small, and it does not block page rendering — but two situations make it worth measuring rather than assuming.

Cold starts. With minimum instances set to zero, the first request after an idle period pays the container's startup cost. On a low-traffic site that can mean a meaningful share of requests hitting a cold instance. Either accept it, or pay for a warm instance.

Region mismatch. A container running in one region serving users in another adds real round-trip time. Deploy close to your traffic, and check where your traffic actually is rather than where your head office is.

Measure it once after go-live: compare event delivery timing before and after the migration. If nothing moved materially, stop thinking about it. If it did, the fix is almost always instance configuration or region, not the architecture.

A sane rollout

1. Stand up the container and point a subdomain at it.
2. Send one vendor first — usually GA4 — while leaving everything else client-side.
3. Run both in parallel for a week and compare counts. They should be close; investigate any material gap before proceeding.
4. Migrate the next vendor, verifying each in turn.
5. Add monitoring before you consider it done, not after the first outage.
6. Keep the client-side container. It still collects browser context — click IDs, cookies, user agent — which the server needs.

FAQ

How much does server-side GTM cost to run?

On Cloud Run, a usage-based cloud bill driven by request volume and minimum-instance settings. Managed providers charge a subscription that scales with volume. Either way, cost per event falls sharply as traffic grows, which is why it is poor value at low volume.

Is Stape better than Cloud Run?

Different trade-offs. Managed hosting is faster to set up and comes with support; Cloud Run gives full control and keeps a third party out of your data path. Choose based on whether you have the capability and appetite to operate it.

Do I need a subdomain for server-side GTM?

Yes, if you want the first-party cookie durability that is the main technical benefit. Running on a provider's domain forfeits most of the advantage.

What happens if my server container goes down?

You stop collecting events routed through it — conversions included — until it recovers. This is why uptime monitoring is mandatory rather than nice to have.

Can I keep my client-side container after moving server-side?

Yes, and you should. The client container collects the browser context the server depends on. Server-side is an additional layer, not a replacement.

Before adding infrastructure, confirm the client-side layer is sound: the free tracking audit checks tags, duplicates, weight, and consent on any URL.