Google Tag Manager environments let a staging or development server run a different container version than the one your visitors get. That sounds useful for every team. In practice, it only pays off when the website itself has more than one deployed copy and a release process that moves code between them. If your site has one production server, environments add snippets to maintain and give little in return.
This article gives a decision framework based on how the site is deployed. It does not cover workspaces, versions and rollbacks in general. Those are explained in GTM Workspaces, Versions and Publishing.
What an environment actually changes
According to Google's Help page on environments, every container has a default Live environment that "always points to the container version that is currently published." You can add custom environments under Admin, then Environments, and "publish any version of your container to any environment you have defined." Publishing to a custom environment does not change Live.
The catch is installation. Each custom environment has its own snippet, available through Actions, then Get Snippet. Google says you install it "on every server that has a corresponding environment defined in Tag Manager." The Environments API reference shows that each environment carries its own authorization code. Resetting an environment link creates a new code, and Google notes that this "will invalidate any container snippets that may be installed."
So an environment is a contract between GTM and a specific server. The server loads the environment snippet, and GTM serves whichever version you assigned to that environment. Google also states that the feature "is designed for use with non-production environments."
