Changelog

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.

Self-hosted Retool 3.251 and later contain two notable changes to the code-executor service:

• A container running code-executor is required to run workflows and custom API authentication. Previously, these features could be run in a sandbox in the backend container. Retool's security team has become aware of a sandbox escape and will no longer be supporting sandboxing in the backend. For more information refer to the disclosure page.
• Traffic to the private 192.168.0.0/16 IP address range is blocked by default. If you want to disable this security configuration, follow the instructions in the code-executor security privileges documentation.

Retool removed the preview release of Agents for self-hosted organizations since Agents is now in public beta with the 3.234.0 edge release and it will be available in the upcoming Q3 stable release. This preview release was intended for deployment into a non-production environment, and was created as a mechanism to allow Self-hosted organizations the opportunity to create agents prior to their availability in an edge or stable release.

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.

Retool made several UI changes to the workflow IDE and updated some terminology to improve clarity of workflow releases. Instead of deploying a workflow release, you now publish the release instead.

The functionality remains the same and you continue to publish a workflow release for it to be live. This change was made to more closely align the app and workflow IDEs.

When you are ready to finalize your workflow changes, click Publish release in toolbar of the workflow IDE. This button was previously labeled Deploy.

Create, publish, and revert releases from the Releases tab in the left panel. This tab was previously labeled Deploy History. You can also navigate to the Releases tab using the button in the status bar of the IDE, which also displays the currently published release version.

You can now view which users and permission groups have access to a workflow, resource, and agent. When on the listing page for one of these objects, click the ••• menu and select View access list. Use the tabs at the top of the list to show Users or Groups. The list shows the access level of each user or user group.

Resources display permissions on a per-environment basis if they are configured.

Access lists were already available for apps and app folders.

Retool Agents is now in public beta on Self-hosted Retool 3.234.0.

To enable Retool Agents in Self-hosted Retool 3.234.0 and later, the AGENTS_ENABLED environment variable must be set to true.

Modules now support typed data inputs. This change makes your modules more reliable by catching mismatched data types early.

Previously, modules offered only a Data input for passing in property values. Now, you can choose from the following options when configuring a module input:

• Any
• String
• Number
• Boolean
• Enum

Choose from String, Number, Boolean, or Enum for type validation on your module input. Selecting a Type enforces stricter validation rules and displays a warning if the input type does not match what you selected. You can also define additional characteristics about the input, such as options for Enum, and default values for all types.

If you set the Type to Any, Retool performs no validation on the module input.