sGTM Container Capacity Maxed Out (200KB)

Google Tag Manager Server Container
1

After setting everything up in server Google Tag Manager, I’ve realized that I’ve maxed out the container max capacity which is 200KB. I am not sure why there is such a low space available for server GTM. I understand that space restriction for web GTM, but not for server.

This is what’s taking up the space:

Traffic Source Tags

TOTAL = 130.25KB

Other Tags

TOTAL = 22.7KB

Variables

TOTAL = 118KB

So if you sum all up, it goes beyond 200KB (270.95KB).

I am not sure about the space size the native variables take, but pretty sure is something around that size. And if you ask, yes, all these tags & variables are needed for the system to work. It is a complex system with multi-domain, click ID mapping, object & array mapping, webhooks, firestore and so on.

Taking into account that it is very rare that Google will increase the server GTM in the near future (although already submitted the feedback), the question is…what should I do in this situation?

Should I create a “main container” with some Traffic Source Tags and then a “secondary container” with the other Traffic Source Tags? That will imply having 2 different server GTM URLs to send data from webhooks. And maintaining 2 different containers with a lot of common variables.

2

you don’t have much choice, you either split it all into multiple containers like you outlined, or you tailor the webhook payload to contain things you need and in format you need, thus eliminating the necessity of that many variables.

3

So weird.

I don’t think ED and constants have a large value.

I agree with @Dan, maybe adjust the payload of the webhook to less heavy work.

I would prob look at the variables:
You have alot of lookup tables, might be worth custom writing a tag to process or something.

4

I would like to reopen the discussion on this topic and whether the options changed after 2 years since it was published.

We have an offline e-commerce setup and we are reaching the GTM container limits. The Stape Google data manager template + 1 tag itself took 20% of the capacity.

@adsmedia can you pls post your experience with multicontainer setup, how does it work for you over time?

@Dan We use Stape Store to handle the offline conversion attribution, so in our case if e.g. divide our setup to 2 containers (e.g. all web based events into one and offline conversion into other), we need to 2 Sores setup and synchronization between them, right?

5

hey @ludoja, if you go the split container route, both Stape Writer and Stape Lookup can talk to collections in different containers (see below), so you can still keep all of your storage in one

Screenshot 2026-04-20 at 16.04.22
Screenshot 2026-04-20 at 16.04.22683×449 39.9 KB

6

Thanx, just to make it clear. When creating new container do I need to create also new datapoint and send data twice, or can the containers share the datapoint, where I send the data from our CRM.

Similar question for containers events allocation/subscriptions - is it possible to pool limits those containers or do I need separate subscriptions for them?

7

From what I’ve seen running multi-container setups: each container exposes its own endpoint, so by default your CRM webhook would need to point to the specific container handling offline conversions. You can duplicate the call or set up explicit routing, but that’s added complexity you’d want to justify.

On the subscription side, in standard Stape setups event allocations are billed per container and don’t pool across them. Worth factoring that in before you split.

Before going multi-container, I’d audit what’s actually eating capacity. Heavy templates, transformation logic, and legacy tags that nobody cleaned up — I’ve seen setups where 30-40% of container size was stuff that could be consolidated or removed. That’s cheaper to fix than managing cross-container debugging long-term.

One thing people underestimate with multi-container: you lose unified debugging visibility, and if the same event hits both containers you need to handle deduplication explicitly. That operational overhead adds up fast.

8

From what I’ve seen running multi-container setups: each container exposes its own endpoint, so by default your CRM webhook would need to point to the specific container handling offline conversions. You can duplicate the call or set up explicit routing, but that’s added complexity you’d want to justify.

Because offline is not dependant on first-party domain so much (since you operate with payloads not headers mostly), you can externalise offline as function to a separate container using natively provided Stape endpoint, so it remains agnostic to DNS records.

What sync is required between the two (ideally little) can be achieved via shared Stape Store, as already discussed higher-up this thread.

On the subscription side, in standard Stape setups event allocations are billed per container and don’t pool across them. Worth factoring that in before you split.

Very valid, there’s an abundance of factors here: your feature requirements, current usage and how the separation of responsibilities between the two is approached.

Before going multi-container, I’d audit what’s actually eating capacity. Heavy templates, transformation logic, and legacy tags that nobody cleaned up — I’ve seen setups where 30-40% of container size was stuff that could be consolidated or removed. That’s cheaper to fix than managing cross-container debugging long-term.

This should undeniably be the first step, thanks for outlining it so well.

Your biggest consumer are still templates though, mostly tags, which I believe is the case with @ludoja, and amount of those is largely informed by destination requirements. So externalising something that is not directly dependant on cookies coming in in headers and doesn’t have to return a cookie back, such as offline is a feasible approach. With some tinkering, things like Klaviyo (or other ESP) could be moved to a separate container as well.

Another possible approach is to start butchering the templates to remove things that are not utilised in your particular setup. Think automatic data parsing functions, logs - you are loosing gallery updates ofc, but depending on how much additional space is needed it may become a worthy tradeoff. A touch advanced and requires more maintenance, but provide it’s done thoroughly could provide considerable size reduction.