• Retool 4.0.2

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

Organization admins on Team and Business plans can now purchase additional AI credit packs directly by clicking on Buy credits from Settings > Plans & Billing > under the new AI Credits tab.

Credit packs are sold in increments of 1,000 credits at $100 per pack. Purchased credits are added to your organization's shared pool and are consumed after your monthly allotment runs out, with the oldest (soonest-expiring) pack used first. Credit packs expire at the end of your next monthly billing cycle (between 30–60 days after purchase), depending on where you are in your billing cycle when you buy them.

• If you are billed monthly, your next billing cycle end date is your expiration date.
• If you are billed annually, your monthly billing date is the same day of the month you originally purchased your plan (e.g., if you purchased an annual plan on April 12, credits expire on the 12th of the following month).

When your organization's credits run out, admins will see a banner prompting them to purchase additional credits or upgrade their plan. Users who are not admins will be directed to contact their admin.

Credit pack purchasing is available on cloud plans using Retool-managed keys. Free plan organizations must upgrade to Team or Business to purchase credit packs. Enterprise customers should contact their account executive.

For more information, refer to the AI credits documentation.

Retool now supports audio and visual browser notifications for app building. If you prompt Retool to build an app and navigate away from the tab, a ping sounds and a red dot appears on the favicon of the tab when you need to return to it. Now, you can multitask and return to the app builder only when your input is required.

This notification occurs at the following key points in the building process:

• The agent needs you to provide input or make a choice (such as selecting a resource).
• The agent needs your approval to run a function.
• The agent is finished building.

To turn off the notification sound, click the Model options selector in the prompting box and toggle off the Sound notifications setting.

What happens when you upgrade​

When you deploy Retool 4.0 stable, the migration runs automatically in the background. In most cases, no action is required.

If the migration fails—even for a single space within your instance—all organization admins will see a notification banner across all settings pages to indicate that the database is in an inconsistent state. This notification includes a link for an admin to trigger the migration again.

The database integrity check can take approximately three hours from upgrade completion. If the check fails, the notification banner is displayed. For larger instances, this check can take up to 15 hours.

If the migration fails​

Should the migration fail, no existing functionality is impacted. In most cases, an admin can trigger the migration again. The option to trigger a migration again is disabled if it is already in progress so it cannot be triggered multiple times.

If re-running does not resolve the issue, contact our support team as soon as possible.

I'm on Amazon ECS. Can I upgrade in place?​

No. Retool 4.0 introduces the agent sandbox and js-executor services, both of which require a custom Linux seccomp profile. AWS Fargate for Amazon ECS does not support custom seccomp profiles, and Amazon ECS on EC2 does not meet the other requirements for a supported production deployment.

There is no in-place upgrade path from ECS to Retool 4.0. You must migrate to a Kubernetes deployment before upgrading. Retool's Terraform blueprints are the officially supported path for new Kubernetes deployments.

Contact your Retool account team to plan the migration. For step-by-step instructions, refer to Migrate from ECS to Kubernetes.

I'm running Kubernetes with raw manifests. Can I upgrade in place?​

No. Raw Kubernetes manifests are not a supported deployment configuration, and services introduced in Retool 4.0 are shipped and configured through the Retool Helm chart. There is no in-place upgrade path for raw manifest deployments.

You must migrate to a Helm-based deployment before upgrading to Retool 4.0. Retool's Terraform blueprints are the recommended path. If you have an existing Helm deployment, the Helm upgrade guide covers how to add the new services.

Contact your Retool account team if you need migration assistance.

I'm running Docker Compose in production. What should I do?​

Retool does not support Docker Compose for production deployments. The agent sandbox service requires resource isolation and pod-level scheduling that a single-VM stack cannot reliably provide.

If you are using Docker Compose in production, migrate to Kubernetes before upgrading. Refer to Migrate from Docker Compose to Kubernetes for step-by-step instructions.

If you are using Docker Compose for non-production or development purposes, you can upgrade in place. Refer to Upgrade your Docker Compose deployment.

Can I upgrade to Retool 4.0 without enabling the new services?​

Yes. All new services introduced in Retool 4.0 (the agent sandbox, JS executor, MCP server, r2 agent, and git server) are disabled by default in Helm chart version 6.11.4. Upgrading the chart without enabling them is safe and fully backward compatible.

You can enable individual services at any time after upgrading. Refer to the Helm upgrade guide for instructions on enabling each service.

What seccomp profiles do the agent sandbox and js-executor require? Is this more or less secure than privileged mode?​

Both the agent sandbox and js-executor require a custom seccomp profile on each cluster node. The profiles grant only the specific system calls each service needs and do not require CAP_SYS_ADMIN. The agent sandbox does not support privileged mode. The js-executor supports privileged mode as an alternative to the custom seccomp profile, but the custom seccomp profile is recommended.

This is significantly more secure than privileged mode. Customers who previously ran code-executor without privileged mode can apply the same approach for these services.

For the full seccomp profile breakdown and a comparison with code-executor, see Custom code execution security.

My ENCRYPTION_KEY contains non-ASCII characters. Do I need to change it before upgrading?​

Yes. From version 3.332.4, ENCRYPTION_KEY must contain only ASCII characters. If your key contains non-ASCII characters, upgrading without rotating it first will cause decryption failures — look for ERR_OSSL_BAD_DECRYPT in your logs.

Rotate your encryption key before upgrading. Contact your Retool account team if you need assistance with the rotation process.

I use SAML SSO. Are there any new requirements?​

Yes, if your users sign in via SP-initiated SAML (starting the login flow from Retool rather than your IdP dashboard). Retool now binds each login to the AuthnRequest that started it using a short-lived, HTTPS-only cookie. Two requirements apply:

• Retool must be served over HTTPS. Do not enable COOKIE_INSECURE. The cookie is set SameSite=None; Secure, which browsers only return over HTTPS. SP-initiated logins will fail on plain HTTP.
• Use a single consistent hostname. The Assertion Consumer Service (ACS) URL registered in your IdP must match the hostname your users start login from. Standard single-hostname deployments need no change.

Standard IdPs (Okta, Entra ID, OneLogin, ADFS, Ping, Google Workspace) return the required InResponseTo value automatically.

IdP-initiated logins — launching Retool directly from your IdP dashboard — are unaffected. Users must complete a login within 10 minutes of starting it.

To disable this validation: set DISABLE_SAML_INRESPONSETO_VALIDATION=true and restart.

I use Temporal-in-Helm. What do I need to do?​

Temporal-in-Helm has been removed in Retool 4.0. Retool no longer ships a Temporal cluster as part of the Helm chart. You must migrate to an external Temporal provider before or during your upgrade.

Retool supports two options:

• Temporal Cloud (recommended): a fully managed Temporal service. Requires outbound network access to Temporal Cloud egress endpoints on ports 443 and 7233.
• Self-hosted Temporal: an externally managed Temporal cluster you operate. Retool does not provide support for the Temporal cluster itself.

After upgrading to Retool 4.0, an admin user must complete Temporal setup from within Retool: click the Workflows nav item and follow the in-product setup steps. A valid license key is required.

If you have Temporal-in-Helm data (workflow history) you want to preserve, contact your Retool account team before upgrading.

You can now use Retool's MCP server to import React apps directly from your agentic coding environment.

Open a React app, and ask Retool to import the app. Retool guides you through the process of selecting the appropriate resources, and sends you a link to the newly imported app in the app builder. From there, you can make tweaks to the generated app, and securely publish the app using the MCP server or from the app builder.

For new deployments: Retool now provides Terraform blueprints that automatically provision all required AWS infrastructure (VPC, EKS cluster, RDS, S3, load balancer, ACM certificate) and deploy Retool via Helm. This is the recommended path for production.

For existing deployments: The upgrade path depends on how you're currently deployed. New services are disabled by default so you can upgrade the chart first and enable them when ready. Some deployment configurations require migration before upgrading.

In addition, a database migration is performed to prepare for upcoming improvements to organization permissions. This migration does not affect any functionality within this release but any migration issues must be resolved before attempting to upgrade to a future release.

• Retool 4.0 upgrade FAQ
• Permissions database migration in self-hosted Retool 4.0

Retool 4.0 upgrade FAQ​

If you have an existing Retool deployment instance, this FAQ can provide guidance as you prepare an upgrade plan.

I'm on Amazon ECS. Can I upgrade in place?​

No. Retool 4.0 introduces the agent sandbox and js-executor services, both of which require a custom Linux seccomp profile. AWS Fargate for Amazon ECS does not support custom seccomp profiles, and Amazon ECS on EC2 does not meet the other requirements for a supported production deployment.

There is no in-place upgrade path from ECS to Retool 4.0. You must migrate to a Kubernetes deployment before upgrading. Retool's Terraform blueprints are the officially supported path for new Kubernetes deployments.

Contact your Retool account team to plan the migration. For step-by-step instructions, refer to Migrate from ECS to Kubernetes.

I'm running Kubernetes with raw manifests. Can I upgrade in place?​

No. Raw Kubernetes manifests are not a supported deployment configuration, and services introduced in Retool 4.0 are shipped and configured through the Retool Helm chart. There is no in-place upgrade path for raw manifest deployments.

You must migrate to a Helm-based deployment before upgrading to Retool 4.0. Retool's Terraform blueprints are the recommended path. If you have an existing Helm deployment, the Helm upgrade guide covers how to add the new services.

Contact your Retool account team if you need migration assistance.

I'm running Docker Compose in production. What should I do?​

Retool does not support Docker Compose for production deployments. The agent sandbox service requires resource isolation and pod-level scheduling that a single-VM stack cannot reliably provide.

If you are using Docker Compose in production, migrate to Kubernetes before upgrading. Refer to Migrate from Docker Compose to Kubernetes for step-by-step instructions.

If you are using Docker Compose for non-production or development purposes, you can upgrade in place. Refer to Upgrade your Docker Compose deployment.

Can I upgrade to Retool 4.0 without enabling the new services?​

Yes. All new services introduced in Retool 4.0 (the agent sandbox, JS executor, MCP server, r2 agent, and git server) are disabled by default in Helm chart version 6.11.4. Upgrading the chart without enabling them is safe and fully backward compatible.

You can enable individual services at any time after upgrading. Refer to the Helm upgrade guide for instructions on enabling each service.

What seccomp profiles do the agent sandbox and js-executor require? Is this more or less secure than privileged mode?​

Both the agent sandbox and js-executor require a custom seccomp profile on each cluster node. The profiles grant only the specific system calls each service needs and do not require CAP_SYS_ADMIN. The agent sandbox does not support privileged mode. The js-executor supports privileged mode as an alternative to the custom seccomp profile, but the custom seccomp profile is recommended.

This is significantly more secure than privileged mode. Customers who previously ran code-executor without privileged mode can apply the same approach for these services.

For the full seccomp profile breakdown and a comparison with code-executor, see Custom code execution security.

My ENCRYPTION_KEY contains non-ASCII characters. Do I need to change it before upgrading?​

Yes. From version 3.332.4, ENCRYPTION_KEY must contain only ASCII characters. If your key contains non-ASCII characters, upgrading without rotating it first will cause decryption failures — look for ERR_OSSL_BAD_DECRYPT in your logs.

Rotate your encryption key before upgrading. Contact your Retool account team if you need assistance with the rotation process.

I use SAML SSO. Are there any new requirements?​

Yes, if your users sign in via SP-initiated SAML (starting the login flow from Retool rather than your IdP dashboard). Retool now binds each login to the AuthnRequest that started it using a short-lived, HTTPS-only cookie. Two requirements apply:

• Retool must be served over HTTPS. Do not enable COOKIE_INSECURE. The cookie is set SameSite=None; Secure, which browsers only return over HTTPS. SP-initiated logins will fail on plain HTTP.
• Use a single consistent hostname. The Assertion Consumer Service (ACS) URL registered in your IdP must match the hostname your users start login from. Standard single-hostname deployments need no change.

Standard IdPs (Okta, Entra ID, OneLogin, ADFS, Ping, Google Workspace) return the required InResponseTo value automatically.

IdP-initiated logins — launching Retool directly from your IdP dashboard — are unaffected. Users must complete a login within 10 minutes of starting it.

To disable this validation: set DISABLE_SAML_INRESPONSETO_VALIDATION=true and restart.

I use Temporal-in-Helm. What do I need to do?​

Temporal-in-Helm has been removed in Retool 4.0. Retool no longer ships a Temporal cluster as part of the Helm chart. You must migrate to an external Temporal provider before or during your upgrade.

Retool supports two options:

• Temporal Cloud (recommended): a fully managed Temporal service. Requires outbound network access to Temporal Cloud egress endpoints on ports 443 and 7233.
• Self-hosted Temporal: an externally managed Temporal cluster you operate. Retool does not provide support for the Temporal cluster itself.

After upgrading to Retool 4.0, an admin user must complete Temporal setup from within Retool: click the Workflows nav item and follow the in-product setup steps. A valid license key is required.

If you have Temporal-in-Helm data (workflow history) you want to preserve, contact your Retool account team before upgrading.

Permissions database migration in self-hosted Retool 4.0​

Self-hosted Retool 4.0 includes an automatic database migration that prepares your instance for upcoming improvements to how Retool handles organization permissions. This migration runs in the background during deployment and does not affect any functionality.

What happens when you upgrade​

When you deploy Retool 4.0 stable, the migration runs automatically in the background. In most cases, no action is required.

If the migration fails—even for a single space within your instance—all organization admins will see a notification banner across all settings pages to indicate that the database is in an inconsistent state. This notification includes a link for an admin to trigger the migration again.

The database integrity check can take approximately three hours from upgrade completion. If the check fails, the notification banner is displayed. For larger instances, this check can take up to 15 hours.

If the migration fails​

Should the migration fail, no existing functionality is impacted. In most cases, an admin can trigger the migration again. The option to trigger a migration again is disabled if it is already in progress so it cannot be triggered multiple times.

If re-running does not resolve the issue, contact our support team as soon as possible.

Self-hosted admins now see an Update available banner on the Retool home page when a newer release or patch update is available for their instance.

The banner shows the available version and links directly to the relevant release notes. Admins can dismiss each notification individually — dismissals are remembered per version.

Two notification tiers appear based on what's available:

• New release — shown when a new minor or major release is available.
• New patch — shown when a patch update is available for the current release.

On airgapped instances, no outbound version check is made and the banner does not appear.

The Settings navigation is reorganized into clearer, task-based groups so you can find what you need more quickly.

Settings are now grouped under the following sections: Management, Monitoring, Permissions, Authentication, Features, and Customization. For example, Users, Groups, Roles, and User attributes are grouped under Permissions, while Single sign-on (SSO) and IAM credentials are grouped under Authentication.

Admins can now use the Overview page in Settings to set up their Retool organization and respond to pending user requests.

The Get started section guides you through configuring the core areas of your organization, including single sign-on (SSO), resources, permissions, spaces, source control, and the Retool API.

Retool marks each step as complete once you configure it, and you can mark any step that does not apply as not relevant. The module is hidden once you complete the Get started steps.

The Overview also surfaces pending join requests and suggested users, so you can approve new members without leaving the page.

• Retool 3.334.17
• Retool 3.300.32

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

Retool's new app builder now supports importing React apps from external sources, such as Replit, Lovable, and Claude Code, for further refinement and development in Retool.

To import your React app in Retool, generate a .zip file of the code, and select Import React code from the app builder. Learn more about how it works.

Apps created with the new app builder can now be protected and checked into your chosen Source Control Manager (SCM). Source Control lets organizations manage changes using remote SCM providers GitHub, GitLab, AWS CodeCommit, Bitbucket, and Azure Repos. Using this distributed approach, your users can:

• Prevent unwanted changes to apps.
• Work collaboratively and methodically through reviews.
• Edit React code from your preferred development environment.

To get started, first protect your app. Then you can create, publish, and tag new versions.

Builders on cloud instances can now use Retool's MCP server to build apps. Apps are built using React and use Retool's updated app builder. Connect the MCP server to Claude, ChatGPT, Codex, Cursor, Kiro, or another agentic coding environment, and describe the app you want to build. Retool's building agent generates the app and returns a preview link. Publish and manage the app from the app builder.

Beyond initial generation, you can also use the MCP server to:

• Continue building or iterating on an existing app.
• Monitor active builds and view past agent activity.
• Review function runs that require human approval.
• Inspect or read the files of an existing app.
• Cancel a failed or in-progress build.

App building tools require the user to be a builder, and the builder must authorize the mcp:write scope. Refer to the tools reference for the full list.

Claude Opus 4.8 is now available on Retool Cloud through Anthropic and Amazon Bedrock. It can be used with AI resource queries, with Retool Agents, and in Assist. Support for self-hosted Retool is coming in an upcoming release.

The app builder includes:

• A Chat tab where you describe changes in natural language and an AI agent plans and executes them, with file uploads and per-thread model selection.
• A Data tab that shows the resources connected to your app and the functions that interact with them, with optional approval gates on writes.
• A Code tab that lets you view and edit every file your app uses.
• Support for organization themes, third-party npm packages, and publishing and version history.

Apps run on React 19 and a curated set of supporting libraries.

• Retool 3.334.16
• Retool 3.300.31

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

• Retool 3.334.15
• Retool 3.334.14
• Retool 3.300.30

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

Organization admins in the admin space can now view audit logs from all spaces on the same instance directly from the Audit logs page. Use the Space filter to view events from a specific child space, or select all spaces to view events from every space at once. When viewing events across spaces, each entry includes a tag indicating which space it belongs to.

Users in child spaces continue to see events from their own space only, and downloads remain scoped to the current space.

For more information, refer to View audit logs across spaces.

• Retool 3.334.13
• Retool 3.300.29

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

The new Analytics page gives you visibility into workflow health and activity across your organization.

From the workflows landing page, select Analytics to access two views:

• All workflows: Aggregate run counts, failure rates, and resource consumption across every workflow in your organization. Includes a ranked list of your most-run workflows, a Top problem workflows table that surfaces workflows with high failure rates, and resource consumption data for the current month.
• Individual workflow: Drill into a single workflow to review summary stats, run and latency breakdown charts, resource consumption, and a paginated list of recent runs with per-run status and duration.

• Retool 3.334.12
• Retool 3.300.28

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

• Retool 3.334.11
• Retool 3.300.27

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

Admins can now configure memory limits for workflow code execution at the org level, and workflow editors can override those limits on a per-workflow basis.

• Org-level defaults: In Settings, go to the Advanced section and click Advanced settings to set a default memory limit (MB) that applies to all workflow runs in your organization.
• Workflow-level overrides: Open any workflow and go to Settings to override the org default for that workflow.

When a workflow runs a code block, the executor enforces the most specific limit available (workflow > org > server default). If a block exceeds its limit, it fails immediately with a clear error.

Customers who are not configuring limits see no behavior change — the server default of 2,500 MB memory applies. For customers whose workflows were hitting out-of-memory errors, limits can now be tuned without requiring infrastructure changes.

Gemini 3.1 Pro (Preview), Gemini 3 Flash (Preview), and Gemini 3.1 Flash-Lite (Preview) are now available in Retool through Google. They can be used with AI resource queries.

Retool now provides a native integration for ClickHouse, an open-source column-oriented database designed for real-time analytics. You can create a ClickHouse resource and use it to query analytical data with SQL—including ClickHouse-specific functions and aggregations—build dashboards on live data, and insert records from apps and automations.

• For cloud organizations, support for MongoDB Server 3.4 and earlier has already been removed.
• For self-hosted organizations, support for MongoDB Server 3.4 and earlier will be deprecated in the Q2 2026 stable release. It will be removed in the Q3 2026 stable release.

MongoDB Server 3.4 has been end of life (EOL) since January 2020. We recommend upgrading to a currently supported MongoDB release.

GPT-5.5 and GPT-5.3 Codex are now available in Retool through OpenAI. They can be used with AI resource queries and with Assist. GPT-5.5 is also available for use with Retool Agents.

Retool now provides a native integration for Azure Blob Storage, Microsoft's scalable object storage service. With the Azure Blob Storage resource, you can upload and download files, generate signed URLs for temporary secure access, and copy, delete, and organize objects across containers—all from Retool apps and automations.

Claude Opus 4.7 is now available on Retool Cloud through Anthropic and Amazon Bedrock. It can be used with AI resource queries, with Retool Agents, and in Assist. Support for self-hosted Retool is coming in an upcoming release.

GPT-4 Turbo, GPT-4.1 Nano, and GPT-5.4 are also now available for use with Retool Agents.

You can now select the Python version used by a workflow from the Languages & Libraries tab. Click ... next to Python, select Update version, and choose between Python 3.10 and 3.14.

Python 3.14 does not include built-in libraries. When you upgrade, Retool automatically identifies any built-in libraries your workflow uses and installs them as custom libraries.

Retool now supports an MCP server, which enables you to interact with your Retool organization from your chosen agentic environment.

Retool's MCP server currently supports tools that help you manage your organization and its users. For example, you can use the MCP for the following use cases:

• Write queries against resources to power data analysis.
• Bulk-invite users or manage pending invites.
• Audit the users who have access to your organization.
• Inspect organization and resource environment configurations.
• List all connected resources and see their configuration.

Refer to the tool reference for the full list.

Retool is actively adding additional tools that expand the capabilities of the MCP server to include additional Retool functionality, including app building.

What's changing​

New and existing workflows on Python 3.10 will continue to run but they will not be supported. They will not be automatically migrated to a newer version.

How to upgrade existing workflows​

Python 3.14 is rolling out to cloud instances and will be available in an upcoming self-hosted release.

1. Open the workflow and go to the Languages & Libraries tab.
2. Click ... next to Python and select Update version.
3. Choose Python 3.14 and click Apply.

When you upgrade, Retool automatically identifies built-in libraries your workflow uses and installs them as custom libraries. Python 3.14 is mostly backwards-compatible, but Retool recommends publishing a workflow release before upgrading so you can revert if needed.

See Configure Python version for full details on how to upgrade and revert to a previously published release.

Timeline​

• Retool 3.334.8
• Retool 3.300.24
• Retool 3.300.23
• Retool 3.284.29

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

• Retool 3.334.7
• Retool 3.300.22

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

To use this endpoint, your API token must have the workflows:write scope. The endpoint only supports deleting standard workflows—deleting agents and functions via the API is not supported.

Refer to the Retool API reference for full endpoint details, including request parameters and error responses.

Retool now provides a native integration for CockroachDB, a relational database management system. You can create a CockroachDB resource to securely connect to your databases and create apps and automations that use SQL queries to perform create, read, update, and delete operations.

• Retool 3.334.6
• Retool 3.300.21
• Retool 3.284.28

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

Retool now supports Google Vertex AI as a new native integration that can be used in AI resource queries.

• Retool 3.334.5
• Retool 3.300.20
• Retool 3.284.27

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

App builders can now defer the initialization of modules until they're viewable to improve the initial loading time of larger apps.

When an app is initially loaded, Retool initializes all code, components, and modules. However, a common use case for modules is including them in conditionally hidden frames, and these modules don't need to be loaded when they are still hidden.

Modules now have a new option in the Inspector: [Beta] Defer evaluation until visible. When a “deferred” module is hidden (either ‘hidden’ state is true, or it is in a hidden frame, or otherwise not being rendered), Retool defers the module's initialization. When the module is shown, Retool invokes the initialization procedure that would typically happen during app startup.

This gives builders more flexibility in how components are loaded in their apps, and large apps load more quickly.

• Retool 3.334.4
• Retool 3.300.19
• Retool 3.284.26

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

• Retool 3.334.3
• Retool 3.334.2
• Retool 3.300.18
• Retool 3.284.25

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

• Improved quality of app generation. Assist has an improved ability to successfully set a wider set of properties across a wider set of components.
• Quicker app generation. Generating an app from scratch is approximately 20% faster.
• Better token efficiency, especially for app editing. Token use has decreased by approximately 40-50%, depending on the change type. Users will notice a decrease in the number of context window issues they encounter.
• Improved support for building forms and using repeatable components inside apps.

Retool now provides a native integration for ServiceNow, an IT service management platform for managing incidents, change requests, service catalog items, and other operational workflows. You can create a resource and write queries to interact with the ServiceNow API.

• Retool 3.334.1
• Retool 3.300.17
• Retool 3.284.24
• Retool 3.253.29

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

GPT-5.4 is now available in Retool through OpenAI. It can currently be used with AI actions.

• Retool 3.300.16
• Retool 3.284.23

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

Retool has two new improvements to the API:

• A new per-instance API reference is now available at {your-instance}/reference. The reference is available on all cloud instances and served locally by self-hosted deployments within its VPC—no internet connection required. The API reference reflects only the API version running on your instance and always matches what's available to you.
• The API version now tracks the Retool release version. The Retool API version now corresponds to your instance's release version. This makes it easier to track Retool API changes whenever your instance is updated.

Retool now uses a service worker in the browser to cache the application frontend so that pages load faster when you revisit them. The service worker uses a stale-while-revalidate strategy: it serves the previously cached version of a page immediately, then fetches the latest version from Retool in the background. If a newer version is available, Retool automatically refreshes the page so you see the latest changes.

The cache is version-aware and automatically invalidates after a Retool upgrade, so you always end up on the latest version of the platform without needing to clear your browser cache. A hard refresh (Cmd+Shift+R / Ctrl+Shift+R) bypasses the cache and loads the latest version directly.

The service worker is enabled by default on cloud instances and on self-hosted versions 3.334-stable and later. Admins can disable it from Settings > Beta if they need to diagnose page load issues in their organization.

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.

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

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.

For full release notes, see Self-hosted Retool 3.334 release notes.

The landing page displays all workflows, and folders containing workflows, for your Retool organization. You can perform the following actions from the landing page:

• Sort workflows by Name, Last Updated date, or Created date.
• Search for workflows.
• Toggle between Grid view or Table view.
• Refresh the workflows list.
• Import a workflow from JSON.
• Create a new Folder.
• Create a new Workflow.
• Create a workflow From Template.

Claude Sonnet 4.6 and Opus 4.6 are now available in Retool through Anthropic and Amazon Bedrock. Sonnet 4.6 and Opus 4.6 can both be used with AI resource queries.

When creating a new REST API resource, you can now connect an OpenAPI or Swagger specification. Connecting an API specification enables:

• Autocomplete: Get endpoint and parameter suggestions when writing queries.
• Validation: Retool validates requests against the specification schema.
• Better Assist: Assist can more effectively generate queries based on the specification.
• Documentation: Endpoint descriptions from the specification appear in the query editor.

When working with resources, users can also manually create endpoints or parameters that aren't included in the specification.

Source Control configuration now supports embedded expressions in sensitive credential fields, including access tokens, passwords, private keys, and SSH keys. This enables secure credential management using configuration variables and secrets.

Toggle the Template variables in Source Control config feature flag in Settings > Beta to enable this feature.

• On cloud and self-hosted instances, you can reference configuration variables:

  {{ environment.variables.MY_KEY_OR_TOKEN }}
  

• On self-hosted instances only, you can also reference secrets from secrets managers:

  {{ secrets.MY_SECRET.KEY }}
  

Embedded expression support is available for all Source Control git providers: GitHub, GitLab, Bitbucket, Azure Repos, and AWS CodeCommit. The UI includes field captions, autocomplete, and validation to help you use embedded expressions correctly.

Non-sensitive fields like repository names, branch names, and usernames do not yet support embedded expressions.

Existing apps are unchanged. If you want to adjust the maximum width of your app, navigate to the Inspector and adjust the Max width setting in the Spacing section.

These changes will first roll out to cloud instances. Self-hosted instances can expect to receive the changes in a future release. There are no pricing or packaging changes associated with this update.

No action is required to facilitate this change. All existing apps, queries, workflows, and agents will continue to work based on existing configurations.

What's changing​

Instead of a single Retool AI resource, AI providers will function like any other resource at Retool. This allows for more flexibility when using AI, such as:

• Using multiple API keys per provider (e.g., by team, resource environment, or use case) so you can better manage access and usage limits.
• The same granular permissions and governance controls, allowing admins to decide who can create or modify specific AI resources.
• Clearer auditability and visibility into which apps and workflows are using which provider and key.
• Easier multi-provider setups, letting you mix and match models from different providers in the same workspace.

The dedicated AI Action query is also being deprecated as its functionality will be available in AI resource queries.

• Free and Team plan users can choose between light or dark mode and select an accent color.
• Business and Enterprise plans support organization-level theming. Alternatively, users can select a theme preset.
• All plans can configure an app theme via the prompt. Be very clear and specific about your design intent. For example, "Create a dark mode theme with blue accent colors", or "Update the theme to match the Acme brand colors and style."

Retool released a Version 3.0 of the Microsoft SQL Server integration that includes various fixes and improvements. New Microsoft SQL resources will use this version by default. Existing resources can be updated using the Connector version setting.

Beginning in the 2026 Q3 stable release, Version 1.0 and Version 2.0 of the integration will be deprecated. Retool strongly recommends that you update your resource configuration before Q3 in order to prevent any interruptions and to resolve any unforeseen issues. If necessary, Retool may automatically migrate resources to Version 3.0 in order to ensure any issues are identified and resolved prior to the removal of the old versions.

There is a known breaking change introduced in Version 2.0 that will also apply when upgrading from Version 1.0 to Version 3.0:

Beginning in Version 2.0, array inputs must be passed as a string when used in string_split in order to pass the Microsoft SQL SDK validation. For example, select * from string_split({{[1,2,3]}}, ','); must change to select * from string_split({{[1,2,3].join(',')}}, ',');.

No breaking changes are expected between Version 2.0 and Version 3.0.

For Enterprise and Business plans, Retool now allows admins to control access to Assist and its Ask and Build modes. Organization admins can use roles and permissions to create roles and edit roles with one of the following permissions:

• Use Assist with Ask and Build mode
• Use Assist with Ask mode only
• No access to Assist

By default, all users have access to Assist and both Ask and Build mode through a preconfigured role. This role is called Assist Role or Editor, based on when your organization was created. Organization admins can edit these roles, or they can create new roles with more restrictive permissions.

This change is valuable for organizations that need to limit or prevent Assist usage to specific populations of users. For example, admins might wish to restrict Assist usage to user groups who do not have access to sensitive data or PII. Alternatively, admins could restrict access to all user groups except for a pilot group testing AI tools.

Multi-instance releases are now generally available to cloud instances and self-hosted instances on version 3.330 or later, with support for both apps and workflows.

Organizations using Source Control can manage releases of protected apps and workflows across multiple deployment instances. This feature enables you to publish different release versions across instances, making it easy to test newer versions on staging or development instances before promoting to production.

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.

Assist can now:

• Plan and build a multipage app from scratch.
• Create, edit, and rename pages.
• Move queries and code between global and page scopes.
• Create globally-scoped frames and components, such as Navigation, to help users move between pages.
• Identify and correct page scope errors.

While Assist is generating, navigating between pages is disabled to prevent errors.

• CVE-2025-55182
• CVE-2025-55183
• CVE-2025-55184

These vulnerabilities were related to React's server-side rendering systems which are not used by Retool. As such, there is no action for cloud- or self-hosted customers to take.

Retool's website was also not impacted. We confirmed with our vendor that these vulnerabilities were already mitigated before being publicly disclosed. After the patches were released they applied the patches the same day.

Retool now supports two modes for prompting with Assist: Ask and Build. Use Ask as a safe, read-only way to understand and debug your app without adding or changing components or logic, and Build when you’re ready for Assist to make edits.

• Ask mode: Assist replies with explanations, suggestions, or debugging help. When in Ask mode, Assist cannot modify your app.
• Build mode: Assist can create and edit components, queries, and logic in response to your prompt.

Both modes use the same understanding of your app, your data, Retool features, and documentation.

Assist defaults to using Build mode. You can switch between modes at any time.

Retool added support for DeepSeek-V3.2 in Baseten. DeepSeek-R1 is no longer supported, and DeepSeek-V3.2 will be used instead.

Assist can now automatically summarize long threads. The amount of information sent to the AI provider (the context window) increases as you build. Instead of sending your full message history to the AI provider with every request, Retool now regularly compacts the thread and sends the conversation summary along with any following messages. This improvement keeps the context window within the required limits, reducing the likelihood of errors and preventing interruptions when prompting with Assist.

Thread summarization can occur either during or after app generation.

The Agent-to-agent (A2A) protocol provides standardized and secure communication between external agents and agents built with Retool, so you can trigger your agent from an external agent, or embed agents in your own systems.

Retool has implemented the core set of A2A functionality, so you can:

• View an agent card.
• Send a message.
• Poll for updates on tasks.
• Stream processing or task updates via Server-Sent Events (SSE).
• Cancel tasks.

To allow external agents to communicate with Retool agents, you can enable the A2A trigger on your agent's configuration page, and copy the endpoint and API key into your A2A client. The A2A client then sends messages via common messaging formats like the HTTP+REST and JSON-RPC APIs, and Server-Sent Events (SSE) for long-running streaming updates.

Explore the following pages for more information:

• Set up an A2A trigger to learn how to enable the A2A trigger.
• A2A endpoints to learn how to cURL for endpoint responses.
• A2A tutorial to learn how to trigger your agent from an external agent.

Assist can now more reliably explore large or under-documented SQL database schemas without exceeding LLM context windows. These changes enable Assist to generate higher quality SQL queries for your apps and reduce the likelihood of SQL-related errors.

Customers with simple schemas now benefit from richer context retrieved through exploratory queries, while large enterprises can rely on Assist to navigate massive data lakes.

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

The multiple configurations beta is available in self-hosted Retool 3.300 and later.

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.

For full release notes, see Self-hosted Retool 3.300 release notes.

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.

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 or Kubernetes 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 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​

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.

Retool now supports an integration to Google Slides, which utilizes the Google Slides API and the Google Drive API. Use this integration to retrieve, create, and update documents for apps, workflows, and agents.

Retool now supports Azure OpenAI for use with Assist. Admins on the Enterprise plan can configure Assist to use Azure OpenAI as the single model provider for Assist-powered interactions.

Retool designed Assist to use two AI providers by default: OpenAI and Anthropic. Using both providers enables Assist to optimize for speed and quality. However, some customers may need to consolidate AI services with a single provider. To accommodate these customers, Enterprise organizations can configure Assist to work with a single provider.

Retool no longer supports Claude Sonnet 3.5. Claude Sonnet 4.5 will be used instead.