Unity Environments

Use logical partitions to organize your service data for testing, staging, and production workflows.

Read time 4 minutes

Last updated 8 days 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 environment support for additional services.

Manage environments

To access a project's environments from the Unity Dashboard, follow these steps:

In the Unity Dashboard, open your project.
Select Development > Environments.

The Environments page displays a list of environments for the project.

Create environments

All projects start with a production environment. You can create up to 25 environments for a project.

To create a new environment for a project, follow these steps:

In the Unity Dashboard, open your project.
Select Development > Environments.
Select Add Environment.
Enter a name for the new environment.
Select Add.

The new environment is displayed in the Environments page for the project.

Refer to Environments best practices for other tooling and recommendations.

Switch environments for a project

Services that support environments contain an environment switcher dropdown in the UI. This displays the name of the currently selected environment.

To switch the environment for a project in the Unity Dashboard, follow these steps:

In the Unity Dashboard, open your project.
Open a service that uses environments.
In the environment switcher, select the environment to use.

The environment you selected is now the active environment for all services in the project.

Access 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.

Warning

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:

Cloud Code (JavaScript and C# modules)
Economy
Game Overrides (through the Services Tooling package)
Remote Config
Leaderboards
Matchmaker
Multiplay Hosting
Access Control (through the Services Tooling package)

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.

Documentation

Development

User Acquisition

Monetization

Industry