Before You Provision Anything
Setting up a server-side GTM container is mostly a hosting exercise, but the decisions that matter most are made before you touch Google Cloud. Two questions shape everything: which destinations you actually need server-side (GA4, Google Ads, Meta's Conversions API), and how you'll carry the visitor's consent into the container. If you skip those, you can end up with expensive infrastructure that forwards data you weren't allowed to send.
This guide is the platform-agnostic version. If you run a specific stack, the WordPress and Shopify guides cover the same steps with platform detail. For the underlying concepts, start with What Is Server-Side Google Tag Manager?
Provisioning a Server Container, Step by Step
Create the server container in GTM
In Google Tag Manager, create a new container and choose Server as the target platform. GTM generates a container configuration string you'll need during provisioning. This container is separate from your existing web container, they work together, not as replacements.
Choose where to host it
Google's documentation offers three official provisioning paths: an automated Cloud Run setup, an older App Engine setup, and a manual setup for any platform of your choice. You can also use a managed tagging host that runs the server for you. Hosting options and their costs are compared below.
Deploy and scale the tagging server
A production deployment should run more than one server instance so a single crash or a traffic spike doesn't drop events. Google recommends provisioning for redundancy rather than running a single minimal instance in production.
Map a first-party custom domain
Point a subdomain of your own site, for example sgtm.yoursite.com or track.yoursite.com, at the server. This is the whole point of the exercise: requests and cookies on a genuine first-party domain survive tracking prevention and are far harder for blockers to strip.
Send data from the web container to the server
In your web container, set the transport URL of your Google tag to the server domain. From then on the browser sends events to your subdomain instead of to Google directly, and the server container forwards them onward.
Test in Preview, then go live
Use the server container's Preview mode to confirm incoming requests are parsed, tags fire, and destinations respond. Only publish once you can see clean events end to end.
Hosting Options Compared
The hosting choice is the biggest fork in the road. It drives cost, effort, and how much of the plumbing you own.
- Google Cloud Run is Google's current recommended path. It's a fully managed, autoscaling container platform, so you pay for the compute you use and it scales to zero when idle. It's the most flexible official option and the one Google's automated setup targets.
- App Engine is the older Google-hosted option. It still works and is documented, but Cloud Run is now the primary recommendation for new deployments.
- Manual setup on your own platform lets you run the tagging server on any host, from a VM to another cloud. It's the most work and the most control.
- Managed tagging hosts run the server for you on a subscription. You trade some control and monthly cost for not operating cloud infrastructure yourself, which is often the right call for marketing teams without a DevOps function.
Server Container Hosting at a Glance
| Option | Effort to run | Typical cost shape | Best for |
|---|---|---|---|
| Google Cloud Run | Moderate: you own the GCP project and scaling config | Pay-as-you-go compute; scales to zero when idle | Teams comfortable with Google Cloud who want flexibility |
| App Engine | Moderate: older Google-hosted path | Instance-hours; less granular than Cloud Run | Existing App Engine users; not first choice for new setups |
| Manual / self-hosted | High: you operate and patch the server yourself | Whatever your infrastructure costs | Teams with strict data-residency or infra requirements |
| Managed tagging host | Low: the provider runs and scales it | Monthly subscription, often tiered by request volume | Marketing teams without DevOps who want it working fast |
What It Actually Costs
There are two cost models, and they behave very differently.
Self-managed on Google Cloud is metered compute. A small site with modest traffic can run for a few dollars a month because Cloud Run scales to zero when there's no traffic. Costs rise with request volume, and a high-traffic site running several always-on instances for redundancy can reach tens or low hundreds of dollars a month. The trap is running a single minimal instance to save money, which sacrifices the redundancy Google recommends for production.
Managed hosting is a predictable subscription, commonly tiered by monthly request volume, with entry tiers around the low tens of dollars per month. You pay more per request than raw Cloud Run at scale, but you get an operated, monitored server without owning any cloud infrastructure. For most marketing teams the time saved outweighs the premium.
Whichever you pick, budget for the second-order costs too: someone has to maintain the container, keep the custom domain and certificates healthy, and validate that consent is being honored. Those are the recurring costs that determine whether the setup keeps working six months later.
Don't Skip the Consent Wiring
A server container that forwards data is trivial to build. A server container that only forwards data for visitors who consented is the part that keeps you compliant, and it's the part most setups get wrong. Before you go live, confirm that non-essential tags are blocked in the web container until consent, that each event carries the visitor's consent state to the server, and that Google destinations receive the correct Consent Mode signals. Validate declined-consent sessions send nothing identifiable.
A Faster Path: CookieBeam's sGTM Add-On
If you'd rather not stand up Cloud Run and manage a domain and certificates yourself, CookieBeam offers a server-side GTM add-on that runs the tagging server on CookieBeam's infrastructure with the consent signal integrated natively. The consent choice captured by your CookieBeam banner is available inside the server container, so gating tags by consent is built in rather than reconstructed after the fact. It's the managed-host model with the consent layer already connected. See the Google Tag Manager integration guide to see how the pieces connect, and Server-Side Consent Enforcement for the enforcement model.
Related Guides and Sources
Next, read Server-Side Tracking Validation to test your container, and Server-Side vs Client-Side GTM to confirm the tradeoffs. Primary sources: Google's server-side tagging overview, the Cloud Run setup guide, the manual setup guide, and the App Engine setup guide.