READMEs can now be protected for apps that use Source Control. For existing apps that have a README, Retool will add a README.md file to your repository with your next commit. If you are protecting an app for the first time, Retool will include the README.md file automatically.

Source Control configuration now supports embedded expressions in sensitive credential fields, including access tokens, passwords, private keys, and SSH keys. This enables secure credential management using configuration variables and secrets.

Toggle the Template variables in Source Control config feature flag in Settings > Beta to enable this feature.

• On cloud and self-hosted instances, you can reference configuration variables:

  {{ environment.variables.MY_KEY_OR_TOKEN }}
  

• On self-hosted instances only, you can also reference secrets from secrets managers:

  {{ secrets.MY_SECRET.KEY }}
  

Embedded expression support is available for all Source Control git providers: GitHub, GitLab, Bitbucket, Azure Repos, and AWS CodeCommit. The UI includes field captions, autocomplete, and validation to help you use embedded expressions correctly.

Non-sensitive fields like repository names, branch names, and usernames do not yet support embedded expressions.

Multi-instance releases are now generally available to cloud instances and self-hosted instances on version 3.330 or later, with support for both apps and workflows.

Organizations using Source Control can manage releases of protected apps and workflows across multiple deployment instances. This feature enables you to publish different release versions across instances, making it easy to test newer versions on staging or development instances before promoting to production.

You can now unpublish workflow releases from the Releases tab.

This feature is also available for workflows protected with Source Control. When unpublishing a release on a protected workflow, the latest saved version on the main branch will be live to users.

You can now unpublish workflow releases from the Releases tab.

This feature is also available for workflows protected with Source Control. When unpublishing a release on a protected workflow, the latest saved version on the main branch will be live to users.

Enterprise customers can now use Source Control to protect workflow triggers. This prevents changes to a workflow's triggers without review. When you protect a workflow for the first time, triggers are now automatically included.

For workflows that are already protected, you now have the option to protect triggers using a new PR.

Once protected, triggers are versioned and published alongside each release. Information about your triggers is stored in the startTrigger.yml file in your Source Control repository.

Self-hosted organizations using Source Control to protect apps can opt into the public beta of multi-instance releases. This feature enables you to publish different release versions of apps across multiple deployment instances. This is particularly useful if you want to test a newer version of an app on a test instance first.

Retool added support within the IDE for merging changes from your default branch into your feature branch. This feature allows developers to keep their branches aligned with the default branch through guided, in-product flows, eliminating the need to switch to external tools like GitHub or GitLab.

When conflicts arise, Retool walks developers through a conflict resolution process entirely within the IDE, including validation checks to catch errors before completing the operation.

This change also eliminates the need for catch-up commits.

When setting up Source Control with Bitbucket, you can now use a Bitbucket access token instead of an app password. Access tokens provide a more secure authentication method than app passwords.

Authentication using app passwords is still supported, but Retool recommends using access tokens instead.

If you use Source Control to protect a workflow, you can now create and publish releases for that workflow. This allows you to safely test and build changes without disruption. Previously, protected workflows were automatically versioned and published, and you could not publish a specific version.

Once you merge a change into the main branch, navigate to the Releases tab in the left-hand menu. In this tab, you can create, manage, and publish versions of the workflow. Refer to Version and publish workflows for more information.