Standing the container up is the short part; running it every day is the commitment.

Standing up a server container means owning real infrastructure. We provision hosting, connect the custom domain, configure clients and routing, and hand over an environment your team can operate. You end up with a working server-side GTM container on your domain, supported by monitoring and an operating runbook rather than a one-time tutorial.

Plan server-side setup All Server-Side Tracking & First-Party Measurement tasks

Some of the 500+ brands we've worked with

See all references

We cover the infrastructure decisions that simplified server-side tagging tutorials usually leave out. Four stages move the setup from topology decisions to infrastructure your team can run day to day.

How we hold ourselves to it

Size the hosting to real traffic — We configure the cloud project, region, and autoscaling range around your actual traffic volume, sized to avoid both overpaying and falling over under load.
A subdomain that's genuinely yours — A subdomain you control points at the container, with certificates configured so every request resolves as first-party traffic on your own domain.
Clients that know where each request goes — GA4 traffic, GTM web-container data, and anything else arriving at the endpoint each need a configured client, and we route every one to the right tag.
Who can deploy, and what the endpoint accepts — We restrict deploy access to the container and lock the endpoint down to only the traffic it's actually supposed to receive.

Design the topology
We agree on hosting region, domain, expected traffic, and which flows move through the server container. The devOps lead approves cloud provider provisioning, custom domain DNS, and budget caps.
Architecture plan
Provision infrastructure
We set up the cloud project, container, domain, and certificates in a non-production environment first. You sign off before anything touches production traffic.
Provisioned environment
Test with real traffic
We shift a portion of traffic through the server path and confirm it reaches destinations correctly, at expected latency and cost. Engineering lead confirms latency and cost hold under full production traffic.
Traffic test log
Cut over and hand off
We move remaining traffic gradually, watch for issues, and hand you a runbook for day-to-day operation. Your ops owner confirms the runbook is usable.
Operating runbook

Provisioning the container is the easier half of the job

Automation generates the infrastructure templates, drafts the staging provisioning checklist, flags latency and cost spikes during the traffic test, and writes the runbook from what we watched at cutover. The gates are operational, so they belong to people: provisioning and budget caps get approved before anything is built, and nothing touches production traffic without a sign-off.

You receive production infrastructure together with the documentation needed to operate it.

Architecture document
Architecture record
What was provisioned, where, and why, domain, region, clients, and routing decisions.
QA notes
Traffic test evidence
What we tested during cutover and what latency, volume, and cost looked like.
Runbook
Operating runbook
How to monitor the container, what to check when something breaks, and who owns what.

We call it done when: requests reach their destinations through the server path under real traffic, latency and cost hold against the estimate, and a rollback has been rehearsed.

Server-side isn't a weekend project. These few questions tell you if your team is ready to run one long-term.

A good fit when

Your server-container decision is made, but the cloud project, custom domain, clients, and routing still need a production-ready build.
Browser restrictions are affecting collection, and you want a first-party endpoint on your own domain.
Cloud costs and monitoring continue after launch, but the team taking over still lacks an operating runbook and a named operations owner.

A crew hoisting a container onto a server-side platform, routing a first-party pipe

Better handled as other work when

You haven't decided whether server-side tracking is worth it for your setup yet, that's First-Party Tracking Architecture.
Your browser-side GTM container is what needs work, not a server one, that's GTM Web Container Architecture.

If one of these is closer to your situation, start here instead: All Server-Side Tracking & First-Party Measurement tasks

We call it done when: the cloud provisioning, the custom domain, and the budget caps are approved by whoever will pay for and operate them.

Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.

Google Tag Manager
where clients and routing get configured once the infrastructure underneath is standing
Stape
the managed hosting option that removes the DNS and TLS work from the client's plate
Google Cloud Run
the self-hosted alternative when the client wants the container on their own cloud account

Share your expected traffic and current setup. We will design and build the infrastructure, then hand it over with a practical operating model.

Plan server-side setup

Do we need this if our browser-based tracking already works?

Not automatically. Server-side tagging addresses specific needs such as ad blocking, first-party cookie durability, and control over data before it leaves your infrastructure. If those are not current problems, First-Party Tracking Architecture can help you weigh the added operational cost.

What ongoing costs should we expect?

Expect cloud hosting costs that scale with traffic, plus time for monitoring and maintenance. Most setups run on two to ten autoscaling instances, so cost moves up and down with your actual request volume. We estimate both from your real traffic before you commit. Once you're live, the operating runbook spells out what a normal cost range looks like, so a spike is obvious right away.

Can our existing agency manage this after you set it up?

Yes. The runbook is written so an agency with the right cloud and GTM access can take over day-to-day operation.

What cloud and DNS access is required?

We need someone who can create cloud resources, DNS access for the custom domain, and admin access to the GTM account.

By team

By industry

By tool

Server-Side GTM & Cloud Setup

From topology decision to a runbook your team runs

Design the topology

Provision infrastructure

Test with real traffic

Cut over and hand off

Evidence the container held up under real production traffic.

Architecture record

Traffic test evidence

Operating runbook