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:

Product IDThe unique identifier assigned to your product at creation. It cannot be changed once it is assigned.
Product NameThe 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 SlugThe 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 ImageA 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 CredentialsA 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


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

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.

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.

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.