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​

• Confirm that your environment meets the Self-hosted Retool requirements, including network and egress configuration.
• Identify any current reliance on shell access, system tools, or custom image modifications.
• Review your update process in Upgrade deployments and your overall deployment model in the Self-hosted quickstart.

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 protect an agent with Source Control from the dropdown next to the agent name, or from the dropdown on the All agents page.

Source Control for agents operates similarly to how it does for apps, but with some key differences.

• Agents cannot be moved or renamed. Protected agents and the folders in which they're located cannot be renamed or moved. You must unprotect agents before making name or location changes. Protected agents must have a unique name.
• Agent triggers cannot be protected. You can edit the trigger of a protected agent without creating a commit.
• Evals and Datasets are incompatible. You cannot access evals and datasets from a protected agent.

Self-hosted Retool 3.284 is now available on the Stable release channel. Retool encourages prompt upgrades to each Stable version once it is released to ensure that your deployment stays secure and up-to-date.

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.

You can now see the output of an agent run with the Result (sync) return type when using the Invoke Agent block in workflows.

• The Result (sync) type is the default setting. This returns the direct result of the agent's output.
• The Run state (async) type returns the agentRunId, agentId, and status only. It does not include the output of the agent.

Retool Agents is available on Retool's stable release 3.253.0.

To enable Retool Agents in Self-hosted Retool 3.253.0 and later, toggle the AI Agents feature flag in Settings > Beta.

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

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 removed some JDBC connectors that were inadvertently included in certain self-hosted release versions. These include:

• Actian Ingres/Vector JDBC Driver.
• Clickhouse JDBC Driver.
• IBM Data Server Driver for JDBC.
• IBM Informix JDBC Driver.
• Trino JDBC driver.

These JDBC connectors are not supported by Retool for self-hosted deployments. If you have created a JDBC resource using these connectors, update its configuration as needed to make use of your own preferred JDBC drivers.

Retool has since released patch updates for affected releases that remove these connectors.

Customers with a 3.259.0-edge deployment should immediately update to 3.259.1-edge. This patch release addresses a security vulnerability that could expose environment variables during code-executor startup.

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.