Server Side GTM Hosting: Stape vs Cloud Run (2026)

Server side GTM hosting is the single biggest cost and reliability decision in any server-side tracking setup, and most ecommerce stores get it wrong by defaulting to whichever vendor showed up first in their Google search. This guide cuts through the vendor marketing and compares the three actual choices that most teams pick from in 2026: Stape (managed, flat-rate), Google Cloud Run (DIY, usage-based), and Taggrs (managed, EU-focused). We’ve deployed all three across our agency’s ecommerce PPC client portfolio, so you’ll get the real cost numbers, the actual setup commands (including a copy-paste gcloud deployment for Cloud Run), and a clear decision framework by store size. This pairs directly with our Shopify server side tracking setup guide, which uses whichever hosting option you pick here.

What is server side GTM hosting?

Server side GTM hosting is the infrastructure that runs a Google Tag Manager server container, which receives event data from your store’s browser pixel and forwards it to ad platforms (Google Ads, Meta CAPI, GA4, TikTok) using server-to-server APIs. Without server side GTM hosting, the entire server-side tracking pattern doesn’t work because there’s no server to relay the events through.

How it sits in the wider server-side tracking stack

The full server-side tracking flow has four moving pieces: (1) the store’s browser-side pixel or Shopify Custom Pixel that captures events, (2) a custom subdomain that routes those events to your server, (3) the GTM server container that receives and processes the data, (4) the ad platform APIs that get the enriched data. Server side GTM hosting is piece 3, but the hosting choice constrains the whole stack because each provider has different scaling characteristics, custom domain support, and total cost of ownership.

Why the hosting choice changed in 2024-2025

Before 2024, almost every server-side setup ran on Google Cloud Run because that’s what Google’s official docs recommended. Then Stape’s flat-rate pricing model proved 5-10x cheaper for predictable traffic, and Taggrs entered the market with an EU-focused alternative. By 2026, the three options serve genuinely different use cases, and picking the wrong one wastes either money (over-provisioning Cloud Run) or flexibility (locking into a managed service when you need custom logic).

Why does server side GTM hosting choice matter for ROAS?

Server side GTM hosting choice matters because it directly affects three things that compound into ROAS: data accuracy (each provider has different uptime and request-handling reliability), cost overhead (the spread between providers can be 10x), and engineering velocity (managed providers ship faster, DIY Cloud Run gives more control). For a store doing $50K per month in ad spend, the difference between the right and wrong hosting choice is typically $1,500-4,000 per year in infrastructure costs plus measurable data-loss differences during traffic spikes.

The data accuracy angle

Stape and Taggrs both maintain 99.95%+ uptime SLAs and auto-scale their containers per region. Self-hosted Cloud Run defaults to a single region with no auto-scaling unless you configure it, which means a Black Friday traffic spike can saturate your container and drop events silently. We’ve audited DIY Cloud Run setups where 12-18% of purchase events were dropped during peak hours because the operator never bumped the instance count past the default. Managed providers handle this without configuration.

The cost compounding angle

Stape Basic ($17-20/month) handles up to 100,000 requests, which fits stores doing 5,000-15,000 monthly sessions. The same traffic on Google Cloud Run runs $50-100 per month in compute alone, plus load balancer fees, plus SSL provisioning. Across 12 months that’s $400-1,000 in unnecessary spend before you’ve gained any meaningful control. The math flips above 5M monthly requests, where Cloud Run’s per-request pricing beats Stape’s tier breakpoints. The crossover varies by store, but most ecommerce accounts under $100K/month ad spend save money with Stape or Taggrs.

How does server side GTM hosting work?

Server side GTM hosting works by running a Docker container with the GTM server image, exposing it on a custom subdomain (sgtm.yourdomain.com) via DNS, and listening for incoming POST requests from your browser pixel. The container processes each event through GTM’s tag manager runtime, evaluates which tags should fire, and dispatches server-to-server API calls to ad platforms in parallel. The whole cycle takes 50-200ms.

 Browser pixel              sGTM hosting layer                    Ad platforms
 (Shopify, WP,              (Stape / Cloud Run / Taggrs)         (server APIs)
  custom)
    |                              |                                  |
    |  1. POST event              |                                  |
    |  to sgtm.yourdomain.com     |                                  |
    |---------------------------->|                                  |
    |                              |                                  |
    |                              | 2. DNS resolves to               |
    |                              |    container IP                  |
    |                              |                                  |
    |                              | 3. Docker container              |
    |                              |    runs GTM server runtime       |
    |                              |    processes the event           |
    |                              |    evaluates triggers + tags     |
    |                              |                                  |
    |                              | 4. Server-to-server calls fire   |
    |                              |---  GA4 Measurement Protocol --->| GA4
    |                              |---  Meta Conversions API     --->| Meta
    |                              |---  Google Ads Enhanced       --->| Google Ads
    |                              |---  TikTok Events API         --->| TikTok
    |                              |                                  |
    |                              | 5. Returns 200 OK in 50-200ms    |
    |<-----------------------------|                                  |

The Docker image everyone runs

Every server side GTM hosting provider including Stape, Cloud Run, and Taggrs runs the same official Google-published Docker image (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable). They differ only in how they orchestrate that image: Stape and Taggrs run it on their own multi-tenant infrastructure with shared regional scaling, while Cloud Run runs your dedicated instance under your billing account. The functional output is identical; the operational characteristics aren’t.

What are the best server side GTM hosting options in 2026?

The three best server side GTM hosting options in 2026 are Stape (best for most stores under $100K/month ad spend), Google Cloud Run (best for engineering teams that want full control and high traffic above 5M requests/month), and Taggrs (best for EU-based stores prioritizing data residency and flat-rate predictability). Each occupies a different point on the cost-control-complexity triangle.

Stape

Stape is a managed server side GTM hosting platform launched in 2020 that has become the default choice for most agencies and Shopify stores. Pricing is flat-rate by request volume, with plans starting at $17-20 per month for entry-level traffic and scaling to custom enterprise tiers above 20 million requests. Setup takes 15-20 minutes through their web UI, and they handle SSL provisioning, custom domain mapping, and container updates automatically. Optional Power-Ups add features like Meta CAPI Gateway, user data enrichment, and consent mode handling.

Google Cloud Run

Google Cloud Run is Google’s own serverless container platform, and the path Google’s official documentation originally recommended for server-side tagging. You deploy the GTM Docker image yourself using gcloud CLI commands, configure your own load balancer, manage your own SSL via Google-managed certificates, and pay Google directly based on CPU/memory consumption and request volume. Cost varies from $50/month for low-traffic stores to $1,000+ for high-traffic enterprise sites.

Taggrs

Taggrs is a Netherlands-based server side GTM hosting platform that competes directly with Stape on price and feature parity. Pricing is flat-rate starting at €22 per month for the Basic plan (750,000 requests), with Pro at €57 (3M requests) and Ultimate at €127 (10M requests). Their advantage for European stores is data residency: all servers are EU-hosted by default, which simplifies GDPR compliance for stores serving European customers.

Hosting options we didn’t include and why

AWS Fargate, Azure Container Instances, and self-hosted Docker on a VPS are technically possible but practically uncommon. AWS works but Google’s GTM Docker image isn’t officially supported there, so you lose Google’s deployment guides and template integrations. Azure has the same issue with worse documentation. Self-hosted on a $5 VPS is the cheapest option but you’re managing SSL, scaling, monitoring, and updates yourself for what amounts to a $200/year saving over Stape. The juice isn’t worth the squeeze for any store doing meaningful ad spend.

How does Stape compare to Google Cloud Run for server side GTM hosting?

Stape beats Google Cloud Run on simplicity, predictable pricing, and time-to-deploy. Cloud Run beats Stape on raw control, very-high-traffic economics (above 5M requests/month), and the freedom to add custom services on the same infrastructure. For 85% of ecommerce stores running under $100K/month ad spend, Stape is the more sensible default. The remaining 15% (enterprise sites, custom-logic teams, or stores already deep inside Google Cloud) benefit from Cloud Run.

When Stape wins

Stape wins when you want server-side tracking working by end of day, when your traffic is predictable enough that flat-rate pricing beats Cloud Run’s pay-per-use math, and when you’d rather invest engineering time in optimizing ads than maintaining infrastructure. For example, a Shopify store doing 50,000 monthly sessions on Stape Basic runs $17-20/month forever and survives Black Friday spikes without any operator action. The same store on Cloud Run costs $50-100/month baseline plus operator time to monitor scaling during peak periods.

When Cloud Run wins

Cloud Run wins above roughly 5M monthly requests where Stape’s tier pricing climbs faster than Cloud Run’s per-request billing, when you need to run custom services alongside the GTM container (analytics microservices, custom enrichment logic, internal APIs), and when your organization is already standardized on Google Cloud and wants billing consolidation. For example, an enterprise SaaS doing 20M monthly requests pays Stape roughly €167/month for the custom tier versus $200-400/month on Cloud Run, but Cloud Run gives you the option to deploy related microservices on the same VPC for free.

How does Taggrs compare to Stape and Cloud Run?

Taggrs sits between Stape and Cloud Run on most dimensions but wins decisively on EU data residency. Pricing is competitive with Stape (entry tier at €22/month for 750K requests versus Stape’s $17-20/month for ~100K requests). Their differentiator is that every server is hosted within the EU by default, which simplifies GDPR documentation for stores serving European customers. Outside the EU residency angle, Taggrs and Stape are functionally close, and the right choice usually comes down to which UI you prefer.

The Taggrs request-counting advantage

Taggrs counts requests more generously at the same dollar amount. Their Basic tier covers 750,000 monthly requests for €22 (roughly $24), while Stape’s similarly-priced Basic plan covers around 100,000 requests. For high-traffic stores with relatively simple tag configurations, this gap can translate into real savings. The trade-off is Stape’s deeper Power-Ups library, which becomes worth the per-request premium if you need features like Meta CAPI Gateway, GA4 deduplication, or consent-mode pre-processing.

How do you set up server side GTM hosting on Stape?

Setting up server side GTM hosting on Stape takes four steps: (1) create a Stape account and provision a new sGTM container, (2) paste your GTM Server container config from Google Tag Manager into Stape, (3) configure your custom subdomain by adding a CNAME record at your DNS provider, (4) wait 5-15 minutes for SSL provisioning and verify the container is live. Total time is 15-20 minutes if your DNS provider responds quickly.

Step 1: Provision the Stape container

Sign up at stape.io with your business email. After verification, click Create new sGTM container and pick the region closest to where most of your customers convert. For a US-focused store, pick US East. For an EU-focused store, pick Belgium or Frankfurt. The region affects latency, not functionality, and you can change it later by migrating containers.

Step 2: Paste the GTM Server config

Open Google Tag Manager in another tab and create a new container of type Server. Inside that new server container, go to Admin then Container Settings, and find the Container Configuration string. This is a base64-encoded blob that includes your container ID and a default API key. Copy the entire string and paste it into Stape’s container setup wizard. Stape uses this to authenticate with your GTM Server container.

Step 3: Add your custom domain

Inside the Stape container, navigate to Domain Configuration and add your desired custom subdomain (typically sgtm.yourdomain.com). Stape will display a CNAME target that looks like cname.stape.io or similar. Go to your DNS provider (Cloudflare, GoDaddy, Route 53, etc.) and add a CNAME record:

Step 4: Verify the container is live

SSL provisioning takes 5-15 minutes after DNS propagates. To verify, run this curl command from any terminal:

curl -I https://sgtm.yourdomain.com/healthy

# Expected output:
# HTTP/2 200
# content-type: text/plain
# date: ...

A 200 OK response means your container is live and ready to receive events. If you get a 404 or SSL error, wait another 10 minutes for SSL provisioning. If you get a timeout, double-check the CNAME at your DNS provider and confirm Cloudflare proxy is off.

How do you set up server side GTM hosting on Google Cloud Run?

Setting up server side GTM hosting on Google Cloud Run takes seven steps and 60-90 minutes for someone who’s done it before: (1) install the gcloud CLI and authenticate, (2) create a new Google Cloud project and enable billing, (3) enable required APIs, (4) deploy the GTM preview server first with one gcloud command, (5) deploy the GTM tagging server with a PREVIEW_SERVER_URL pointing at the preview server, (6) configure a custom domain through Cloud Run domain mapping or a load balancer, (7) point DNS at the Cloud Run endpoint and verify. The commands below are the exact sequence we use across our agency’s Cloud Run deployments and they work first try.

Step 1: Install gcloud CLI and authenticate

If you don’t already have gcloud installed, install it from cloud.google.com/sdk. Once installed, authenticate against your Google account:

# ============================================================
# STEP 1: Authenticate gcloud CLI
# ============================================================
# WHERE TO RUN: Your local terminal (Mac, Linux, WSL, or PowerShell)
#
# NO CUSTOMIZATION NEEDED. The browser window will open
# automatically for you to log in to your Google account.
# ============================================================

gcloud auth login

Step 2: Create a Google Cloud project

Create a dedicated project for the GTM server. Using a dedicated project keeps billing isolated and simplifies cleanup if you ever decide to migrate away.

# ============================================================
# STEP 2: Create a new Google Cloud project for sGTM
# ============================================================
# WHERE TO RUN: Your local terminal, after authenticating
#
# CUSTOMIZE BEFORE DEPLOYING:
#   Replace 'sgtm-yourbrand-prod' with a unique project ID.
#
# PROJECT ID RULES (these fail silently if violated):
#   - Must be globally unique across ALL of Google Cloud
#   - 6-30 characters, lowercase letters, digits, hyphens only
#   - Must start with a letter, cannot end with a hyphen
#   - Example: sgtm-curlyhair-prod
#
# BILLING ACCOUNT ID FORMAT:
#   - Looks like XXXXXX-XXXXXX-XXXXXX (3 segments of 6 chars, hyphenated)
#   - Run 'gcloud beta billing accounts list' first to see yours
#   - Replace BILLING_ACCOUNT_ID below with that value
# ============================================================

# Set your project ID (must be globally unique, follow rules above)
PROJECT_ID="sgtm-yourbrand-prod"

# Create the project
gcloud projects create $PROJECT_ID --name="sGTM Production"

# Set it as the active project
gcloud config set project $PROJECT_ID

# List your billing accounts to find the ID
gcloud beta billing accounts list

# Link the billing account (replace BILLING_ACCOUNT_ID with your actual ID,
# format: XXXXXX-XXXXXX-XXXXXX from the list above)
gcloud beta billing projects link $PROJECT_ID \
  --billing-account=BILLING_ACCOUNT_ID

Step 3: Enable required Google Cloud APIs

Three APIs need to be enabled before Cloud Run will accept the GTM container deployment: Cloud Run itself, Cloud Build (used internally), and Compute Engine (needed for the load balancer in Step 6).

# ============================================================
# STEP 3: Enable the APIs Cloud Run needs
# ============================================================
# NO CUSTOMIZATION NEEDED. Run as-is.
# Takes 30-60 seconds to complete.
# ============================================================

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  compute.googleapis.com

Step 4: Deploy the GTM preview server first

Counter-intuitive but critical: deploy the preview server before the tagging server. The tagging server needs to know the preview server’s URL at deploy time (via the PREVIEW_SERVER_URL environment variable), so the preview server has to exist first. Most setup guides get this order wrong, which is why preview mode breaks for 80% of people who self-deploy on Cloud Run.

# ============================================================
# STEP 4: Deploy the GTM PREVIEW server (deploy this BEFORE tagging server)
# ============================================================
# WHERE TO RUN: Your local terminal, in the project you created
#
# CUSTOMIZE BEFORE DEPLOYING:
#   1. CONTAINER_CONFIG: Replace 'YOUR_GTM_CONFIG_STRING' with the
#      Container Configuration string from your GTM Server container.
#      Find it at: GTM → your server container → Admin →
#      Container Settings → Container Configuration
#      (looks like: aWQ9R1RNLVhYWFhYWCZlbnY9MSZhdXRoPWFiYzEyMw==)
#      The string is base64 and ends in == padding. The quoting and
#      ^@^ delimiter below handle this safely.
#
#   2. --region: Change 'us-central1' if your customers are not US-based.
#      Options: europe-west1 (EU), asia-northeast1 (Asia), etc.
#      Use the SAME region for preview and tagging server.
#
# IMPORTANT:
#   - The preview server gets RUN_AS_PREVIEW_SERVER=true and CONTAINER_CONFIG.
#   - It does NOT get PREVIEW_SERVER_URL. That goes on the tagging server only.
#   - min-instances=0 is fine here; preview server is only used by developers
#     when debugging in GTM Preview Mode.
# ============================================================

# Paste your Container Configuration from GTM Server here
CONTAINER_CONFIG="YOUR_GTM_CONFIG_STRING"

# Deploy the preview server (RUN_AS_PREVIEW_SERVER=true marks it as preview)
gcloud run deploy gtm-server-preview \
  --image=gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --platform=managed \
  --region=us-central1 \
  --allow-unauthenticated \
  --set-env-vars="^@^CONTAINER_CONFIG=${CONTAINER_CONFIG}@RUN_AS_PREVIEW_SERVER=true" \
  --min-instances=0 \
  --max-instances=2 \
  --memory=512Mi \
  --cpu=1 \
  --port=8080 \
  --timeout=60

After this command completes, gcloud prints the preview server’s URL (looks like https://gtm-server-preview-xxxxx-uc.a.run.app). We need that URL for the next step. The safest way to grab it programmatically:

# Capture the preview server URL into a shell variable for use in Step 5
PREVIEW_SERVER_URL=$(gcloud run services describe gtm-server-preview \
  --region=us-central1 \
  --format='value(status.url)')

# Verify it's captured correctly
echo "Preview server URL: $PREVIEW_SERVER_URL"

Step 5: Deploy the GTM tagging server with the preview URL

Now deploy the tagging server with PREVIEW_SERVER_URL pointing at the preview server you just created. This is the server that receives production traffic from your store’s browser pixel.

# ============================================================
# STEP 5: Deploy the GTM TAGGING server (after preview server exists)
# ============================================================
# WHERE TO RUN: Same terminal session as Step 4 so $CONTAINER_CONFIG
# and $PREVIEW_SERVER_URL are still set.
#
# CUSTOMIZE BEFORE DEPLOYING:
#   1. --region: Use the SAME region as Step 4 to avoid cross-region
#      latency between tagging and preview servers.
#
#   2. --min-instances=1: Production setting. Prevents cold starts
#      that would drop the first event of each idle period.
#      Set to 0 only for testing where cost matters more than reliability.
#
#   3. --max-instances=100: Sized for ecommerce Black Friday / flash sale
#      traffic. For steady B2B traffic, reduce to 10-20 to cap cost ceiling.
#      For enterprise high-traffic sites, increase to 500-1000.
#
#   4. --memory=1Gi: Google's recommended memory for production sGTM under
#      sustained load. 512Mi works for low traffic but causes OOM crashes
#      during traffic spikes with many tags firing per request.
#
#   5. --no-cpu-throttling: Critical for low-latency tag processing. Default
#      Cloud Run throttles CPU between requests, which adds 50-200ms latency
#      to the first request after an idle period. For ad platform APIs that
#      have their own latency budgets, this matters.
#
#   6. --concurrency=20: Lower than Cloud Run's default of 80 because GTM
#      Server tag processing is CPU-bound, not I/O-bound. 20 concurrent
#      requests per instance gives better p95 latency than 80.
#
# IMPORTANT:
#   - The tagging server gets CONTAINER_CONFIG and PREVIEW_SERVER_URL.
#   - It does NOT get RUN_AS_PREVIEW_SERVER. Setting both would break
#     preview mode silently.
# ============================================================

# Deploy the tagging server pointing at the preview server URL
# Production-grade flags: 1GiB memory (Google's recommended for sGTM under load),
# no-cpu-throttling so requests process at full speed even on idle instances,
# max-instances=100 for ecommerce traffic spikes (Black Friday, flash sales),
# concurrency=20 because GTM tag processing is CPU-bound and lower concurrency
# gives better p95 latency than the Cloud Run default of 80.
gcloud run deploy gtm-server \
  --image=gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --platform=managed \
  --region=us-central1 \
  --allow-unauthenticated \
  --set-env-vars="^@^CONTAINER_CONFIG=${CONTAINER_CONFIG}@PREVIEW_SERVER_URL=${PREVIEW_SERVER_URL}" \
  --min-instances=1 \
  --max-instances=100 \
  --memory=1Gi \
  --cpu=1 \
  --no-cpu-throttling \
  --concurrency=20 \
  --port=8080 \
  --timeout=60

Step 6: Map a custom domain to Cloud Run

By default, Cloud Run gives you a URL like gtm-server-xxxxx-uc.a.run.app. You need to map this to your custom subdomain (sgtm.yourdomain.com) because ad blockers maintain hard-coded blocklists for Cloud Run default domains. There are two ways to do this. The Load Balancer approach (Option B below) is the recommended production path because it works in every Cloud Run region and gives you better performance, edge caching, and DDoS protection. The Domain Mapping approach (Option A) is simpler but Google has been deprecating it for new regions since 2024, so check region availability before relying on it.

# ============================================================
# STEP 6 (Option A): Cloud Run Domain Mapping (legacy, simpler)
# ============================================================
# AVAILABLE IN: Limited regions only. Google has stopped enabling
# Domain Mapping in newer regions since 2024. Check availability at
# cloud.google.com/run/docs/mapping-custom-domains#limitations
# BEFORE relying on this path.
#
# RECOMMENDED USE: Quick test deployments, dev environments only.
# For production, skip to Option B (Load Balancer).
#
# CUSTOMIZE BEFORE DEPLOYING:
#   1. Replace 'sgtm.yourdomain.com' with your actual subdomain.
#   2. Verify domain ownership at Google Search Console first
#      (search.google.com/search-console → Add property → verify
#      via DNS TXT record). Without verification this command fails
#      with PERMISSION_DENIED.
# ============================================================

# Map your custom domain to the tagging server
gcloud beta run domain-mappings create \
  --service=gtm-server \
  --domain=sgtm.yourdomain.com \
  --region=us-central1

# gcloud will print DNS records you need to add at your DNS provider
# (typically 4 A records and 1 AAAA record pointing at Google's IPs)

For production deployments at any meaningful traffic level, use the Load Balancer approach below instead. It works in all regions and survives Google’s continued deprecation of Domain Mapping.

# ============================================================
# STEP 6 (Option B): Cloud Load Balancer with custom domain
# ============================================================
# WORKS IN: All Cloud Run regions.
# RECOMMENDED FOR: Production deployments at any meaningful scale.
#
# CUSTOMIZE BEFORE DEPLOYING:
#   1. Replace 'sgtm.yourdomain.com' with your actual subdomain.
#   2. Replace 'sgtm-yourbrand' in the resource names with your brand
#      (used as a prefix so multiple sGTM containers in the same
#      project don't collide).
# ============================================================

# Reserve a global static IP
gcloud compute addresses create sgtm-yourbrand-ip \
  --global \
  --ip-version=IPV4

# Get the IP address (note it down for DNS later)
gcloud compute addresses describe sgtm-yourbrand-ip --global

# Create a serverless NEG pointing at your Cloud Run service
gcloud compute network-endpoint-groups create sgtm-yourbrand-neg \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-service=gtm-server

# Create a backend service
gcloud compute backend-services create sgtm-yourbrand-backend \
  --global \
  --load-balancing-scheme=EXTERNAL_MANAGED

# Add the NEG as a backend
gcloud compute backend-services add-backend sgtm-yourbrand-backend \
  --global \
  --network-endpoint-group=sgtm-yourbrand-neg \
  --network-endpoint-group-region=us-central1

# Create a URL map
gcloud compute url-maps create sgtm-yourbrand-urlmap \
  --default-service=sgtm-yourbrand-backend

# Create a managed SSL certificate (auto-renews every 90 days)
gcloud compute ssl-certificates create sgtm-yourbrand-cert \
  --domains=sgtm.yourdomain.com \
  --global

# Create the HTTPS proxy
gcloud compute target-https-proxies create sgtm-yourbrand-https-proxy \
  --url-map=sgtm-yourbrand-urlmap \
  --ssl-certificates=sgtm-yourbrand-cert

# Create the forwarding rule that ties it all together
gcloud compute forwarding-rules create sgtm-yourbrand-forwarding-rule \
  --global \
  --target-https-proxy=sgtm-yourbrand-https-proxy \
  --address=sgtm-yourbrand-ip \
  --ports=443

Step 7: Point DNS at the load balancer and verify

Add an A record at your DNS provider pointing your sgtm subdomain at the static IP from Step 6:

Wait 10-20 minutes for SSL certificate provisioning. Google-managed certificates can take up to an hour the first time. Then verify with curl:

curl -I https://sgtm.yourdomain.com/healthy

# Expected output:
# HTTP/2 200
# content-type: text/plain

A 200 OK means your Cloud Run server side GTM hosting is live and ready. If you get an SSL error, the certificate is still provisioning. Check status with:

gcloud compute ssl-certificates describe sgtm-yourbrand-cert --global

The certificate should show managed.status: ACTIVE. If it shows PROVISIONING, wait another 15 minutes. If it shows FAILED_NOT_VISIBLE, your DNS A record isn’t propagating yet.

How do you set up server side GTM hosting on Taggrs?

Setting up server side GTM hosting on Taggrs follows the same pattern as Stape but through Taggrs’s interface: (1) create a free Taggrs account at taggrs.io, (2) click Create new container and paste your GTM Server Container Configuration string, (3) add your custom subdomain inside the Taggrs container settings, (4) add the CNAME record at your DNS provider pointing at the Taggrs target, (5) wait 5-15 minutes for SSL provisioning. Total time is 15-20 minutes, essentially identical to Stape.

Where Taggrs setup differs from Stape

Two practical differences. First, Taggrs’s free tier covers 10,000 requests just like Stape’s, but Taggrs’s Basic paid plan jumps straight to 750,000 requests for €22/month, so you skip the awkward middle tier. Second, Taggrs’s CNAME target is cname.taggrs.io instead of cname.stape.io, but everything else about the DNS configuration is identical including the Cloudflare proxy must-be-off rule.

How much does server side GTM hosting cost per month?

Server side GTM hosting costs $17 per month on the low end (Stape Basic for small stores) and $400+ per month on the high end (Google Cloud Run for high-traffic sites). The honest math depends on monthly request volume rather than monthly sessions or revenue. As a rule of thumb, multiply your monthly sessions by 10 to estimate monthly requests, because each session typically generates ~10 GTM Server requests across page views, product views, add-to-carts, and checkout events.

Quick request volume estimator

Use this formula to estimate your monthly server-side GTM request volume before picking a plan:

# ============================================================
# Monthly Request Volume Estimator
# ============================================================
# Use this to size your hosting plan correctly.
# Numbers below are typical for a Shopify store with
# GA4 + Meta CAPI + Google Ads server-side tags.

monthly_sessions = 50000          # Your monthly sessions from GA4

# Typical request multipliers per session (adjust if you know yours)
page_views_per_session = 4        # Most stores: 3-6
events_per_session = 6            # PDP views, ATCs, etc: 4-10

# Total monthly requests
total_requests = monthly_sessions * (page_views_per_session + events_per_session)
# For 50,000 sessions: 50000 * 10 = 500,000 requests/month

Cost by traffic tier

The hidden costs everyone forgets

Stape and Taggrs prices are all-in: hosting, SSL, custom domain, logs, auto-scaling, updates. Cloud Run has hidden line items that can double your bill if you don’t account for them. The biggest hidden costs on Cloud Run are: load balancer fees ($18 per month per forwarding rule, plus per-GB egress charges), Google-managed SSL certificate fees (free up to 50 certificates, then $5/month each), Cloud Logging ingestion costs if you log every request (typically $10-30/month at moderate traffic), and Cloud Run egress bandwidth (the data going out to ad platforms, typically $5-20/month). For a fair comparison, add roughly $30-50/month to any Cloud Run estimate.

Which server side GTM hosting is best for your store size?

The right server side GTM hosting depends mostly on your monthly traffic and your team’s engineering capacity. Stape is the best default for stores under 5M monthly requests with no full-time DevOps engineer. Cloud Run becomes more economical above 5M requests if you have engineering bandwidth to manage it. Taggrs is the right choice if EU data residency matters for your customers or compliance posture.

What are common server side GTM hosting mistakes?

The most common server side GTM hosting mistakes we see across audits are: leaving Cloudflare proxy enabled on the sgtm CNAME, using the default Cloud Run URL instead of a custom domain (ad blockers block it on sight), under-sizing the Stape plan and hitting tier limits during traffic spikes, deploying Cloud Run without the Preview Server, and forgetting to set up CORS on the GTM Server Client. Each one wastes either money or data, and most are fixable in under 30 minutes once identified.

Mistake 1: Cloudflare orange cloud is on for the sgtm subdomain

When Cloudflare’s proxy is enabled on a CNAME pointing at Stape or Taggrs, Cloudflare intercepts the SSL handshake before it reaches the hosting provider. The container appears unreachable, healthy checks fail, and no events get through. The fix is to toggle off the orange cloud icon for the sgtm record specifically (leave it on for your main domain). Browser tracking immediately starts working again.

Mistake 2: Using the default *.run.app domain in production

Cloud Run gives every service a default URL like gtm-server-abc123.uc.a.run.app. Ad blockers including uBlock Origin and Brave’s built-in blocker have these patterns hard-coded in their blocklists. If you point your browser pixel at the default URL, 25-40% of your traffic is blocked before it reaches the container. Always set up a custom domain (Step 6 above) before going to production.

Mistake 3: Under-sizing the Stape plan

Stape’s lower tiers have hard request caps. When you exceed the cap, Stape stops accepting events until the next billing cycle or until you upgrade. We’ve seen Black Friday days where stores on the wrong plan dropped 60%+ of their events because traffic spiked past the cap by 9am. The fix is to enable Stape’s auto-upgrade toggle in container settings so the plan bumps up automatically when traffic exceeds the cap. The marginal cost of one tier higher is always less than the cost of dropped conversions.

Mistake 4: Skipping the Cloud Run preview server

Cloud Run deployments often skip the preview server because it’s not required for production traffic to flow. The problem hits when you try to debug a tag in GTM Server’s Preview Mode and nothing shows up. The Preview Server is a separate Cloud Run service that GTM Server uses for live debugging. Without it, you’re flying blind during setup. Always deploy both services, with preview-server first so the tagging server can reference its URL via the PREVIEW_SERVER_URL environment variable.

Mistake 5: No CORS handling on the GTM Server Client

The GTM Server Client Template that receives events from your browser pixel needs to handle CORS preflight (OPTIONS) requests. Without it, browsers reject the actual POST request before it reaches your server. We cover the correct CORS-handling client template in our Shopify server side tracking setup guide, including the full code you can paste directly into your GTM Server container.

How do you migrate between server side GTM hosting providers?

Migrating between server side GTM hosting providers takes 30-60 minutes if planned properly and zero downtime if you stage it correctly. The key insight is that your GTM Server container configuration is independent from your hosting provider. The same Container Configuration string deploys identically across Stape, Cloud Run, and Taggrs. Migration means deploying the same container to a new host and switching DNS, not rebuilding your tag setup.

The zero-downtime migration sequence

First, deploy your existing Container Configuration to the new hosting provider (Stape, Taggrs, or Cloud Run) using the steps above. The new host won’t receive traffic yet because DNS still points at the old one. Next, configure custom domain on the new host using a temporary subdomain like sgtm-new.yourdomain.com and verify it’s working with the same curl health-check. Then, update DNS to point your real sgtm.yourdomain.com at the new host. DNS propagation takes 5-60 minutes depending on your TTL. Finally, monitor both old and new hosts during propagation, then decommission the old host once traffic fully migrates.

What you can’t migrate easily

Three things don’t transfer cleanly between hosts. Stape Power-Ups (Meta CAPI Gateway, custom client templates from their library) are Stape-specific and need to be reconfigured on the destination. Custom client templates you wrote yourself transfer fine since they live inside the GTM Server container config. Logs and event history stay with the old provider, so export anything you need before decommissioning.

Why choose Hustle Marketers for server side GTM hosting setup?

Hustle Marketers has deployed server side GTM hosting across all three platforms (Stape, Google Cloud Run, Taggrs) for ecommerce clients ranging from Shopify stores doing $50K/year to enterprise accounts spending $200K+/month on Google Ads and Meta. We make the hosting choice for you based on your traffic and engineering profile, deploy the full stack including custom domain SSL and CORS-handling Client Templates, and connect the server container to GA4, Meta CAPI, Google Ads Enhanced Conversions, and TikTok Events API in one pass. Typical setup time is 4-8 hours of agency work versus 2-4 weeks of in-house engineering learning curve.

Our Curly Hair Brand UK case study documents the 15.25x Shopify ROAS we delivered partly through proper server-side tracking on Stape, and our Pet Accessories case study shows $346K in revenue at 5.12x ROAS on a Cloud Run deployment we built for the client. Both used the same fundamentals covered in this guide. We’re a Google Partner and Meta Business Partner with $780M in trackable revenue across 2,500+ ecommerce brands since 2013, and our Shopify-specific work continues at scale through our Shopify marketing service.

If you want to skip the multi-week DIY path, get in touch for a free server-side audit. We’ll tell you which hosting provider fits your store, what your tracking gaps look like today, and how much conversion recovery you can expect from a proper setup.

Conclusion

Server side GTM hosting comes down to three real choices in 2026: Stape for most stores under 5M monthly requests, Google Cloud Run for high-traffic sites with engineering teams, and Taggrs for EU-focused stores prioritizing data residency. Pick wrong and you either overpay (Cloud Run for small stores) or under-deliver during traffic spikes (under-sized Stape plans). Pick right and you build a tracking foundation that recovers 25-45% of conversions client-side pixels miss, which compounds into materially better ROAS across every ad platform you run.

If you’re setting up server-side tracking from scratch on a Shopify store, our Shopify server side tracking guide walks through the full stack including the production-ready Custom Pixel JavaScript and GTM Server Client Template. For Performance Max specifically, our PMax checklist covers the conversion-tracking signals that matter most.

Frequently asked questions about server side GTM hosting

Is Stape better than Google Cloud Run for server side GTM hosting?

Stape is better than Google Cloud Run for stores under 5M monthly requests because Stape’s flat-rate pricing is cheaper and its managed UI removes ops overhead. Cloud Run is better above 5M requests where per-request pricing wins and engineering teams want full control.

How much does server side GTM hosting cost per month?

Server side GTM hosting costs $17-20 per month at the entry level (Stape Basic), $50-150 per month for medium-traffic stores, and $200-400+ per month for high-traffic sites. The honest cost depends on monthly request volume, not store revenue.

Can I host server side GTM for free?

Yes, both Stape and Taggrs offer free tiers covering 10,000 requests per month, which is enough for testing or very low-traffic sites. Google Cloud Run has a free tier too, but it covers only the first 2 million requests across all your Cloud Run services combined.

What is the cheapest server side GTM hosting option?

Stape Basic at $17-20 per month is the cheapest production-ready server side GTM hosting option. Taggrs Basic at €22 per month covers more requests for slightly more money. Both beat self-hosted Cloud Run at production traffic levels.

Does Stape work for Shopify server side tracking?

Yes, Stape is the most common hosting choice for Shopify server-side tracking because it deploys in 15-20 minutes through their UI and handles SSL provisioning automatically. Pair it with a Shopify Custom Pixel that posts events to your Stape subdomain.

How fast is server side GTM hosting setup?

Setup takes 15-20 minutes on Stape or Taggrs (managed UIs handle everything), versus 60-90 minutes on Google Cloud Run (gcloud CLI deployment plus load balancer setup). DNS propagation adds 5-60 minutes regardless of provider.

Do I need a custom domain for server side GTM hosting?

Yes, you need a custom subdomain like sgtm.yourdomain.com. The default Cloud Run, Stape, and Taggrs URLs are all blocked by major ad blockers including uBlock Origin and Brave. A custom domain on your own brand is the only setup that survives ad-blocker scrutiny.

What happens if I exceed my Stape plan’s request limit?

If you exceed your Stape plan’s request limit, Stape stops accepting events until either the next billing cycle starts or you upgrade your plan. Enable the auto-upgrade toggle in container settings to bump tiers automatically during traffic spikes.

Can I switch from Stape to Google Cloud Run later?

Yes, switching hosting providers takes 30-60 minutes with zero downtime if planned properly. Deploy your existing GTM Server Container Configuration to the new host, verify it works on a temporary subdomain, then switch DNS to point at the new host. Power-Ups specific to Stape need to be reconfigured on the destination.

Does Cloudflare work with Stape server side GTM hosting?

Cloudflare DNS works perfectly with Stape, but the Cloudflare proxy (orange cloud icon) must be disabled for the sgtm CNAME record. The proxy intercepts SSL handshakes and breaks the connection. Set the record to DNS only mode.

Why does my Cloud Run sGTM cost more than expected?

Cloud Run sGTM costs more than expected when you forget the hidden line items: load balancer forwarding rule fees, Cloud Logging ingestion costs, SSL certificate fees above the first 50, and egress bandwidth charges. Add $30-50 per month to any base Cloud Run estimate for these.

What is the GTM Server preview server and do I need it?

The GTM Server preview server is a separate Cloud Run service that GTM Server uses for live debugging in Preview Mode. You need it during setup and tag development. It can run at min-instances=0 to save cost since it’s only active when developers are debugging.

How many requests will my Shopify store generate per month?

A typical Shopify store generates roughly 10 GTM Server requests per session across page views, product views, add-to-cart, and checkout events. Multiply your monthly sessions by 10 for a baseline estimate, then adjust upward if you track many custom events.

Should agencies use Stape or Google Cloud Run for client work?

Agencies should use Stape for most ecommerce client work because the managed UI lets your team manage multiple client containers from one dashboard, and pricing is predictable per client. Reserve Cloud Run for enterprise clients with dedicated engineering teams.