Product, Sandbox, and Deployment IDs

Overview of product management tools in the Developer Portal.

6 mins to read

Products are games or other software projects that contain sandboxes and deployments within EOS. You can have multiple products registered with EOS, and each product maintains a separate set of sandboxes. At every product creation, a new public sandbox is automatically assigned to your live environment.

For example:

Organization: Epic Games
- Product: Jazz Jackrabbit
  - Sandbox: Development
    - Deployment: DevGame01
  - Sandbox: Staging
    - Deployment: QATestGame01
    - Deployment: AlphaGame
    - Deployment: BetaGame
  - Sandbox: Live
    - Deployment: LiveGame

In your Developer Portal, you can create and manage each of your products from the side panel under Your Products. The Product Settings are found in the side panel of the specific product you select. Each product has their own set of product settings.

The default tab provides general information about your product:

Setting	Description
Product ID	The unique identifier assigned to your product at creation. It cannot be changed once it is assigned.
Product Name	The display name of your product. You can change it by typing a new name in the field and clicking Change Name. This automatically updates your Product Slug.
Product Slug	The short name for your product helps you quickly identify your product, in addition to the Product ID. It automatically updates when you change your Product Name.
Product Cover Image	A cover image that displays when viewing the product’s page. You can change this by uploading a new image and clicking the Save Image button.
SDK Credentials	A list of all your SDK credentials for that product. Do not share this information outside your organization.

Environments (Sandboxes and Deployments)

Environments encompass your sandboxes and deployments for your product. You can view and manage your product’s sandboxes and deployments within the Developer Portal by selecting Product Settings > Environments.

For example:

Organization - Epic Games
- Product - Jazz Jackrabbit
  - Sandbox - Development
    - Deployment - DevGame01
  - Sandbox - Staging
    - Deployment - QATestGame01
    - Deployment - AlphaGame
    - Deployment - BetaGame
  - Sandbox - Live
    - Deployment - LiveGame

Titles are in control of their presence information. Epic recommends setting presence information to codenames during development as an additional safeguard for the most sensitive games. The ProductName field in EOS_Initialize is where the default game name comes from.

Sandboxes

Sandboxes are high-level distribution environments for a product that contains store-related information, mod configurations, and entries for specific deployments of the product. For each sandbox, you can configure its Deployments and Identity Providers.

By default, new EOS products include one public, predefined sandbox called Live.

EOS products that integrate with the Epic Games Store have three predefined sandboxes: Live, Stage, and Dev. By default, Live is a public sandbox, and Stage and Dev sandboxes are private.

To get access to the private Stage and Dev sandboxes, you must complete the Epic Games Store onboarding process. Reach out to your Technical Account Manager or Service Delivery Manager for more information on the onboarding process.

You can use Player Groups to grant external user access to your private sandboxes and deployments without having to add these users as Dev Portal organization members.

Deployments

Deployments are specific distributions of a product and store’s progression, achievements, statistics, matchmaking, and other gameplay-related user information. You can configure your deployments by clicking Deployments for a sandbox. Each deployment can only attach to a single sandbox. If you want parallel deployments in two different sandboxes, you must create one deployment for each.

The Deployments modal allows you to create, edit, or archive the deployments of a specific sandbox.

Archiving a deployment cannot be undone.

At creation, each deployment is automatically assigned a unique identifier. This Deployment ID is required for initializing the SDK and is configured to access product session data for that deployment. Information stored at the sandbox level is also obtained by the deployment ID.

When launching your product through the Epic Games Launcher, you need to map your deployments to your Epic Games Store artifacts.

Deployment Use Cases Examples

Deployments can provide another level of organization and separation to your development, testing, and shipping process. The following examples highlight different deployment opportunities:

Single-Branch Deployment

Create a single deployment called Live for development, testing, and shipping.
- All the data from development and testing is present in Live.
(With wipe) Create two deployments: Dev and Live. Conduct development and testing in the Dev deployment, but only ship Live.
- All data from development and testing persists in Dev, but is not present in Live.

Single-Branch Beta Test Deployment

Create two deployments: Dev and Live. Conduct development and internal testing in the Dev deployment, and run the beta tests in the Live deployment. Then, ship the game using the Live deployment.
- All data from development and internal testing persists in Dev and is not present in the betas or Live.
- All data from the beta tests are present in Live.
(With wipe) Create three deployments: Dev, Beta, and Live. Conduct development and internal testing in the Dev deployment and run the beta tests in the Beta deployment. Then, ship the game using the Live deployment.
- All data from development and internal testing persists in Dev and is not present in Beta or Live.
- All data from Beta persists but is not present in Live.

Separate development branches

For example:

Dev-Main
Dev-Release
Dev-Experimental
Dev-CoolFeature1
Dev-CoolFeature2

A CI/CD pipeline

For example:

Dev-Latest
Dev-Stable
Dev-Staging
Live

Separate development needs

For example:

Dev-LongTermStableBuildForExternalPartner
Dev-MainBranchPlaytest
Dev-ReleaseBranchPlaytest

Player Groups

Player Groups allow you to manage external users’ access to private sandboxes and deployments. By default, private sandbox or deployment access is denied to external users unless they are given permission by using Player Groups. For example, you can add your QA team’s account ID to a group so they can test on their own private version of your product. If you are using Epic Account Services, access is denied to external users until your application has gone through our Brand Review Application Process.

Note: Access to a private sandbox or deployment is automatically granted to organization users that have access to the associated product.

You can view and manage external user access to private sandboxes and deployments within the Developer Portal by selecting the Player Groups tab on the Product Settings dashboard.

Creating a New Player Group

To create a new Player Group, click Create New Group. Each group you create requires the list of external account IDs you want to grant access. These account IDs can belong to any supported identity provider.

You can also import your list of account IDs with a .CSV file. This can be more efficient if you have many IDs from multiple providers.

To streamline importing multiple IDs, you can download a template with the correct file format from the Import list tab. Here is a sample import list of player IDs:

Once you finish assigning player groups to the appropriate IDs, select the sandboxes and deployments this group can access. Once you create the group, all external users in that Player Group can access the select private sandboxes and deployments.

You can always edit a Player Group from the Player Groups tab by selecting the More Options.