Studio Versioning

Each org will have a Studio Version player-setting that allows them to determine which version of the studio will be used for the player (all players, both embedded and in the platform), editor, and jobs. Because this is configured at the org-level, it is possible to update a deployed project entirely from within the platform.

Note: For non-super users to be able to see and change an org’s Studio Version, their org must first have the Studio Versioning feature flag enabled.

Note: When migrating data between orgs, make sure they’re on the same version (or as close as possible) to ensure the assets behave as expected on the destination org.​Migrating does not cause the Studio Version or any other settings to be transferred over.

The Studio Version dropdown allows the user to select from any of the official releases deployed on the environment. In addition to all the official releases, the following special options are also available:

• Initial Release (ie. the oldest release)

• Latest Release (disabled on fts)

• Enter Build Tag (for engineer debugging, mostly)

Note: The Studio Version is cached for up to 5 minutes, so you might not see an immediate change after switching versions

Embed

When embedding the player, a bearer_token should be included in the URL to ensure the correct version of the player bundle is fetched, eg:

<script src=<https://branch.threekit.dev/app/js/threekit-player.js?bearer_token=1234-567890>..." />

• This applies to all other bundles as well, such as ARify.

If no bearer_token is specified, then we default to using the oldest release on preview/fts, and default to using the latest release on staging

Note about no-conf bundles: no-conf bundles are typically fetched from another environment that your org isn’t on, and thus your org’s Studio Version setting won’t apply to it. There’s two workarounds you can use to control the version in this case:

• Create an additional org on the environment that you’re fetching the noconf bundle from (and use the token from that other env’s org instead). The orgs don’t need to match/relate in any way for this to work.

• Embed a static URL instead. Eg. https://preview.threekit.com/app/js/threekit-player-noconf.js redirects to a static URL https://preview.threekit.com/js/threekit-player-noconf-preview-hotfix-preview-2026-feb-20-2026-02-20-14-26-26.js. Simply embed the static URL instead.

No-conf bundles should only be used for A/B testing and never production, other than in special cases such as when using the China proxy.

You can use https://triptych-player.pages.dev to test player embed​

Player / Editor

All platform players and the editor are versioned. The version will appear in the top-right corner of the player/editor

Jobs

All studio-related jobs are versioned: importers (including clara-importer), exporters (including export-paths), render-vray, render-webgl, composite, zip-downloader, and image-worker (aka. image-magick ). The only jobs not versioned are bq-analytics, org-data-transfer, and wf-generator.

At the top of each job log, you should see a message similar to the following which confirms that the job picked up the correct studio version: “Using Studio Version: '_initial'. Release tag: 'preview-2026.4.0'. Build tag: hotfix-preview-2026-feb-20-2026-02-20-14-26-260”

Note, render-webgl jobs are versioned but will display the following message due to implementation discrepancies: “Studio Versioning is not enabled for this job type”

Services

• Are not versioned, Services always run the latest version.

• fast-compositor will respect the org’s Studio Version when rendering, but technically this is just the service selecting the correct player bundle, the service itself is not versioned