Unity Environments

Environments are logical partitions for Unity Game Services that contain data associated with your project. Examples can include game code using Cloud Code, or game configurations using Remote Config.

  • Environments are isolated. This means that if you change data in one environment, data in other environments is not affected.
  • You apply Environments at the project level.
  • You can think of Environments as namespaces or labels for your data.
  • Creating an environment doesn't provision resources; it enables you to tie data to a specific workspace.

Supported Services

The following services currently support Environments:

Unity Gaming Services will continue to release Environments support for additional services.

Managing environments

To access a project’s Environments from the Unity Dashboard:

  1. Select Projects from the primary navigation menu.
  2. Select the project to which you want to apply Environments.
  3. Select the Environments tab.

All projects start with a production environment. You can create up to 25 environments. To create a new environment, click Add Environment, give the new environment a name, and select Add.

Refer to Environments best practices for other tooling and recommendations.

Switching environments for a service

To switch the environment for a service in the Unity Dashboard:

  1. Select Projects from the primary navigation menu.
  2. Select the project for which you want to change the environment.
  3. Select the Environments tab.
  4. Select the environment to use.

Accessing environments within Unity projects

Use the Services Core initialization options to initialize your Unity Gaming Services in the development environment you want the player to experience. If unspecified, Unity Gaming Services will initialize in the default “production” environment.

Note: The Services Core SDK is included as a dependency for each service that supports Environments. For more information, see documentation on Services Core API.

To do this, include the Unity.Services.Core and Unity.Services.Core.Environments namespaces, then invoke the UnityServices.InitializeAsync() method with an options parameter configured to pass in the environment name. For example:

Initializing Unity Gaming Services with the "dev" environment.

using Unity.Services.Authentication;
using Unity.Services.Core;
using Unity.Services.Core.Environments;
using UnityEngine;

class InitWithEnvironment : MonoBehaviour {
   async void Awake()
   {
       var options = new InitializationOptions();

       options.SetEnvironmentName("dev");
       await UnityServices.InitializeAsync(options);
       await AuthenticationService.Instance.SignInAnonymouslyAsync();
   }
}

If no option is specified, the Environment Selector value is used. If no Environment Selector option is present, 'production' is used as the default.

For more information, refer to Environment Selector.

Important: You must include the Unity.Services.Core.Environments namespace to access the SetEnvironmentName method.

Environments Recommended Practices

Configuration as Code

Most UGS services support implementing Configuration-as-Code practices. Configuration as Code is the practice of treating configurations the same as code. This approach enables versioning, code review, automated deployment, and eliminates manual environment setup across your development pipeline.

It also lets you reuse configurations across projects and organizations.

Recommended environment strategy

The recommended best practice is to use environments as follows:

  • Production environment: Live environment serving released applications, updated from stabilization branches.
  • Staging environment: Production-like environment for final testing, updated from stabilization branches.
  • Development environment: Shared integration environment for the team, updated from main development branch.
  • Personal environments: Individual developer workspaces for experimentation and feature development. Only developers actively working on service-enabled features need personal environments to iterate safely and avoid impacting anyone's work.

Environment management tooling

Editor Deployment window

The Deployment Window is accessible through Services > Deployment in Unity Editor 2022 and later, once the package is installed. It allows you to deploy local service content to the services. It is the preferred way of iterating and working on service-enabled features.

The following services are supported:

The respective service package must be installed to enable the integration, refer to the Deployment window for details.

Any content that can be deployed via the Deployment window can be deployed to any environment.

Actions available through the Deployment window can also be used in automations using the Deployment API, such as build scripts. You can also use the Deployment API to build custom tooling to work with environments.

Unity Gaming Services CLI

Use the UGS CLI to call services' admin APIs, and to deploy and fetch configurations for the following services:

  • Access Control
  • Cloud Code (Scripts and Modules)
  • Remote Config
  • Economy
  • Leaderboards
  • Matchmaker
  • Triggers
  • Schedules

The CLI also provides access to other services without config-as-code needs. For more information, refer to the CLI documentation.

Deploy and fetch workflow

You can use the deploy and fetch commands in automations to achieve common needs, such as diffing an environment and rolling back an environment with the supported services.

Deploy command

Use the deploy command to move content from one environment to another, with rollback:

Without source control:

mkdir backup_prod
mkdir staging_conf
ugs fetch backup_prod --reconcile -s <specify the services here>
ugs fetch staging_conf --reconcile -s <specify the services here>
ugs deploy staging_conf -e production # promotion
#rollback
ugs deploy backup_prod -e production

With source control:

git checkout origin/stable
ugs deploy ugs_config_folder
#rollback
git checkout tags/last-release -b stable
ugs deploy ugs_config_folder

Source control makes it easier to track what's being deployed, and automate deployments.

Fetch command

Use fetch to compare the configuration between two environments. This fetches the relevant configuration and compares it, using your preferred diff tool.

Fetch configurations from both environments and use git diff:

ugs fetch ./staging-configs --environment-name staging --reconcile -s <services>
ugs fetch ./prod-configs --environment-name production --reconcile -s <services>
kdiff3 ./staging-configs ./prod-configs

UGS Services APIs package

The Services APIs package provides simple access to most public UGS API packages. This lets you build any amount of custom tooling using the admin APIs or game APIs directly from within Unity.

Unity logo Documentation
Copyright © 2025 Unity Technologies
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.