Publish

This page promotes your staged GTM workspaces to live container versions. For each workspace (server first, then web), GSS calls the GTM API to create a new container version, then publishes that version. Once published, the new version is live in the GTM container — every site visitor's GTM snippet loads it on their next page load (subject to Google's edge caching).

Publish is the most consequential single action in the entire flow because it changes what real users experience. Before this point, all GSS work has been in staging workspaces that nobody outside your team sees. After this point, the world sees your server-side pipeline. The page is gated by Publish — Review staged setup being stamped — the live-traffic verification happens after publish in the next step.

Glossary▶

Workspace

A GSS-managed staging area inside a GTM container. Holds the role-mirrored variables / triggers / tags GSS authored. Persists across publishes — the same workspace row is reused on re-publish.

Container version

A snapshot of a GTM container's published state. Each Publish creates a new version named "GetServerSide mirror-pipeline setup".

Audit (Step 1)

Read-only inspection of the two staged workspaces — lists pending changes, surfaces auto-deletable retired items, and flags items needing manual cleanup.

Retired GSS items

GTM artifacts GSS authored in an earlier configuration but no longer needs (e.g. a deprecated forwarder tag). Step 2 lets you stage their deletion in the workspace before Step 3 publishes.

publish_audit_record

An immutable log row written on every successful publish. Records both new container versions, the prior versions (rollback targets), and a configuration hash. Used by the Emergency Rollback flow.

Provenance state

Per-container drift signal: ok (live version matches GSS's last publish), drift (live version differs — someone published outside GSS), unknown (no GSS publish recorded yet).

Not covered on this page: the preceding readiness gate (Publish — Review staged setup), the live-traffic verification that follows (Publish — Confirm live traffic), or post-publish rollback (Emergency Rollback flow on the Go-Live stage).

Before you start

• Publish — Review staged setup is stamped (writes profile_config.publish_confirmed_at). Clearing that stamp re-locks this page.
• The staged GSS workspaces in both containers are in configured state — i.e. Connect — Web Container and Connect — Server Container ran and queued the GSS-authored items.
• Edit + publish permission on both GTM containers. Read access alone isn't enough; the orchestration writes a new container version on each side.
• Nobody else is publishing the same containers concurrently. GTM's API doesn't have strong concurrency guarantees for publish, and overlapping publishes will surface a stolen-attempt error.

Publish containers (decision record)

The decision-record card at the top of the page summarises the current publish state. It updates on each Check or Publish attempt.

1 Audit GTM containers

Click Audit GTM containers. GSS reads both staged workspaces (the same workspace IDs Configure has been writing into) and produces a snapshot covering: number of pending changes per container, the count of needs-attention items, and any retired GSS artifacts still present.

The audit panel that renders below the button surfaces two sub-sections: Pending changes per container (one line per kind — web vs. server — with a count of changes that will go live on publish) and either "No blocking issues found." or a tally of items needing attention. Any retired items appear in Step 2 below; manual-cleanup-only items appear there informationally.

The audit is read-only — it never mutates the workspace. It surfaces what's about to go live, and what Step 2 might want to clean up beforehand. If you change anything in GTM after auditing (manually editing the workspace, re-running Configure), re-audit before publishing — the snapshot is what Step 2 and Step 3 read. The button shows a "Last updated: <X ago>" timestamp next to it once a fresh audit exists; if the snapshot has gone stale, the page replaces the snapshot with "Audit failed or is stale. Click Audit GTM containers to refresh before publishing."

2 Retired GSS items

GSS lists any auto-deletable retired items found during Step 1 — tags, triggers, or variables GSS authored in a previous configuration but no longer needs. Examples: a forwarder tag from a deprecated loader profile, an init trigger replaced by a newer pattern.

Two options:

• Stage deletion — GSS removes the items from the workspace. Live traffic isn't affected yet; the deletion goes live when Step 3 publishes.
• Skip cleanup — leave the items in place. Use this if you want to publish exactly the items GSS authored without any cleanup, or if you're not sure whether a flagged item is safe to remove.

Manual-cleanup items (items GSS won't auto-delete because their removal could break adjacent setup) are surfaced informationally; they don't block publishing and aren't touched by Stage deletion.

3 Publish GTM changes

Click Publish GTM Changes. The in-app modal lays out what's about to happen; click Confirm to start the orchestration:

1. Snapshot prior versions — for each container, read the currently-live containerVersionId. This is the rollback target if you later need it.
2. Server workspace publish — call create_version against the server staging workspace (snapshot the workspace into a new GTM container version), then publish_version on that new version. Server publishes first because the web container's tags reference the server endpoint; if you published web first, traffic could briefly hit a server container that didn't yet have the GSS-staged config.
3. Web workspace publish — same two-step pattern on the web staging workspace.
4. Write publish_audit_record — one immutable row containing both new version IDs, both prior version IDs, the config hash, and a schema version. Written when at least one container publishes, so partial-publish state is still recorded.
5. Update workspace status — both staging workspaces transition to published; their published_version_id field is set.

Each create_version + publish_version pair takes a few seconds; publishing both containers typically completes in 5–15 seconds total.

4 Have my container changes been published?

After Step 3, click Check. GSS reads the live versions of both containers and runs three checks against the actual published state. This is your last automated confirmation that what you intended to publish is actually what's live; if something published incorrectly, this catches it.

Common errors & failure modes

Next step

Once all four steps are green, continue to Publish — Confirm live traffic. That step polls GA4 Realtime + Cloud Run on your live site to prove the just-published pipeline is actually moving traffic, then asks you to attest.

After Go Live

Once the project completes the Go Live cutover, this page stays reachable as the publish receipt. The H1 stays "Publish"; the page intro switches to "This publish stage is read-only because the project is live. The publish receipt and live container checks remain visible here for review."

The four-step orchestration buttons (Audit, Stage deletion, Publish GTM Changes, Check) are hidden. Step 3 renders a receipt table sourced from the latest publish_audit_record row:

• Published — the published_at timestamp from the audit record.
• Web container version — web_published_version_id.
• Server container version — server_published_version_id.
• Publish source — how the publish was triggered (UI button vs. internal).

The publish-orchestration JavaScript that drives steps 3 and 4 is gated off entirely. Direct POSTs to /p/{slug}/publish/run/* return 409 live_project.

The receipt is the page. If a project completed cutover under an earlier flow without writing a publish_audit_record, the receipt falls back to "No publish receipt was found. Use the setup snapshot for the frozen cutover record." The cutover snapshot itself lives at /setup-snapshot.