Documentation

Support

Services

Services

Unity Environments

Use logical partitions to organize your service data for testing, staging, and production workflows.
Read time 4 minutesLast updated 17 hours ago
Environments are logical partitions for Unity Gaming 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. 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.

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_prodmkdir staging_confugs 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#rollbackugs deploy backup_prod -e production
With source control: 
git checkout origin/stableugs deploy ugs_config_folder#rollbackgit checkout tags/last-release -b stableugs 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.