Provision Cloud Run Services

This step stands up the two Cloud Run services that run the GTM server image: a preview service for testing and a tagging service that receives live events. Both services run Google's official gtm-cloud-image:stable container image — GSS does not build or deploy custom code.

Once both services are running, the runtime checks in Step 3 prove they are reachable, healthy, and configured correctly before Tagging Endpoint unlocks. The tagging service still has only a *.run.app URL at the end of this step; attaching a custom domain happens in Tagging Endpoint.

Glossary▶

Cloud Run

Google's managed serverless runtime for containers. Each service is a deployed container with its own URL, scaling rules, and IAM policy.

Preview service

The Cloud Run service that GTM Preview / Tag Assistant connects to. Has RUN_AS_PREVIEW_SERVER=true and is capped at 1 instance.

Tagging service

The Cloud Run service that handles live event traffic. Always has at least 1 warm instance to avoid cold-start latency on incoming requests.

CONTAINER_CONFIG

The base64-encoded GTM server container configuration string. GTM gives it to you on Admin → Container Settings → Set up your tagging server → Manually provision tagging server. Both Cloud Run services need it as an environment variable to know which container they host.

Container image

The Docker image both services run: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable. Maintained by Google. GSS does not modify or replace it.

Region

The Google Cloud region where the services run. Default suggestion is us-central1; you can pick any Cloud Run region. Both services run in the same region.

Not covered on this page: enabling the Cloud Run Admin API (GCP Project), the GTM server container itself (GTM Containers), or attaching a custom domain (Tagging Endpoint).

Before you start

• Complete GCP Project — the Cloud Run Admin API must be enabled and the project bound.
• Complete GTM Containers — the server container must be bound so GSS can validate the CONTAINER_CONFIG string matches it. The page surfaces a link directly to that step if it's missing.
• Have the CONTAINER_CONFIG base64 string from the server container's Admin → Container Settings → Set up your tagging server → Manually provision tagging server screen.

Decision record

Once both Cloud Run services are bound, the page surfaces a Cloud Run services decision record above the steps with the preview / tagging service IDs and URLs, the deployment-config save state, when requirements were last checked, and the current requirement rollup.

1 Capture CONTAINER_CONFIG From Your GTM Server Container

GTM gives you a base64-encoded configuration string that tells the server container which GTM container it is. Both Cloud Run services need this string as their CONTAINER_CONFIG environment variable; without it, the container does not know which configuration to load. GSS will inject the value into the services it creates and check that user-bound services already have it.

In GTM, open your server container → Admin → Container Settings → Set up your tagging server → Manually provision tagging server. Copy the long string labelled Container Config. Paste it into the input under Step 1 and click Save deployment config. The page also surfaces the bound server container's name and ID, with a link to Container Settings, so it's easy to jump back into GTM.

GSS validates that the string is valid base64, that the decoded value contains id=GTM-XXXXXXX, and that the GTM ID matches the bound server container. After saving, the value is shown masked next to a show toggle so you can verify what's stored without exposing it on every page load. The string is stored on the project (as profile_config.container_config) and is only sent to Cloud Run as an environment variable when GSS creates or updates services.

The button label flips to Update deployment config after the first save, so you can replace the value if you re-key the GTM server container.

2 Which Cloud Run Services Should Host the Preview and Tagging Containers?

Step 2 stays locked until the GCP project is bound and Step 1's deployment config is saved. The page reminds you which project the services will land in (inherited from GCP Project) above the picker. You need two services: one running in preview mode, one running tagging traffic, both in the same project.

Option A — Pick existing services

The two pickers (Preview service / Tagging service) list every Cloud Run service in the bound GCP project. Pick one row for the preview slot and a different row for the tagging slot, then click Save Cloud Run services. Save stays disabled until both pickers have a value, both differ from what's already saved, and the two picks are different services — the page surfaces an inline warning if you pick the same service in both slots ("Preview and tagging must be different services").

GSS records each binding with created_by: user metadata. Step 3's runtime checks confirm that the services have the right environment variables and IAM policies regardless of who originally created them — mis-configured user services will fail those checks with specific guidance on what's wrong.

Option B — Create Cloud Run services from scratch

Click the Create Cloud Run services link (it reads Create new Cloud Run services if you already have services in the picker). A modal opens with checkboxes for each service, a name input per service, a region selector (default suggestion us-central1, reordered by your local timezone), and a read-only display of the image GSS will deploy.

• Image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable — Google's official maintained image.
• Preview service: CONTAINER_CONFIG + RUN_AS_PREVIEW_SERVER=true, max instances = 1, allow unauthenticated invocations (anyone on the internet can reach /healthy).
• Tagging service: CONTAINER_CONFIG + PREVIEW_SERVER_URL pointing at the preview service's URL, min instances = 1 (always-warm), allow unauthenticated.

Click Create. A confirmation prompt warns that creating Cloud Run services locks the primary GA4 property and GTM web container selections for this setup — to change those later you'd archive the setup and start a new one. The deployment is synchronous: the request blocks until both services are running (typically 30–60 seconds). Both bindings get created_by: gss metadata.

If you already have one of the two services bound (for example, you previously created the preview but not the tagging), the corresponding checkbox is unchecked and its name field disabled — you can re-run the Create flow for just the missing side. If the preview deploys but the tagging service fails, you'll see a partial-success message and can retry just the tagging side.

3 Are Both Services Reachable, Healthy, and Configured?

Step 3 stays locked until both services are bound in Step 2 and the deployment config is saved in Step 1. Click Check to run 9 runtime checks. GSS makes 4 Cloud Run API calls (2 service reads, 2 IAM policy reads) plus 1 HTTP probe to the preview service's /healthy endpoint, and reuses the responses across the rows.

Preview service (3.1–3.4)

Tagging service (3.5–3.6)

Cross-service environment + access (3.7–3.9)

Common errors & failure modes

Next step

Once all 9 runtime checks pass, the next step is Tagging Endpoint — attaching a custom subdomain to the tagging service so first-party event traffic flows through your domain instead of *.run.app.