Stape: hosting server-side Google Tag Manager without your own cloud server

Stape is a platform that hosts the server container of Google Tag Manager for you. Instead of setting up a server on Google Cloud Run yourself, you paste your server container’s configuration into Stape, choose a server location and connect a subdomain of your own website. Your tags then send their data to that server first, which forwards it to GA4, Google Ads, Meta or LinkedIn. Stape has a free plan for small volumes and paid plans based on the number of requests.

This article is about the hosting choice and the practical setup. What server-side tagging is and why it makes your measurement more resilient is covered in our guide to server-side tagging and, specifically for advertising, in server-side tracking for Google Ads.

What exactly does Stape do?

Server-side Google Tag Manager has two containers: the regular web container in the browser and a server container that runs on a server. That server has to live somewhere. Google’s standard route is Google Cloud Run in your own cloud project. Stape offers the same as a managed service, with extras on top:

• Hosting of the server container in a region of your choice, with scaling without managing servers yourself.
• Custom domain connection, so your server runs on a subdomain of your own site.
• Power-ups such as a custom loader (loading GTM through your own domain), a global CDN and Own CDN, where your server domain runs through the same IP address as your website.
• Templates and connectors for the Meta Conversions API, Google Ads and LinkedIn, among others.

What does Stape cost?

Stape charges per month based on the number of requests your server container processes. According to Stape’s pricing page (checked on 6 October 2026, in US dollars, with annual billing):

These are the vendor’s prices, not ours. A request is every hit your server receives: a page view, an event, a script load. A B2B site with 20,000 visits a month and a handful of events per visit quickly goes over the free plan.

Stape or Google Cloud Run?

In its Cloud Run setup guide, Google describes running at least 2 instances in production to limit data loss during an outage, and says each server costs approximately 45 dollars per month. A production setup on Cloud Run therefore starts at around 90 dollars per month, plus your own time for management.

The shorter log retention is the point that comes up most in practice. Logs are your evidence when a conversion value is unrealistically high or an event arrives twice. With 3 days of logs you have to be quick. If you have an IT department that already works on Google Cloud, Cloud Run may make more sense.

Setting up Stape in six steps

1. Create a server container in GTM. In Tag Manager, create a new container with “Server” as the target platform and copy the container configuration.
2. Create the container at Stape. Paste the configuration and choose a server location, preferably in the EU for Belgian and Dutch sites.
3. Connect a custom domain. Stape says it literally in its setup guide: use a custom domain to set first-party cookies, on the same root domain as your website, for example sst.yourcompany.com. You add the DNS records Stape shows you; verification usually takes 2 to 3 hours, sometimes up to 72 hours.
4. Point your web container to the server. In your web container, set the server_container_url parameter in the Google tag to your subdomain. Your GA4 hits then go to your own server instead of directly to Google.
5. Build your server tags. In the server container, add the GA4 tag, the Google Ads conversion tag, and connectors such as the Meta Conversions API. Every tag gets the same consent logic as in the browser.
6. Test and publish both containers. Preview the web container and the server container together and check that every event arrives once.

The mistakes we see most often

• No custom domain. The server runs on Stape’s default domain. Then you set no first-party cookies and lose the biggest benefit.
• Duplicate conversions in Meta. You send a Lead event through the pixel and through the Conversions API, without the same event_id. Meta only deduplicates when event_id and the event name match within 48 hours. This is the classic cause of duplicate purchases or leads after a move to server-side.
• Skipping consent. Server-side feels like “outside the browser, so outside the banner”. That is not true: on your server, too, you only forward what the visitor allowed. Pass your consent state, for example from Cookiebot, along with every event.
• Forwarding personal data unfiltered. On your server you can strip IP addresses and parameters before sending data to a platform. Do so.
• Not looking at the logs. If you see a strange conversion value, check the logs within your plan’s retention period.

How do you check that it works?

Then compare the leads in Google Ads, Meta and your CRM for a week. Server-side tagging usually delivers a more complete signal, but you have to see the difference in your own data, not in a promise. It also helps to send qualified leads back through offline conversions from your CRM.

Need help with server-side tagging?

Server-side tagging touches GTM, consent, your ad platforms and your DNS at the same time. At Kaizo we built the chain for GA4, Google Ads and Meta; read the setup. At Suivo, lead tracking ran all the way into the CRM. Not sure whether server-side makes sense for you? Start with a tracking audit. If you want it built on Stape or Cloud Run, our tracking specialist does it. Pricing on request.

Frequently asked questions