Skip to main content

Changelog

Updates, changes, and improvements at Retool.

Internationalization (i18n) is now in beta for organizations on the Enterprise plan. This allows you to localize Retool app content and data.

This beta is available on Retool Cloud and self-hosted deployments running Retool 3.38 or later. Contact your Retool account team to request early access.

You can now set private or public access for files uploaded to Retool Storage. Each file in your Retool organization has a public URL that you can enable by making the file public.

Files uploaded to Retool Storage are private by default, and you can switch between private or public access at any time. When uploading files with a Retool Storage resource query, you can enable Make file public on upload to automatically make them public.

Make file public on upload

We're continuing to make performance improvements after recently upgrading to React 18. Update batching groups state updates together, rather than perform each one separately, to optimize performance. This results in a more responsive experience in Retool and faster page load times.

The Image column type for the Table component now supports image uploads directly to Retool Storage. Enable Allow uploading images to allow users to upload and replace images to Retool Storage.

Self-hosted organizations on the Enterprise plan can create multiple, isolated organizations on a single Retool instance with Spaces.

Prior to Spaces, you needed to spin up an additional deployment to onboard an independent team with its own apps, resources, and software development cycle (SDLC). Now, on the same instance, you can create a Space with its own subdomain, SSO configuration, Source Control setup, and more.

Retool has improved the self-hosted Retool release process with the introduction of two release channels: Stable and Edge.

Stable releases

Releases on the Stable channel occur every quarter. Preparation and testing of a Stable version occurs approximately four weeks prior to its release and they are rigorously tested before they are published. The release tags for Stable releases contain the suffix -stable.

Retool supports each Stable release for six months. During this time, Retool will release patch updates that contain bug fixes or security updates. Patch updates do not contain functionality changes and can be applied more quickly than performing a full version upgrade.

Retool provides versioned product documentation for supported Stable releases. When browsing Retool Docs, use the version dropdown menu in the navbar to switch to a relevant version.

Edge releases

Releases on the Edge channel occur weekly. Each release occurs one week after the equivalent release for cloud-hosted Retool. Edge releases are available for organizations that want the latest features or to use private beta functionality. The release tags for Edge releases contain the suffix -edge.

Retool recommends most organizations use Stable releases unless you have a specific need for Edge releases and can keep your deployment up-to-date.

Benefits of Stable and Edge releases

Until now, Retool maintained a single release channel. A new release would be published every two weeks that is generally a number of versions behind Retool Cloud. Retool would also release patch updates for previous versions.

The new release channels streamline the release process, makes it easier for administrators to perform upgrades, and provides a separate deployment path for customers who prioritize stability over new functionality. As the Stable release cycle is less frequent, administrators can more easily maintain and upgrade deployments.

Edge releases are now on par with Retool Cloud, providing self-hosted customers with new features much sooner. The weekly release schedule also means it is no longer necessary to patch previous releases. Every Edge release contains bug fixes and improvements.

Self-hosted Retool now includes default statement timeouts that apply when running upgrade migrations. If your organization has a self-hosted Retool deployment that uses PgBouncer with its main PostgreSQL database, you must update the PgBouncer configuration to ignore statement timeouts.

PgBouncer configuration
ignore_startup_parameters = statement_timeout