Skip to main content

Changelog

Updates, changes, and improvements at Retool.

Refer to the stable and edge release notes for detailed information about self-hosted releases.

Self-hosted organizations can now restrict the creation or usage of specific resource types using either the RESOURCE_TYPES_CREATION_DENY_LIST or RESOURCE_TYPES_DENY_LIST environment variables.

  • RESOURCE_TYPES_CREATION_DENY_LIST prevents users from creating any resources of the specified types. Any existing resources continue to function.
  • RESOURCE_TYPES_DENY_LIST prevents users from both creating and using any resources of the specified types. Any related resource queries will then fail.

Any restrictions you set can be reverted at any time.

Role-based permissions is now generally available for organizations to configure granular admin controls. Organizations can now configure granular admin permissions. You can create roles with granular permissions so groups can manage certain organization settings without full administrator access.

Once you configure the necessary roles to control access, you can apply them to any number of groups. Retool will eventually transition away from using per-group permissions to role-based access controls for permissions management.

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

Retool releases a version on the Stable channel every 13 weeks (quarterly). 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.

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.

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.

You can now unpublish workflow releases from the Releases tab.

This feature is currently rolling out on Retool Cloud and will be available in subsequent releases of self-hosted Retool. Reach out to your account manager to enable unpublish for workflows.

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.

Retool improved Assist's ability to reason about and plan layout changes for large and complex apps. This change has the following impacts:

  • Improves the quality of layouts when editing medium to large apps. Assist is now better at formatting the spacing and alignment of components.
  • Improves latency when making large edits to UI layout. For example, one layout change that previously took 5 minutes now takes under 1.5 minutes.
  • Improves support for adding header frames.

This change is available on Retool Cloud and will be available in subsequent releases of self-hosted Retool.

Retool now supports hardened images, which are available on the self-hosted edge release channel. These images are designed to improve supply-chain security, reduce the attack surface, and support modern infrastructure while remaining functionally compatible with existing deployments. Learn more about hardened images in the conceptual guide.

Plan your migration

Use the following high-level steps to evaluate and roll out hardened images.

1. Review requirements and environment

2. Test hardened images in non-production

Retool strongly recommends testing hardened images on non-production instances first, for example:

  • A development or staging instance in a separate Virtual Private Cloud (VPC) or cluster.
  • A temporary test environment built using the Docker, Kubernetes, or ECS Fargate deployment guides.

When testing:

  • Update your manifests or Docker Compose files to use the appropriate *-edge-hardened-beta tags.
  • Verify your critical apps, workflows, and database connections behave as expected.
  • Check container health, logs, and telemetry using Deployment logs and Collect self-hosted telemetry data.

3. Roll out to production instances

When you're ready to use hardened images in production:

  • Follow your usual deployment and rollout process. For example, use the near-zero downtime strategy in Scale your self-hosted deployment infrastructure.
  • Upgrade instances sequentially (development → staging → production) and validate each step.
  • Communicate with your users about maintenance windows and any expected changes.

If you encounter regressions, you can temporarily roll back to classic images by reverting your image tags while you work to diagnose and resolve issues.

Stable channel timeline

After sufficient testing and feedback on edge, Retool plans to transition hardened images to the stable channel. When that happens:

  • Both Stable classic and Stable hardened images will be available in parallel for a period of time.
  • Over time, hardened images will become the recommended default for production deployments, and classic images will eventually be phased out.

To stay current on timelines and support windows, monitor the Stable releases and Self-hosted requirements documentation.

You can now create a README from the workflow IDE to help clarify important information about your workflow for collaborators. For example, if a workflow requires certain permissions on a resource, or if it's only scheduled to run once a week.

This feature is available on Retool Cloud and will be available in subsequent releases of self-hosted Retool. Reach out to your account manager to enable README for workflows.

This feature is also available for workflows protected with Source Control. To create a README, click the title of the workflow and add content to the Editor README field. READMEs are visible from the Edit workflow details dialog box, in workflows JSON exports, and in a markdown file from source control.