Server-Side GTM Running on Your Own Infrastructure

Safari caps any cookie written from JavaScript at seven days, and it applies the same cap when a first-party subdomain is a CNAME pointing at a vendor. A cookie issued by your own endpoint, on your own DNS, from infrastructure you hold the billing account for, is not covered by that cap. That is the whole engineering argument for running the server container yourself, and it is worth doing only if you actually run it yourself. Where it runs: Cloud Run in europe-west3 (Frankfurt) on Google's tagging server image, pinned to a version we upgrade deliberately, or on your own hosts if your platform team prefers to keep everything in one place. Minimum instances set so a cold start does not eat a burst of events at the start of a campaign; concurrency and CPU sized from your real request volume, not from the default. A separate preview server, reachable only internally. A custom subdomain on your DNS with your certificate — gtm.yourbrand.de, not a vendor's domain wearing your name. For the shops we run, this costs roughly EUR 150 to 400 a month in compute at two to six million monthly events. We tell you the figure before you commit, and we would rather you knew it than discovered it. What we configure on it: The GA4 client and first-party cookie issuance with Set-Cookie and HttpOnly. Conversions API tags running server-side with event deduplication against the browser layer. A transport URL that fails closed rather than silently dropping. A logging policy that is written down: request payloads containing identifiers do not go to Cloud Logging, retention is set explicitly, and log-based metrics carry no personal data. This is the part most server-side builds skip, and it is the part that surfaces in the first audit. Monitoring you can hold someone to: uptime check, 5xx and latency alerting, request volume anomaly detection that catches the failure where the endpoint is healthy but the browser stopped sending. What a server container is not for: It does not create a legal basis. Moving a request from the browser to your server changes the transport, not the processing, and anyone selling it as a consent workaround is selling you a finding at your next audit. We will not use it to disguise a third party as first party in order to evade tracking protection while telling users something else in the banner. We will not send events for users who declined. The container respects the consent signal at the server too, and we test that path explicitly. We will not run it inside our own Google Cloud project. You own the project, the domain and the billing account. If you replace us, you change one IAM role, not your measurement stack. Ongoing operation: Available as a monthly retainer covering version upgrades, incident response against an agreed response time, cost review, and the measurement engineering that keeps arriving — a new market, a new payment provider, a platform changing its event requirements. Two mornings a month go to reviewing what actually happened rather than waiting for a ticket. Who this is not for: Shops below roughly one million monthly events, where the tracking gain does not repay the operational surface you are taking on, and we will tell you that in the first call rather than after the invoice. Teams with no one on call for their own infrastructure. Anyone who wants us to host it as a black box; that arrangement is comfortable until the day it is not. Runbook, alert definitions and architecture documentation in English or German, in your repository.