A Cloud Run pricing calculator will tell you server-side GTM costs close to nothing. Plug in a modest ecommerce traffic estimate, leave every setting on default, and the number that comes back often reads under 10 dollars a month.
That number is real, and it is also not what a production tagging server actually costs. The gap between the calculator estimate and the real server side GTM cost a store sees on its invoice three months later is the single most common surprise we see when we audit a server-side GTM setup.
The calculator prices the scale-to-zero scenario: your container spins down when nobody is checking out and spins back up on the next request. A tagging server that has to respond fast enough to fire a Google Ads or Meta conversion in real time, often while consent mode is deciding whether to allow the tag at all, cannot tolerate that spin-up delay. So production setups keep at least one instance running continuously, and Google's official server-side tagging documentation is upfront that the default Google Cloud Platform deployment carries costs that scale with usage and linked projects beyond the free tier, not a flat free ride.
That is the real driver behind the gap between what a calculator shows and what shows up on the card three months in. This post walks through what Cloud Run, a managed host like Stape, and staying client-side actually cost at different traffic levels, and the two hidden line items that hosting comparisons never price.
What Cloud Run actually bills you for
Google Cloud Run's pricing page breaks billing into three components: vCPU time, memory (GiB) time, and request count, each metered per second and offset by a monthly free tier. The mechanism itself is straightforward.
What changes the bill is which billing mode you run under. Request-based billing, the default, only meters CPU while a request is actively being handled, which is why idle traffic estimates come back near zero. Keeping an instance always allocated so it can respond instantly, the mode a production tagging server needs, meters CPU and memory continuously for as long as the instance exists, whether or not it is handling a request that second.
An independent cost breakdown from TrackingFixes puts realistic Cloud Run hosting at $20 to $60 a month for stores under roughly 500,000 monthly sessions, climbing to $80 to $150 a month once a store passes 1 million sessions. Those figures already assume the always-allocated configuration a live tagging server needs, not the scale-to-zero estimate a default calculator run produces.
What a managed host like Stape actually charges
Managed server-side tagging hosts trade a lower theoretical ceiling for a flat, predictable number. Stape's own hosting page lists a free tier for under 10,000 requests a month, a $20-a-month tier covering up to 500,000 requests, and $100 a month above that threshold.
Stape's comparison also states plainly that the Google-recommended production configuration runs close to $120 a month before any traffic overage, against their own $20 tier for the equivalent workload. That is a vendor comparing itself to a competitor, so the exact multiple is worth some skepticism, but it lines up directionally with the independent Cloud Run figures above: once you configure Cloud Run for production reliability rather than the idle default, a flat-rate managed host frequently comes out cheaper for stores that are not running heavy enough volume to justify the engineering time.
The tradeoff is control. A managed host abstracts away the instance count and scaling decisions that a self-managed Cloud Run deployment exposes, which is exactly what most ecommerce teams want, and exactly what a team running multiple linked GCP projects or custom server-side clients usually does not want to give up. We covered the architecture and deployment mechanics of a self-managed setup in our server-side GTM deployment guide if that control is worth the tradeoff for your team.
The two costs no pricing page mentions
Hosting is the line item every comparison prices. Two others rarely make the comparison table, and both recur.
Build time. Migrating an existing client-side setup to server-side means re-mapping every tag, GA4, Google Ads, Meta Conversions API, to a server-side client and trigger, then verifying each one fires exactly once against the same event it used to fire from the browser. On a Shopify store running checkout extensibility, that mapping starts from the Web Pixels API rather than a theme-loaded container, which we detail in our Shopify conversion tracking guide. This is a one-time cost, but it is rarely small, and DIY estimates that only price hosting miss it entirely.
Maintenance. Google and Meta update their server-side APIs and event schemas often enough that a tagging server built once and never revisited tends to drift out of spec within a year, usually silently. Someone has to own watching for those changes, re-testing the container in preview mode, and confirming match rates and event counts still reconcile against platform reporting.
Neither of these costs a fixed dollar figure the way hosting does, which is exactly why they get left off pricing comparisons even though they are usually the larger share of the first year's real cost.
A rough decision frame by scale
Use monthly sessions and ad spend as the two inputs, not a generic "do we need this" gut call.
- Under 500,000 sessions, under $5,000 monthly ad spend: client-side tracking done correctly, meaning Shopify Web Pixels for checkout events plus clean GA4 and Meta tags, usually covers a store at this scale without the added hosting and maintenance surface of a server-side container.
- 500,000-plus sessions, or ad spend where a few points of iOS/Safari tracking loss is a real revenue number: a managed host is the fastest path to server-side accuracy gains without adding a Cloud Run instance to babysit.
- High volume with in-house engineering capacity to monitor a service: self-managed Cloud Run can undercut a managed host per request at real scale, but only if someone owns watching the instance count, the billing mode, and the API drift described above.
The number that actually matters
Prices on this page will not hold forever. Cloud Run's per-second rates and Stape's tiers are both subject to change, and the honest move before committing a budget is to re-check both pricing pages directly rather than trusting a number from any single post, including this one.
What does not change with pricing updates is the underlying question: what is your monthly server-side event volume, and does the accuracy gain at that volume outweigh the hosting bill plus the maintenance it takes to keep the setup honest. That is the number worth pinning down before picking a hosting path, not the sticker price on a calculator screen.
If you are not sure which side of that line your store sits on, that reconciliation, checking what a server-side setup would actually cost against what it would actually fix, is exactly what we scope in a tracking audit before recommending a server-side tracking setup at all.
