Stape: What It Is, and How to Verify Your Server-Side Setup

What Stape is

Google Tag Manager server-side needs somewhere to run. Google’s default answer is deploying the container yourself on cloud infrastructure; Stape’s answer is doing that for you. You create a container, point a subdomain at it, and Stape operates the servers, scaling and monitoring underneath.

On top of raw hosting, Stape ships conveniences that would otherwise be manual work: custom loader delivery of the GTM script from your own domain, cookie management helpers, and integrations for common vendors.

Why teams choose managed hosting

In client projects the decision is rarely about price alone. Self-hosting a container means a Docker image or Cloud Run service, a deployment pipeline, and in larger companies a security and governance review before anything ships. That review is often the longest part of a server-side project.

Managed hosting compresses all of that to a DNS record. The trade-off is that your data transits through a third party, which your own compliance review may or may not accept. Both paths are legitimate; the right one depends on who in your organization owns infrastructure decisions.

What Stape does not decide for you

Hosting solves where the container runs. Everything that determines compliance and data quality still lives in your GTM configuration:

1. Consent forwarding. The consent state collected by your CMP must reach the server container and be evaluated before tags fire. Hosting does not do this for you.
2. Deduplication. If the same event leaves from the web container and the server container, vendors need a shared event identifier to merge them.
3. Cookie strategy. Serving the script first-party is not the same as setting HTTP cookies server-side; the second is what extends cookie lifetime under Safari ITP.
4. Vendor scope. Which platforms receive which events, with which parameters, remains your call and your responsibility.

The mistakes we actually find in audits

Recurring findings when we audit Stape-hosted (or any managed) server-side setups:

1. Consent state never forwarded: server-side tags fire for visitors who refused, which turns an infrastructure upgrade into a compliance incident.
2. Custom loader configured, cookies still set by JavaScript: the setup survives ad blockers but keeps dying at Safari’s 7-day cap.
3. Double conversions: web and server containers both send purchases with no shared identifier. GA4 will not deduplicate them for you.
4. Microsoft forgotten: Bing conversions stop silently when consent signals for Microsoft are not wired, and nobody notices for weeks because all eyes are on Google and Meta.
5. No re-testing after CMP updates: a banner update changes the consent data flow and quietly breaks conditions downstream.

How to verify a Stape-hosted setup

The checks are the same as for any server-side architecture, and none of them require access to the Stape account:

1. Private window, DevTools open. Before touching the consent banner, the Application tab should show no vendor cookies.
2. Network tab: the GTM script and the hits should load from your own subdomain, and responses should set HTTP cookies.
3. Refuse consent, then browse. No vendor requests should leave, from either container.
4. Accept consent, complete a test conversion, and confirm it appears once (not twice) in each vendor.

Our free tracking checker runs the passive part of this inspection on any URL in about a minute.

Frequently asked questions

Keep reading

• Server-side tracking: the full field guide
• Addingwell: what it is and how to verify your setup
• Free tracking checker