Studio Versioning
With the addition of Studio Versioning, players will no longer automatically update when a platform release is deployed. Instead, each org can independently select the version used by embedded players, platform players, and jobs. Because this is configured at the org level, it is possible to update a deployed project entirely from within the platform.
Frontend code must be updated for an embedded player to leverage Studio Versioning. See the Embed section below.
When migrating data between orgs, it is best for both orgs to be set to 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.
Setting the Version
For an org’s Studio Version to be editable on the UI, the org's Studio Versioning setting on the Features page must first be enabled.

The Studio Version dropdown, on the Player Settings page, allows the user to select from any of the official releases deployed on the environment. Options include:
2026.4 (the initial release)
Use latest (preview and personal orgs only)
Enter Build Tag (obtained from Engineering for unique circumstances or debugging)

Studio Version is cached for up to 5 minutes so there could be a slight delay in changes being applied.
Embed
When embedding the player, a bearer_token must be included in the URL to ensure the correct version of the player bundle is fetched, eg:
This applies to all other bundles as well, such as ARify.
If no bearer_token is specified, the oldest version of the player, 2026.4, is loaded.
no-conf bundles are typically fetched from a different environment and an org’s Studio Version setting will not apply to it. To control the version in this case, use either of the following workarounds:
Create an additional org on the environment from which the noconf bundle will be fetched (and use the token from that env’s org instead). The orgs do not need to match/relate in any way for this to work.
Embed a static URL instead.
Example: 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.
Platform Players / Editors
All platform players and the editor are versioned. The version will appear in the top-right corner of the player/editor if the Studio Versioning setting on the Features page is enabled.
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, there will be a message similar to the following, which confirms 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”
render-webgl jobs are versioned but will display “Studio Versioning is not enabled for this job type” due to implementation discrepancies.
Services
Services always run the latest version.
fast-compositorwill 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.
Last updated
Was this helpful?

