Manage Environment Version
Every GraFx Studio environment has a GraFx Studio version setting. It controls which version of Studio is used by the templates and projects in that environment when they open and save. Pin to a specific version for stability, or set it to Latest to auto-update with each new release.
Admin access required
Only environment admins can change the version. If you don't see the settings described below, you don't have admin access on this environment.
Set the GraFx Studio version
To set or change the GraFx Studio version of an environment:
-
Open the environment settings. You can do this two ways:
From inside an environment: click the settings icon.

From the environments overview at https://chiligrafx.com/environments: hover over an environment and click the settings button.

-
In environment settings, find the GraFx Studio version field. By default this is Latest — meaning the environment auto-updates to the newest Studio release as soon as it ships. When set to Latest, the resolved version is shown in parentheses, e.g.
Latest (1.42.x).
-
Click the pencil icon next to the version.
-
In the GraFx Studio version dialog, choose a specific version to pin to, or select Latest to switch back to automatic updates. Click Update to confirm.

After you change the version, the environment settings reflect your choice.
Existing templates and projects don't auto-upgrade
Changing the environment version doesn't migrate existing content. Templates and projects keep their current saved version until someone opens and saves them — at which point they're saved in the new version.
When to pin vs. stay on Latest
Pinning a version gives you control over when new Studio releases reach your environment. Without a deliberate versioning strategy, automatic updates can introduce behavior changes, break existing templates, or disrupt production workflows.
Common patterns:
- Production environments: pin to a specific version. Test new releases in a separate environment first, then update production once you're confident.
- Test or staging environments: stay on Latest to catch issues with new releases before they affect production.
- Single-environment setups: pin to a specific version and update on a schedule you control.
Compatibility rules
Before changing the version, know the basic rule: templates and projects saved in a newer version cannot be opened in an older version. This makes downgrades a one-way risk — once content has been saved in a newer version, re-pinning the environment to an older version leaves that content inaccessible until you re-pin upward.
For the full compatibility model — including backwards compatibility, SDK compatibility, and worked examples — see Compatibility Rules in the developer documentation.
Related
For designers
If you design templates, the version your environment runs on directly affects which environments can later open the templates you save. See Guidance for Designers for the rollback problem and best practices.
For integrators
If you build the application that loads Studio UI or the Studio SDK, your integration code must stay in sync with the environment's configured version. See Guidance for Integrators for CDN URL structure, SDK pinning with ~ vs ^, and how to read the environment's current version via the API.
Full picture
For the full picture of how versioning works — including compatibility rules, the patch update policy, the one-year grace period, the API for reading and changing the environment version, and a recommended update workflow — see Versioning Your Integration in the developer documentation.