GTM Environments: Staging, Live and Share Links

This guide is built from Google's own pages, checked on 10 November 2026: Tag Manager Help on environments, publishing, versions and approvals and built-in variables, and the Tag Manager API reference for the Environment resource. How drafts become versions is in our GTM workspaces and versions guide; how to debug a draft in Tag Assistant is in GTM preview mode.

What an environment is

An environment decides which version of a container a given site loads. Google describes the feature as "ideal for organizations that want to preview their container changes in a test environment before those changes are published", and as useful for teams with "multi-tiered environments in their development workflow (e.g. 'development', 'staging', and 'production'.)"

Without environments, a container has one published version, and every site that carries the standard snippet runs it. With environments, a staging server can run a newer version than the live site, while both use the same container, tags and triggers.

Google sums up the setup in three steps:

1. Define your environments.
2. Install the relevant container snippet for each environment on their respective sites.
3. Publish the container to the desired environment.

There is no fixed limit in the Help article: "You can set up as many environments as is required for your workflow, and you can publish any version of your container to any environment you have defined."

Live, Latest, Now Editing and custom environments

Every container already has some environments that Tag Manager manages itself. The API reference lists four environment types, and the built-in Environment Name variable returns "Live", "Latest" or "Now Editing" for the built-in ones:

The API reference says a user "can create, delete and update environments of type USER, but can only update the enableDebug and url fields of environments of other types." The Help article adds that you never set up Live yourself: "Every container is set up with a "Live" environment by default, which always points to the container version that is currently published."

Latest and Live are not always the same. If you save a version with Create Version and don't publish it, as described in our workspaces guide, that version is the latest one but not the live one.

Creating a custom environment

First decide what each environment is for. Google's example convention is Dev ("what you and your team use for day-to-day website development"), QA ("used for quality assurance testing") and Live ("the version that is visible to your users"). Live already exists, so in practice you create the others:

1. Click Admin.
2. In the Container menu, click Environments.
3. Click New.
4. Enter a Name, and optionally a Description and Destination URL.
5. Optionally check Enable Debugging by Default "if you need the environment to always use preview mode."
6. Click Create, then Publish Now. The Version menu lets you choose which container version the new environment starts with.

The new environment then appears in the Custom Environments list. Publishing to it does not touch your live site: "When you publish a custom environment, you will not send those changes to the live version of your container."

Snippet or share link

There are two ways to make a browser load a custom environment, and Google describes both:

Google is clear that environment snippets are for test servers only: "The Environments feature is designed for use with non-production environments. To ensure the best performance, you should install the standard Tag Manager container snippet on live/production websites."

The share link is the lighter option. In Google's words, with it "you don't have to install and deploy a special environment code snippet." It suits a client or colleague who needs to check one change on the real site. The snippet suits a staging server that should always run the staging setup, for every tester, without anyone opening a link.

The environment share link is different from sharing a Tag Assistant debug session or a version's Share Preview, which our preview guide covers. The environment link follows whatever version is published to that environment.

Publishing to an environment

Once a container has custom environments, the publish dialog gains a choice of destination. Google's steps:

1. Click Publish in the upper right corner of Tag Manager.
2. Choose an environment in the Publish to Environment section.
3. Click Publish.

You can also move an environment to any existing version without opening a workspace: in the Custom Environments list, open the Actions menu, select Publish To..., pick the version in the Version menu and click Publish Now. That is how a tested version on staging is matched to the one you then publish to Live.

When environments exist, the Versions list gains an Environments column that "indicates to which environment the version was published", so you can see at a glance which version each site is running.

Editing an environment and resetting its link

To change an environment, open its Actions menu and select Edit Settings. You can change the Name, Description and Default URL, and switch Enable Debugging by Default on or off.

If a preview link has gone to people who should no longer use it, open the Actions menu, select Reset Link and confirm with Reset and Relink. This cancels the old authorization code and creates a new one. Google warns that it "also will invalidate any container snippets that may be installed", so the staging site needs the new snippet afterwards, or it stops loading that environment.

The Environment Name variable

The built-in Environment Name variable tells tags which environment they are running in. Google says it "Returns the user-provided name of the current environment, if the container request was made from an environment "Share Preview" link or from an environment snippet." For the built-in environments it returns "Live", "Latest" or "Now Editing", and in all other cases an empty string.

You can use it in a trigger condition or a lookup table, for example to send staging hits to a test GA4 property instead of the real one. That keeps test traffic out of your reports alongside an internal traffic filter.

When we use a staging environment

This is our own practice, not Google guidance:

• A site with a separate staging server, where developers and clients test before release, gets a "Staging" environment with its own snippet. Small sites without staging don't need one; preview mode and a share link are enough.
• The live site always keeps the standard container snippet, as Google recommends.
• We publish to Staging first, test there, then publish the same version to Live, so what goes live is exactly what was tested.
• Staging tags send data to a test property, switched by the Environment Name variable.
• When a project with outside testers ends, we reset the environment link and install the new snippet on staging.

Frequently asked questions

What are environments in Google Tag Manager?

Environments let different sites load different versions of the same container. Every container has a Live environment; you can add custom ones such as Dev or Staging and publish any version to each of them.

Does publishing to a custom environment change my live site?

No. Google says those changes are only viewable on a server with that environment's snippet, or in a browser that used the environment's share link. The live site keeps running the version published to Live.

Should I put the environment snippet on my live site?

No. Google says environments are designed for non-production sites and recommends the standard container snippet on live websites.

What is the difference between Live and Latest in GTM?

Live points to the container version that is currently published. Latest points to the newest container version, which can be a version that was saved but not yet published.

What happens when I reset an environment link?

The old authorization code stops working and a new one is created. Shared preview links stop working, and so do installed snippets for that environment, so the site needs the updated snippet.

For more on tagging, see our guides to Google Tag Manager basics, GTM triggers, the data layer and testing a website before launch.