Connect GTM Containers

This step (titled Connect GTM Containers in the app) binds the GTM server container that will run inside your Cloud Run tagging service. The web GTM container was audited and bound during the Audit stage and is shown read-only here. If you need to change it, go back to Audit Discovery.

The server container is permanent: the same container goes through Cloud, Connect, Publish, Go Live, and ongoing operation. You don't need separate test and production containers — the configuration inside it changes as you move through the stages, but the container identity stays the same.

Glossary▶

Web container

A GTM container with usage context web. Lives in the browser as gtm.js. Identified by a public ID like GTM-XXXXXXX.

Server container

A GTM container with usage context server. Runs in your Cloud Run tagging service, processes events forwarded by the web container, and writes them to GA4.

GTM account

The top-level container holder in GTM. Web and server containers must be in the same account for workspace operations to work in later stages.

Public ID

The GTM-XXXXXXX string that's visible in the page source. Used by browsers to load the container snippet.

Container path

The internal GTM API identifier: accounts/{a}/containers/{c}. Different from the public ID; used for API calls.

Not covered on this page: changing the web container (Audit Discovery), workspace selection (handled later in the Connect stage), or Cloud Run setup (Cloud Run Services).

Before you start

• Complete GCP Project — Tag Manager API must be enabled.
• Web container was selected during Audit Discovery. If you need to change it, go back there — the change cannot be made on this page.
• Have at least Edit access to the GTM account that holds your web container, so GSS can list and create containers in it.

Decision record

1 Discover GTM containers available to your account

Click Find containers the first time you visit this page. GSS calls the Tag Manager API for the GTM account that holds your bound web container and lists every container in that account (both web and server). After the first run the button becomes Refresh containers — use it whenever you add or remove containers in GTM.

The status line shows how many GTM containers were found in total and how many of those are server-context candidates for Step 2. If the container you expect doesn't appear, your account probably doesn't have at least Edit access on the GTM account — fix the access in GTM Admin, then click Refresh containers.

2 Which GTM server container should GSS configure?

The web container is shown above the picker as inherited context (you can only change it from Audit/Discover). The picker below lists every server-context container in the same GTM account as the web container. You can pick one that already exists or have GSS create a new one in this account — both paths land at the same final state, just with different provenance metadata.

This step stays locked with a "Locked" banner until both prerequisites are met: a web container is bound in Audit, and Step 1 discovery has run. The Save button stays disabled until you pick a row different from what's already saved; switching to a different server container clears Step 3's requirement results and you'll need to re-run Check.

Option A — Pick an existing server container

If you already have a server container in the right GTM account, click its row in the picker and then Save server container. The picker filters to server-context containers in the same account as the web container, so you should only see eligible candidates. Each row links its GTM-XXXXXXX ID out to the workspace view in tagmanager.google.com.

GSS records this binding with created_by: user metadata so the Resources page can label it as user-managed. Behavior is identical either way; the metadata is only for display.

Option B — Create a new server container in this account

Click the Create a new server container in this account link below the picker (or Create server container in this account if no server containers were found). The modal has just two visible fields:

• Container name — pre-filled with a project-derived suggestion (a numeric suffix is appended if the name is already in use in the account). Editable; required.
• Account (read-only) — the GTM account that holds your web container. GSS always creates the new server container in this account so the same-account requirement check passes automatically.

Click Create. GSS calls the Tag Manager API to create the container, binds it to the project, and re-renders Step 2 with the new container selected; Step 3's requirement results are cleared so you'll need to re-run Check. If the API call fails, the error is shown inline next to the Create button — retry or pick an existing container instead.

GSS records this binding with created_by: gss metadata.

3 Can GSS work with both containers?

Click Check to validate that both containers are reachable, the server container has the correct server usage context, both live in the same GTM account, and the web container's public ID has the expected GTM-XXXXXXX format. GSS makes one or two Tag Manager API calls (one if both containers are in the same account, two if they happen to be in different accounts — though that itself fails the same-account requirement).

Step 3 stays locked until both Step 2's server container and the Audit web container are bound. After a successful Check the page nav at the bottom unlocks the link to Connect GA4.

Common errors & failure modes

Next step

Once Step 3's check passes, the page nav unlocks the link to Connect GA4 property — picking or creating the GA4 Test Server property that will receive forwarded events during Build verification.