Cloudflare Zaraz vs Server-Side GTM: the $0 and the $120/month Paths to Server-Side Tagging

The standard recommendation for fixing analytics data loss is server-side GTM. The standard recommendation also costs about $120 a month before it processes a single event: Google’s production guidance calls for at least three Cloud Run instances, and traffic fees stack on top. Cloudflare Zaraz starts at $0 for a million events a month, on the network your site may already run on.

That gap is not an apples-to-apples discount, because the two tools do different things with your tags. Picking between them on price alone is how teams end up with the wrong one.

Cloudflare Zaraz vs server-side GTM: what each one actually moves

Server-side GTM moves the processing. Your tagging server, a Node.js container on Cloud Run, Stape, or your own Docker host, receives hits on a first-party subdomain, transforms them through clients and triggers, and fans them out to GA4, Meta CAPI, and whatever else is configured, server to server.

What it does not move is the browser side. A client-side GTM web container still loads on the page, still executes vendor tags, and still occupies the main thread; only the destination of the hits changes. Zaraz inverts this: vendor logic runs as Managed Components inside Cloudflare Workers, the browser ships one small loader, and there is no web container at all.

So the comparison is not two flavors of the same thing. It is processing depth on a server you operate versus execution removal on an edge you rent for free, and most of the differences below fall out of that split.

TL;DR

• Server-side GTM relocates tag processing to a tagging server, but the client-side GTM container keeps running in the browser. Zaraz removes vendor JavaScript from the browser entirely.
• Cost floor: about $120/month on Cloud Run per Google’s three-instance guidance, $20 to $200/month on Stape depending on volume. Zaraz is free to 1 million events a month, then $5 per additional million.
• Safari 16.4 caps even server-set cookies at 7 days unless the tracking subdomain’s IP shares a /16 subnet with the main domain. Zaraz gets that alignment automatically; Cloud Run defaults fail it.
• Roughly 80% of ad blockers detect custom-domain sGTM traffic. The real recovery on both platforms is the server-to-server CAPI layer.
• Google Tag Gateway is a third, lighter option: first-party serving through your CDN with no tagging server and no processing.
• The working threshold: above roughly $5,000 a month in paid media with heavy Safari traffic, sGTM’s integration depth can earn its bill. Below it, Zaraz usually covers everything you need.

How server-side GTM works: the tagging server

Server-side GTM is a Node.js application shipped as a Docker image that you host yourself. The browser sends measurement hits to a subdomain like ss.yourdomain.com; the tagging server picks them up and runs them through a pipeline of clients, triggers, and tags.

Clients are the underrated part. A client is an adapter that reads any incoming HTTP request and turns it into GTM events, which means the tagging server can ingest things a browser never sends: Shopify webhooks, CRM events, native app hits, Measurement Protocol calls from your backend. One request can become many events, and each event fires tags independently.

The tag side is where sGTM pulls far ahead. The community template gallery covers Meta CAPI, TikTok Events API, Klaviyo, Pinterest, and most of the long tail of ad platforms, with the knobs that matter for paid media: Enhanced Conversions hashing, Meta Event Match Quality optimization, event deduplication by event_id, offline conversion uploads. If a marketing team needs it, someone has built a template for it.

One recent change worth knowing: since sGTM v3.2.0 in September 2025, the GA4 client no longer loads gtag.js itself; all Google JavaScript libraries are served through the Web Container Client. The architecture keeps evolving, and Google develops it actively.

What never changes is the browser half. The client-side web container still loads, vendor tags still execute on the main thread, and the page still pays for them. Independent measurements by Semetis describe the page-speed gain of moving tags server-side as significant but not conclusive; on a site running only GA4, the difference is usually a few PageSpeed points. Server-side GTM is a data-quality tool that sometimes helps performance, not a performance tool.

How Zaraz works: no vendor code to relocate

Zaraz starts from the browser side that sGTM leaves alone. Each tool runs as a Managed Component inside a Cloudflare Worker, on the edge that already serves your site; the browser ships a single loader that batches events through zaraz.track() and sends them to your own domain. There is no web container, no vendor tags on the main thread, nothing to relocate.

The fan-out happens where sGTM’s does, server-side, just on rented infrastructure instead of operated infrastructure. A pageview hits the edge worker and flows to GA4, Meta, or Google Ads over their server APIs. Consent Management and Google Consent Mode v2 are built into the same layer, so the gate travels with the transport.

The full architectural argument, including what happens when you try to keep vendor scripts in the browser but move them to a web worker, is in Partytown vs Cloudflare Zaraz. The short version for this comparison: Zaraz buys its performance win by accepting a smaller integration catalog, and that trade is the hinge of every section below.

Two limits to keep on the table. Zaraz expects your DNS proxied through Cloudflare, and its tool catalog is whatever has a Managed Component, which is dozens of integrations against sGTM’s hundreds of templates. GA4 also arrives with a documented gap: Zaraz auto-forwards only three events, and engaged-session tracking is yours to build.

The cost gap: $0 versus $120 a month before traffic

The sGTM software is free; the infrastructure is not. On Cloud Run, Google’s setup guidance recommends a minimum of three instances for production, which lands around $120 a month before traffic fees. Usage-based billing means a spike in events is a spike in the bill, and teams routinely discover this from the invoice rather than a dashboard.

Managed hosting compresses that. Stape’s current ladder runs free under 10,000 requests, $20 a month up to 500,000, $100 a month up to 5 million, and $200 a month up to 20 million, with roughly 20% off on annual billing. The trade is a third vendor in your data path, and one plan covers exactly one site, so an agency portfolio multiplies the line item.

Zaraz’s pricing is a different shape entirely: 1 million events per month free on every Cloudflare plan, including Free, then $5 a month per additional million events. A site pushing 5 million events a month pays Stape $100 for the tagging server while the web container still runs in the browser; the same site pays Zaraz $20 and ships no vendor JavaScript at all.

The number that matters is not $120 against $0, it is what the money buys. If you need the tagging server’s processing depth, the bill is justified and Stape makes it affordable. If you need first-party collection and a clean browser, you are paying for capabilities Zaraz includes at zero.

Safari ITP and the IP alignment problem Zaraz does not have

The first-party cookie story is where most sGTM sales pitches go soft, because the fine print moved in 2023. Safari’s ITP has capped JavaScript-set cookies at 7 days since 2019, and server-set cookies were the documented escape. Safari 16.4 closed half of it: server-set cookies also drop to 7 days when the tracking subdomain’s IP does not share the first 16 bits with the main domain’s IP.

That check fails on default deployments. A Cloud Run service resolves to Google’s IP range while your site resolves to its own host, the subnets do not match, and the 400-day first-party cookie quietly becomes a 7-day cookie again. Fixing it requires deliberate IP alignment: load-balancer gymnastics on GCP, or a provider like Stape whose own CDN routes the tagging domain through the same subnet as the site.

Zaraz never has this conversation. The site and the tracking endpoint are served by the same Cloudflare proxy, on the same IPs, because Zaraz is not a subdomain pointing elsewhere; it is the same edge that serves the page. IP alignment is not a configuration step, it is a property of the architecture.

For a stack where Safari and iOS are a meaningful share of revenue, this single detail decides more than the feature lists do. An sGTM deployment without verified IP alignment is paying for a Safari benefit it does not receive.

Ad blockers eat both, just differently

The pitch you will hear for both tools is that first-party collection defeats ad blockers. The current data says otherwise, and it is worth being precise about what each architecture actually changes.

For sGTM, the custom subdomain is no longer enough. DataUnlocker’s analysis found that roughly 80% of widely used ad blockers still detect and block custom-domain sGTM traffic, because modern filter lists match on path patterns, payload shape, and the loader scripts themselves rather than only on vendor domains. The client-side web container that sGTM keeps in the browser remains a stationary target.

Zaraz removes the vendor domains and the vendor scripts, which shrinks the blockable surface, but its default /cdn-cgi/zaraz/ paths sit in the same privacy filter lists, and uBlock Origin blocks them out of the box. The working countermeasure is custom endpoints, which serve the loader and event calls from pathnames a generic list cannot distinguish from application code. The mechanics are covered in the Partytown comparison linked above, and it is how this site runs.

The durable recovery on both platforms is the same layer: server-to-server. A Meta CAPI call from a tagging server or an edge worker never touches the visitor’s browser, so no extension can filter it. The conversion-recovery numbers vendors advertise come from that layer, not from renaming a subdomain, and both tools have it. Consent still gates everything; the goal is keeping consented visitors in your reports, not tracking the ones who opted out.

Google Tag Gateway: the third option already in your dashboard

In May 2025 Google shipped a third path that this comparison cannot skip, because it lives in the same Cloudflare dashboard as Zaraz. Google Tag Gateway for advertisers, the renamed first-party mode, serves gtag.js and routes measurement through your own domain via a one-toggle Cloudflare integration. Akamai followed in January 2026, Fastly in April 2026.

Be clear about what it is not. Tag Gateway has no tagging server and no event processing: the Google tag still executes in the browser, on the main thread, exactly as before. It changes the serving and collection path, which improves signal capture; Google reported around an 11% uplift in observed signals at launch, and Fastly cites 14% on its implementation.

That makes it the lightest intervention of the three. No infrastructure, no migration, a measurable data-quality gain, and zero performance benefit. If your only problem is signal loss on Google tags and your stack is otherwise fine, the toggle may be all you need, and it costs nothing to try.

The reason it does not replace either tool in this article: it covers Google tags only, does nothing for Meta or TikTok, keeps all vendor JavaScript in the browser, and offers no consent layer, no transformation logic, and no non-Google destinations. Tag Gateway is a patch on the collection path; Zaraz and sGTM are architectures.

When server-side GTM is worth its bill

The threshold that keeps showing up in practitioner write-ups is paid media spend. Above roughly $5,000 a month in ad budget, conversion-signal loss is a real line item, and the integration depth that recovers it, Enhanced Conversions, Event Match Quality optimization, offline conversion uploads, starts paying for the tagging server. Below that, the maintenance burden usually costs more than the recovered signal is worth.

Three more signals point at sGTM. Your marketing team lives in GTM and needs its template gallery rather than a fixed component catalog. Your data sources go beyond the browser: CRM webhooks, native apps, backend Measurement Protocol calls that need a custom client to ingest. Or your site simply is not on Cloudflare, which ends the Zaraz conversation before it starts.

The two are also not mutually exclusive. A working hybrid keeps Zaraz as the browser-facing layer, one loader, consent gate, GCMv2, and adds the tagging server as one more server-side destination for the events that need deep processing. The catalog ceiling stops being a constraint, the browser stays clean, and the cost is operational: two systems to debug and strict event deduplication by event_id, or Meta counts every conversion twice.

For everything below the threshold, the decision collapses to the architecture question this article started with. If the data you need fits Managed Components, and for most sites running GA4, Google Ads, and a Meta pixel it does, you get first-party collection, automatic IP alignment, consent, and a browser with no vendor code, for $0 to $5 a month. The tagging server remains what it always was: a serious tool for the minority of sites whose data problems are actually worth $120 a month.

Weighing Zaraz against server-side GTM for your stack? gary@edgekits.dev