Server-side tag managers guide

Server-side tag managers: ssGTM, Stape, Addingwell, HTTP-only

Server-side tracking is now mainstream, but the implementation choices are still easy to blur together. Teams hear “move it server-side” and assume the answer must be a GTM server container, a managed host, or a complex proxy layer. In practice there are four real options: self-hosted ssGTM, a managed ssGTM host like Stape, a managed ssGTM host like Addingwell, or skipping the tag manager entirely and sending events over HTTP from your own backend. The right choice depends less on vendor branding and more on who will operate the system after launch.

Comparison

4 main options

These four models all move tracking away from a browser-only dependency, but they do not create the same operating burden. Comparing them clearly is useful because people often mix up “hosted ssGTM” with “direct server tracking,” even though the first keeps GTM as the orchestration layer and the second does not.

Option	Model	Cost	Setup complexity	Maintenance
ssGTM self-hosted	Google Tag Manager server container on your own cloud infra	Low infra cost, high people cost	High	You own Cloud Run, DNS, preview workflows, templates, logs, and fixes
Stape managed ssGTM	Hosted server-side GTM with managed infrastructure	Moderate and request-based	Medium	Infra gets easier, but GTM tags, variables, and release discipline stay
Addingwell	Managed server-side GTM with extra ops and debugging tooling	Moderate and request-based	Medium	Less infra work, but container design, event mapping, and GTM QA remain
HTTP-only	Application or worker sends events directly from the server	Usually lowest total cost	Low to Medium	You maintain event contracts and destination logic, not a GTM runtime

Fit

When each wins

Choose self-hosted ssGTM when control is the primary goal

If your company already standardizes on Google Cloud, has GTM specialists, and expects custom server tags or unusual routing rules, self-hosted ssGTM is the most flexible option. The tradeoff is that your tracking stack becomes an internal application with real operating cost.

Choose Stape when you want GTM without running Cloud Run yourself

Stape is a good fit when the team is already bought into server-side GTM but does not want to spend time provisioning servers, managing scaling, or handling the rough edges of Google Cloud. It simplifies hosting, not the GTM model itself.

Choose Addingwell when GTM hosting plus operational polish matters

Addingwell lands in a similar place to Stape, but some teams prefer it for its plan structure, debugging workflow, and support posture. It still assumes GTM is the control plane, so the operating model remains tag-manager heavy.

Choose HTTP-only when the product already has a backend source of truth

If the authoritative events already happen in your app server, order service, CRM worker, or webhook layer, HTTP-only delivery is usually the cleanest answer. The request goes straight from your system to the routing layer with fewer abstractions, less preview-mode debugging, and fewer chances to drift.

Positioning

TrackLayer position

TrackLayer sits closest to the HTTP-only branch, but it is not just a thin forwarding proxy. The core philosophy is that most teams are better served by a direct event pipeline than by rebuilding tag-manager logic on the server. Your application or worker sends one canonical event over HTTP. TrackLayer validates it, enriches it, scores identifier quality, deduplicates it, and fans it out to the platforms that need it.

That makes TrackLayer an HTTP-only alternative plus the layers teams usually discover they still need after going direct: platform-aware schemas, delivery diagnostics, match quality visibility, dashboard views for event health, and a cleaner operational surface for marketing and engineering. The point is not to imitate GTM with fewer buttons. The point is to remove the need for a general-purpose server container when the business really wants trustworthy conversion delivery.

Schemas keep event names and payloads stable across destinations.

Match quality makes identity issues visible before campaign performance drops.

Dashboard workflows let operators inspect delivery without living in cloud logs or GTM preview.

Migration

Migration paths

The practical move away from a tag manager is rarely “rip and replace.” The safer approach is to move high-value business events first, preserve event IDs, compare destination acceptance, and only then remove the old routing layer. That keeps the migration centered on event truth instead of on a tool brand.

From ssGTM

Start by identifying which business events really need the container and which are only there because GTM was the default. Move purchase, lead, refund, and subscription events into one canonical HTTP event contract first. Keep the same event IDs during overlap, compare delivery, then retire container-owned routes destination by destination.

From Stape

The clean migration path is usually faster because hosting is no longer the problem. Inventory the current server container, list every destination it owns, map the event names into canonical TrackLayer events, then switch the destinations over after a short parallel validation window.

From Addingwell

Treat it the same way as any managed ssGTM migration: preserve the useful event taxonomy, remove dead tags, keep browser and server dedup consistent, and move the routing logic into a direct HTTP pipeline. The migration risk is almost always in event identity and consent, not in transport.

Economics

Cost projections

For a typical 10M-event month, the infrastructure bill is usually not the deciding variable. The operating model is. Still, it helps to put current public pricing and realistic infra assumptions in one place so the conversation starts from actual ranges instead of folklore.

Option	10M-event / mo projection	Notes
ssGTM self-hosted	$120–$220 / mo	Inference: Google documents about $45 per Cloud Run server per month and recommends a minimum of 2 instances. Add load balancer, logs, and headroom for peak traffic.
Stape managed ssGTM	$167 / mo	Based on current public pricing where the Enterprise tier covers up to 20M requests per month, so a 10M-event scenario lands there.
Addingwell	€210 / mo	Based on current public pricing where the 12M requests plan is cheaper than stacking overages on the 5M plan for a 10M-event month.
HTTP-only	$0–$80 incremental infra	Usually rides on infrastructure you already run, such as app servers, workers, or edge functions. The real cost is engineering design, not a dedicated tag runtime.

The important reading is this: managed ssGTM hosts often look inexpensive on paper, self-hosted ssGTM can also look cheap if you count only Cloud Run, and HTTP-only often looks nearly free because it piggybacks on existing backend infrastructure. The true question is which model creates the smallest long-term mismatch between who owns tracking and who has to debug it on a bad day.

Decision

Decision tree

Branch 01

Do you already have people who are genuinely strong in GTM server containers?

Yes

Stay in the ssGTM lane and then choose between self-hosted, Stape, or Addingwell based on who should own infra.

Skip to HTTP-only first. Most teams without GTM specialists do better with a direct server event model.

Branch 02

Do you need arbitrary custom tags and container logic, or mostly reliable delivery to known platforms?

Yes

ssGTM remains the flexible option, especially if vendor logic changes often.

HTTP-only is usually the better fit because the event contract is clearer and the debugging surface is smaller.

Branch 03

Is cloud infrastructure ownership acceptable for this team?

Yes

Self-hosted ssGTM can make sense if control and compliance matter more than speed.

If you still want GTM, use a managed host like Stape or Addingwell. Otherwise go direct with HTTP-only.

Branch 04

Will marketers need to ship routing changes without touching application code?

Yes

That leans toward GTM-style server containers and a managed host.

That leans toward HTTP-only, where engineering owns a smaller and more durable integration surface.

FAQ

Common questions

Is HTTP-only the same thing as server-side tracking?

Yes. Server-side tracking is the category. A server-side tag manager is one way to implement it, but not the only way. Direct HTTP delivery from your backend is still server-side tracking.

When does ssGTM become overkill?

It becomes overkill when the team mainly needs dependable forwarding to common destinations but ends up operating clients, tags, variables, preview sessions, and cloud infrastructure anyway. If most of the work is maintenance instead of insight, the abstraction is too heavy.

Are request-based pricing plans actually expensive?

The infra line item often is not. The hidden cost is that request-based managed hosts still assume GTM expertise. As traffic grows, the hosting bill rises at the same time the operational burden stays with your team.

Can we keep browser GTM while moving server delivery to HTTP-only?

Yes. Many teams keep browser GTM for onsite scripts, consent banners, or lightweight frontend behavior while moving authoritative conversion delivery to a direct server path.

What is the real migration risk when changing server-side tracking stacks?

The risky parts are event identity, consent consistency, deduplication, and reporting continuity. Transport is rarely the hard part. The hard part is preserving one clean business event across the old and new systems during the cutover.

Next reads