The following patch is now available on the Stable release channel:

• Retool 4.0.13

Update your Retool instance to apply the latest bug fixes and security patches.

Self-hosted Retool 4.34.0 is now available on the Stable release channel.

Retool releases a version on the stable channel each quarter. A stable release is generally four versions behind the cloud-hosted version at the time.

Preparation and testing of a stable version occurs approximately four weeks prior to its release. Stable releases are rigorously tested before they are published. As the release cycle is less frequent, administrators can more easily maintain and upgrade deployments.

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.

After six months, a stable release is considered deprecated. You can continue using a deprecated release but it will no longer receive updates. At this time, you should upgrade to the latest stable release.

Retool is deprecating the dedicated BigID resource type.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, BigID resources will stop working. Queries in apps and workflows that still point at those resources will fail. Cloud and self-hosted organizations will not have a BigID connection option after removal.

Organizations can keep querying BigID after removal by creating a REST API resource. Retool will not migrate BigID resources or their query references automatically.

1. Create a REST API resource. To use guided query creation, select Use an API spec and enter the specification URL https://sandbox.apps.mybigid.com/BigAPI.yaml or the BigAPI.yaml URL for your BigID instance, with the environment server variable set to your BigID hostname. Otherwise, select Manual queries and set the base URL to https://HOSTNAME/api/v1.
2. Set Authentication to Custom Auth. Add an API Request step that sends POST /api/v1/refresh-access-token with your BigID user token in the Authorization header. Add a Define a variable step named SYSTEM_TOKEN with value {{ http1.body.systemToken }}. Add an Authorization header on the resource that uses {{ SYSTEM_TOKEN }}. Enable Run this custom auth workflow without prompting the user. Configure a refresh auth workflow that repeats the exchange after a non-200 response. Generate the user token in the BigID UI and exchange it as described in BigID's token authentication.
3. Open each app, workflow, and Query Library query that uses the BigID resource. Change the query to use the new resource, then test it. If you used an API spec, select the same operation. Otherwise, recreate the request as method and path, such as GET /ds-connections. If the query editor shows an Authorization parameter, leave it empty.

Custom authentication is not supported in public apps. If you have a large number of BigID queries and need help finding them, contact Retool Support.

The following patch is now available on the Stable release channel:

• Retool 4.0.12

Update your Retool instance to apply the latest bug fixes and security patches.

Enterprise organizations can use access policies to define which data each group of users can read or write on a resource. Retool enforces access policies on every query that runs against the resource. A policy can grant access to whole tables, specific columns, or specific rows.

For example, you can use an access policy to restrict an EMEA group's access on a table to only the customer rows for their own region. Retool applies that restriction to every query the group runs against the resource, so it holds regardless of which app, query, or agent the request comes from.

One policy covers queries from apps, the query library, raw SQL, and agents. Workflow queries against an enforced resource are blocked, so account for any workflows using the resource before you turn enforcement on. Retool supports access policies on PostgreSQL resources.

Access policies are enabled by default on cloud instances. On self-hosted instances, navigate to Settings > Beta and toggle on the feature flag for Enforce data security using access policies. To create a policy:

1. Open a PostgreSQL resource and select the Access Enforcement tab.
2. Turn on Data access enforcement.
3. Create a policy, choose the groups and environments it covers, and define its rules.
4. Activate the policy, then click Save changes.

Turning on data access enforcement closes the resource by default in every resource environment. Access policies apply only to the resource environments you select, so grant broad access first and narrow it once your policies are in place. Refer to Configure access policies for more details.

Access policies operate by granting access, not denying access. Refer to Access policies and Data access enforcement for more information.

Retool is deprecating the dedicated Vertica resource type.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, Vertica resources will stop working. Queries in apps and workflows that still point at those resources will fail. Retool will no longer ship the Vertica JDBC driver. Cloud organizations will not have a Vertica connection option after removal.

Self-hosted organizations can keep querying Vertica after removal by creating a JDBC resource and adding a Vertica JDBC driver that you provide. Retool will not migrate Vertica resources or their query references automatically.

1. Download the Vertica JDBC driver from Vertica.
2. Add the .jar file to your self-hosted instance. Follow the JDBC configuration steps for JDBC_DIRECTORY_PATH.
3. Create a JDBC resource with Driver name com.vertica.jdbc.Driver, connection string jdbc:vertica://HOSTNAME:5433/DATABASE?user=USERNAME&password=PASSWORD&DisableCopyLocal=true, and schema query select table_name, column_name, data_type, table_schema from columns. Include DisableCopyLocal=true on the connection string.
4. Open each app and workflow query that uses the Vertica resource. Change the query to use the new JDBC resource, then test it.

JDBC resources do not support Retool-managed SSH tunnels. If your Vertica resource uses an SSH tunnel, or you have a large number of Vertica queries and need help finding them, contact Retool Support.

The following patches are now available on the Stable release channel:

• Retool 4.0.10
• Retool 3.334.28

Update your Retool instance to apply the latest bug fixes and security patches.

Retool 4.35 is now available on the Edge release channel for self-hosted organizations.

The following patches are now available on the Stable release channel:

• Retool 4.0.9
• Retool 3.334.27

Update your Retool instance to apply the latest bug fixes and security patches.

Admins on the Enterprise plan can now complete each step in the Get started section of the Overview page using guided step-by-step wizards instead of navigating through separate Settings pages to complete configuration.

You can now directly configure from the Overview page:

• SSO
• Resources
• Source control
• Spaces
• Permissions

The Get started section is aimed at providing a better onboarding experience for admins of new organizations, and will help identify what configurations still need to be set up for admins or existing organizations. For example, setting up spaces walks you through choosing custom spaces or a Dev/Staging/Prod environment split, naming and configuring each space, and optionally copying over your existing SSO settings, before creating every space at once.

The Overview page also includes an Action center that contains important notifications and pending join requests, suggested users, and seat upgrade requests, so admins can act on what needs attention, as well an at-a-glance overview of your organization stats, such as total users, apps, workflows, and AI credit usage.