You can now unpublish workflow releases from the Releases tab.

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 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 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 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.

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.

Enterprise customers can now use Source Control to protect workflow triggers. This prevents changes to a workflow's triggers without review. When you protect a workflow for the first time, triggers are now automatically included.

To enable protected workflow triggers, navigate to Settings > Beta, and enable Allow users to edit triggers on branches.

For workflows that are already protected, you now have the option to protect triggers using a new PR.

Once protected, triggers are versioned and published alongside each release. Information about your triggers is stored in the triggers.yml file in your Source Control repository.

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.

Enterprise customers can send page load and query traces to Datadog and Sentry using Retool's performance monitoring integration, now in public beta. Customers can respond proactively to regressions and troubleshoot more quickly by creating dashboards and alerts to monitor the performance of their apps and use the spans themselves to help pinpoint where to take action if their apps are degraded.

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

Retool now supports managing permissions using role-based access control in public beta. You can create roles with granular permissions so groups can manage certain organization settings without full administrator access.

Role-based permissions offer much greater access control than Retool's existing group permissions functionality. For example, a Design team may need access to your organization's branding settings to ensure the Retool organization follows branding styles and guidelines. Rather than give the team members admin access, role-based permissions allow for granular control over what specific settings they can 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 per-group permissions to role-based access controls as the method with which you manage permissions.

To enable this feature, navigate to Settings > Beta and enable Permissions v2.

OAuth 2.0 is now supported when adding an MCP server as a tool for an agent.