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.

92 posts tagged with "Self-hosted"

Updates related to self-hosted instances.

View All Tags

Hardened images available in stable channel

Retool now supports hardened images, which are now available on the self-hosted stable 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.

note

At this time, hardened images are supported for the tryretool/backend Docker image only. Retool plans to expand support for hardened images to tryretool/code-executor-service in the future.

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 or Kubernetes deployment guides.

When testing:

  • Update your manifests or Docker Compose files to use the appropriate *-stable-hardened tags.
  • Verify your critical apps, workflows, and database connections behave as expected.
  • Check container health, logs, and telemetry using Container 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​

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.

Self-hosted Retool 3.334 Stable

Self-hosted Retool 3.334.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.