Addressables Remote Catalog Profile Configuration for Environment Isolation

Question

Remote Catalog Loading and Environment Separation
Unity Addressables allows the definition of remote load paths via Profiles, enabling the runtime to resolve asset bundles from a remote URL. In a typical integration workflow, different profiles are used to swap the base URL between staging and production environments to avoid using production credentials or endpoints during testing.
While the system supports swapping URLs through profiles, the framework does not provide a built-in mechanism to enforce credential isolation or access control for the catalog requests themselves. This leaves the responsibility of securing the catalog update process to the external hosting provider or custom build scripts.
Given the lack of native authentication for catalog requests in the Addressables package, how should the permission boundary be defined to prevent unauthorized catalog overrides during integration testing? What is the recommended approach for ensuring that a client only accepts catalogs from a trusted build source without implementing a custom network layer?

Siddharth · Answer

Permission boundary without custom network code
Unity Addressables does not authenticate remote catalog sources natively. The framework relies on URL isolation and HTTPS to separate environments. Below is the practical permission boundary you can establish using only profile configuration and hosting controls.

Define a distinct Addressables Profile for staging and production. Each profile holds its own Remote Catalog URL and Remote Load Path. Activate the matching profile at build time; do not rely on runtime profile swaps unless the target URL is also swapped.
  Deploy each environment’s catalog to a separate storage bucket or CDN path. Use distinct bucket names or prefix folders (e.g., staging-catalog/ vs prod-catalog/) so that a client pointing at one URL cannot resolve the other.
  Grant read-only permissions to the catalog bucket for the client’s IP range or service account. Restrict write access to the CI/CD pipeline that publishes the catalog. Avoid public listing or anonymous read.
  Ensure the Unity build script or CI pipeline selects the correct profile via Addressables.InitializeAsync with the profile name, or via PlayerSettings addressablesProfile. Do not leave profile selection to default or user input.
  After switching profiles, call Addressables.ClearCatalogs or clean the persistent data path to prevent stale catalogs from resolving against the wrong URL.

Verification: build a target platform with the staging profile active, then inspect network traffic (via proxy or platform logs) to confirm the catalog request resolves to the staging bucket URL over HTTPS and returns the expected catalog JSON. Repeat for the production profile.
Depending on whether your hosting uses separate buckets or path-based routing on the same hostname, the boundary may require additional URL allowlisting or certificate pinning. Confirm your hosting setup to determine if the above steps are sufficient.

Addressables Remote Catalog Profile Configuration for Environment Isolation

Remote Catalog Loading and Environment Separation

1 answer

Permission boundary without custom network code

Your perspective belongs here.

0 question comments