What Is a Server-Side GTM Container and Why Does It Matter?

A server-side Google Tag Manager container is a second GTM environment that runs not in the visitor’s browser, but on a server you control. In a traditional GTM setup, every tag fires inside the user’s browser—Google Analytics, Meta Pixel, TikTok Pixel, and dozens of others all execute as JavaScript on the visitor’s device. This creates three serious problems. First, ad blockers and browser privacy features block many of these tags, causing data loss. Second, each third-party tag adds page load weight, slowing your site. Third, you have limited control over what data is shared with third-party vendors, creating compliance headaches under GDPR and CCPA.

Server-side GTM solves all three problems by moving tag execution off the browser entirely. Your website sends events to your own server endpoint. That server—running the GTM server container—then fans the data out to Google Analytics, Meta, TikTok, or any other destination. Ad blockers cannot intercept server-to-server calls. Your page loads faster because third-party scripts no longer run in the browser. And you control exactly what data leaves your infrastructure before it reaches any vendor.

Google Cloud Run is the ideal hosting platform for a server-side GTM container. It is a fully managed, serverless container platform that scales automatically from zero to thousands of requests per second. You pay only for what you use, with a generous free tier that covers most small and medium websites entirely. In this guide you will learn how to deploy your server-side GTM container on Cloud Run from scratch.

Architecture Overview

The setup involves three components. The tagging server is a Docker container provided by Google (the official GTM server image) running on Cloud Run. The client-side GTM container is your existing browser GTM container, modified to send events to your tagging server instead of directly to Google’s servers. The server-side GTM container is a new GTM container of type “Server” that receives events from your client container, processes them with server-side tags, and sends data to your analytics and advertising platforms.

The data flow looks like this: browser fires GTM → GTM sends events to your Cloud Run tagging server URL → server-side GTM container receives and processes events → server sends data to GA4, Meta CAPI, TikTok Events API, and any other destinations. The browser never directly contacts Google Analytics or Meta’s servers. Everything goes through your infrastructure first.

Step 1: Create a Server-Side GTM Container

Log into tagmanager.google.com and click “Create Account” or go to an existing account. Click “Create Container.” Give it a descriptive name like “Analytigrow Server.” For the target platform, select “Server” instead of “Web.” Click “Create.” GTM will show you a Container ID in the format G-XXXXXXXXXX and a Container Config string—a long base64-encoded value that starts with ZW5.... Copy this Container Config string. You will need it when deploying Cloud Run.

Unlike a web container, a server container does not give you a snippet to paste into your HTML. Instead, the container config is passed as an environment variable to the Docker container running on your server. This is what tells the tagging server which GTM container to load.

Step 2: Enable Required Google Cloud APIs

Open the Google Cloud Console at console.cloud.google.com and select your project. Navigate to “APIs and Services” then “Enable APIs and Services.” Search for and enable the following APIs: Cloud Run API, Cloud Build API, and Artifact Registry API. These are all free to enable—you only pay for usage. Cloud Run has a generous free tier of 2 million requests per month, 360,000 GB-seconds of memory, and 180,000 vCPU-seconds. For most websites this means the entire tagging server runs at zero cost.

Step 3: Deploy the GTM Server Container on Cloud Run

The easiest deployment method uses the Google Cloud Shell. Open it by clicking the terminal icon in the top right of the Cloud Console. In the Cloud Shell, run this command, replacing the container config value with your actual Container Config string from Step 1:

gcloud run deploy gtm-server   --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable   --region us-central1   --platform managed   --allow-unauthenticated   --min-instances 1   --max-instances 4   --memory 512Mi   --set-env-vars CONTAINER_CONFIG=YOUR_CONTAINER_CONFIG_HERE

The --min-instances 1 flag keeps one instance always warm, eliminating cold start latency. Without this, the first request after a period of inactivity experiences a 1–3 second delay while Cloud Run spins up a container—unacceptable for a tag that needs to capture every pageview. The --max-instances 4 limits scaling to prevent unexpected cost spikes. Adjust this based on your traffic volume. The --memory 512Mi gives the container enough memory to process concurrent events comfortably.

After the command completes (usually 2–3 minutes), Cloud Run outputs a Service URL that looks like https://gtm-server-abc123-uc.a.run.app. This is your tagging server URL. Test it by visiting https://your-service-url/healthz in a browser—you should see {"ready":true}.

Step 4: Map a Custom Domain to Your Tagging Server

For server-side tracking to work effectively—particularly for first-party cookie benefits—your tagging server should run on a subdomain of your own domain rather than the run.app URL. Common choices are tag.yourdomain.com, collect.yourdomain.com, or sst.yourdomain.com. In the Cloud Run console, click on your service, then “Manage Custom Domains.” Click “Add Mapping,” select your Cloud Run service, and enter your desired subdomain.

Cloud Run will provide you with a CNAME record to add to your DNS. Add this CNAME in your domain registrar or DNS provider. DNS propagation typically takes 10–60 minutes. Once propagated, Cloud Run automatically provisions and renews a free SSL certificate for your subdomain via Let’s Encrypt. Test the custom domain by visiting https://tag.yourdomain.com/healthz—you should see {"ready":true}.

Step 5: Configure Your Client-Side GTM to Send to the Tagging Server

Now update your existing browser GTM container to route events to your server. In your web GTM container, go to Variables and find the GA4 Configuration tag (or create one if you do not have it). In the tag settings, find “Server Container URL” and enter your tagging server URL: https://tag.yourdomain.com. This tells the GA4 tag to send measurement protocol hits to your server instead of directly to Google.

Alternatively, and more robustly, modify your GTM snippet in the website HTML. The standard GTM snippet loads from https://www.googletagmanager.com/gtm.js. Change this to load from your tagging server: https://tag.yourdomain.com/gtm.js. This is the most thorough approach because it routes the GTM script itself through your server, making it appear as a first-party resource to the browser and defeating most ad blockers.

Step 6: Add a GA4 Client and Tag in the Server Container

Back in your server-side GTM container, you need to configure a Client to receive events and a Tag to forward them to GA4. Navigate to Clients and click “New.” Choose “GA4” as the client type. This client listens for GA4 measurement protocol requests arriving at your tagging server. Leave the default settings and save.

Then go to Tags and create a new tag. Choose “Google Analytics: GA4” as the tag type. Enter your GA4 Measurement ID (G-XXXXXXXXXX). For the trigger, select “All Events” or create a specific trigger for the events you want to forward. This tag takes the events received by the GA4 client and forwards them to Google Analytics on the server side, using server-to-server communication that bypasses ad blockers entirely. Save and submit the container version.

Step 7: Verify the Setup

Use GTM’s preview mode to verify events are flowing correctly. In your server-side GTM container, click “Preview.” Enter your website URL. GTM will open your site and the preview pane will show events arriving at the server container in real time. You should see events like page_view and session_start appearing as they are triggered on your site.

Also check the GA4 DebugView (in GA4 Admin → DebugView) to confirm events are arriving in GA4. Events forwarded server-side appear in DebugView just like browser-fired events. If events appear in the GTM server preview but not in GA4 DebugView, check that your GA4 tag in the server container has the correct Measurement ID and that the GA4 client is configured correctly.

Monitoring Costs and Performance

Cloud Run billing is based on requests, CPU time, and memory. For a website receiving 100,000 pageviews per month with two events per pageview, you would process approximately 200,000 requests. Cloud Run’s free tier covers 2 million requests per month, so this scenario costs nothing. Even at 1 million pageviews per month generating 5 million events, you would pay only a few dollars.

Monitor your Cloud Run service in the Cloud Console under Monitoring. Watch for elevated latency (p99 should stay under 200ms for a healthy tagging server) and error rates. Set up a budget alert in Google Cloud Billing at $5/month—if costs ever spike unexpectedly, you will be notified immediately before charges accumulate. For most websites, the server-side GTM setup on Cloud Run will cost exactly zero dollars per month.

Conclusion

Deploying a server-side GTM container on Google Cloud Run gives you ad-blocker-resistant tracking, faster page load times, and full control over what data reaches third-party vendors—all with minimal ongoing cost. The setup described in this guide takes about one to two hours to complete from start to finish, and the performance and data quality benefits begin immediately. Once your server container is live, you can progressively add server-side tags for Meta CAPI, TikTok Events API, Google Ads enhanced conversions, and any other platform that supports server-to-server event delivery.