Retool now supports performing web searches from the Chat tab of the app builder and from functions in draft or published apps. While building apps, the agent can access the internet to answer questions or provide more context. Web searches use a Tavily account that Retool manages for you.

Your apps can also use functions to perform web searches. Prompt the agent to include the search functionality that the users will need.

Web search is on by default. Admins can disable this feature by toggling off Web search in Settings > AI.

Workflows triggered by a schedule, a webhook, or a query, can now run as a service user. Service users for workflows are available on Business and Enterprise plans. Previously these runs defaulted to running as the first admin in your organization.

Select a permission group in the Triggers panel of the workflow IDE. Retool creates a service user for the group, and triggered workflows run as that service user. Only members of the group and admins can edit workflows running as a service user, and run logs are limited to people in the service user group.

Key features of this release include:

• Service users allow workflows run against resources with data access enforcement turned on. Scheduled and webhook-triggered workflows no longer need a separate unenforced resource. Grant the service user group access in your access policies.
• Service users do not count toward your user seats.
• Audit logs record actions that a service user performs under the existing event types, with the service user's ID as the actor.
• Source control includes a workflow's run identity in its YAML file. On deploy, Retool matches the service user by ID, then by group name.

If an admin deletes a service user group, workflows set to run as that group will fail until you choose a new group.

To get started, refer to Run a workflow as a service user. For details on how run identities work, refer to Service users for workflows.

• Retool 4.34.16
• Retool 4.0.28

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

Apps, workflows, and queries that depend on Microsoft SQL resources still using version 1.0 or 2.0 stop working. This follows the deprecation announced in July.

What to do​

Update each affected resource to version 3.0:

1. Open the resource from the Resources page.
2. Change Connector version to Version 3.0.
3. Save your changes.

Version 3.0 accepts array values in query parameters, so you don't need to rewrite existing queries. If you haven't intentionally created a resource on an older integration version, your resource is likely already on version 3.0.

You can now use the Build with tests setting to validate that your app is functioning as expected and catch unintended changes before you publish your app to end users. Toggle this setting on from the chat settings or from the debug console.

When app testing is enabled, the agent writes or updates tests whenever it adds or changes behavior in your app. By default, the agent writes a small set of behavioral tests. After the agent makes any changes to your app, Retool runs the tests related to those changes. If any of them fail, Retool sends the failures to the agent, which continues working to fix them.

The Retool Blueprints listing enables you to deploy self-hosted Retool to Google Kubernetes Engine (GKE) as a prepackaged Kubernetes app. Deploying Blueprints requires a Retool license key. Blueprints has no usage fee, but Google Cloud charges for the GKE resources you run.

• Retool 4.34.15
• Retool 4.0.27

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

GPT 6.1 Terra is now available in Retool through OpenAI. It can be used with AI resource queries and building apps.

• Retool 4.34.14

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

Retool now supports the use of private npm registries for apps. Enterprise organization admins can add registries in Settings > App Security, and builders can then ask the agent to install packages from them. Use private registries to:

• Download a specific package from a private registry. For example, pull a design system that you host on your own servers into your apps.
• Download all packages from a specific registry. Add a registry as the default, or route entire npm scopes (such as @acme) to it. Registries can require authentication with a bearer token or basic auth, or allow anonymous access.
• Control which packages are allowed. Build your own registry with rules about what it permits users to download. For example, enforce a minimum package age that you configure yourself.

Private registries must be npm-compatible and use HTTPS.

Admins for cloud-hosted instances on Enterprise plans can now set spend limits on AI usage using the new Spend Controls tab in the AI monitoring settings.

Limits work for both Retool-managed keys (credits) and bring your own key (tokens). Set an organization-wide default user limit, then override it for specific users or groups. You can also set a limit on a model to cap its total usage across your organization. For each, you can set a Notify at limit, which sends notifications and lets usage continue, and a Block at limit, which blocks further usage. A user's effective limit is their own limit, then the highest limit among their groups, then the default. Model limits apply separately from user and group limits.

When a builder reaches a block limit, AI app building pauses and they can send a limit increase request to admins. Admins can review requests in the Spend Controls tab or from the Action center on the Overview page, then approve a higher limit or deny the request. Retool also sends email notifications when limits are reached.

Buying additional AI credit packs by card is now available on all paid plans. Admins can buy a pack directly in Retool if their monthly allocation is running low.

To buy credits, go to Settings > Plans & Billing, select the AI Credits tab, then click Buy credits. Credits are available as soon as payment succeeds.

Purchased credits expire at the end of the next calendar month. For example, if you buy credits on October 20, they expire on November 30. On Enterprise plans with named seats, credits included with builder seats are used first. Then Retool uses your organization's monthly credits, then purchased credits.

The AI Credits tab also shows your additional AI credit history, including when each pack was added, how many credits remain, and when they expire.

Retool's AI-powered app builder is now generally available. Since first releasing the app builder in May 2026, Retool has continually expanded its capabilities to include:

• The ability to build from anywhere using the MCP server or CLI. Learn more about the difference.
• Flexible prompts that enable planning changes, creating new resources, or queueing messages.
• Comprehensive support for all resources available in Retool.
• Full source control support, including protecting apps, transitioning between development environments, and multi-instance releases.
• Expanded management tools, including custom Content Security Policies, org-wide agent context, and the ability to embed apps.

Whatever or however you build, your apps inherit the security standards your organization has already approved and implemented.

To get started, admins can use the configuration guide to set up their organization to use the app builder.

• Retool 4.34.13
• Retool 4.0.26

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

• Several of eMudhra's emSign intermediate certificate authorities were compromised and revoked upstream. Components bundled in Retool trusted certificates signed by those intermediates.
• This created a man-in-the-middle risk for self-hosted instances on affected versions: an attacker would need both a certificate from the compromised intermediates and a network position between your instance and an external endpoint.
• Cloud was patched centrally. Self-hosted customers should upgrade.
• IOCs: None. No exploitation observed, and no indication any maliciously signed package was pulled in.
• Maintained stable releases contain a full fix (v4.0 and newer), version 3.334 received a partial fix for the Node, Python, and PIP systems, Java was not patched due to no upstream patch available.

What happened​

eMudhra's emSign intermediate CAs were compromised and revoked, and upstream projects (OS ca-certificates, Node.js, Java, and Python certifi/pip) distrusted them. Retool components ship their own bundled CA lists, so older Retool versions continued to trust the compromised chain even on a patched host OS.

Affected components​

The upstream issue is the compromised emSign intermediate CAs (emSign ECC Root CA - G3 and the Comodo AAA Services cross-sign root). Retool components that validated certificates against a bundled CA list were affected:

• Node.js.
• The database connector's Java runtime.
• The OS CA bundle.
• The code executor's Python (requests/pip), custom Python environments, and drivers such as @sap/hana-client and oracledb (thick mode).
• The telemetry sidecar and the fluent-bit image.

Affected versions​

Note: 4.0.23 and 4.34.10 do not contain the fix. Do not treat them as patched.

Fixed versions​

Am I affected?​

If you run a self-hosted instance on an affected version, it continues to trust the compromised chain. Exploitation would require an attacker to hold a certificate from the compromised intermediates and to sit in the network path between your instance and an external endpoint. There is no indication of actual exploitation. Customer-provided CA certificates attached to a resource apply only to that resource's connections and are never added to a shared or system trust store.

What you should do​

• Cloud: No action. Patched centrally on 2026-10-21.
• Self-hosted 4.0 line: Upgrade to 4.0.25.
• Self-hosted 4.34 line: Upgrade to 4.34.12.
• Self-hosted edge: Upgrade to 4.81.0.
• Self-hosted legacy 3.334: Upgrade to the 3.334 patch or move to v4. The 3.334 patch is partial — it fixes Node but not Java or host-level items.

Do not rely on 4.0.23 or 4.34.10; they do not contain the fix.

CVE details​

Revision history​

• 2026-10-26 — Initial publication.

• Retool 3.334.32

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

Retool Cloud was patched on October 21, 2026, at 4:44 PM PDT, 13 hours and 6 minutes after public disclosure. No action is required for Cloud customers. Self-hosted customers should upgrade to a fixed version.

The same Node.js release fixes other vulnerabilities that have a lower impact on Retool. Upgrading to a fixed version addresses all of them. For details on each one, refer to Vulnerabilities in this release.

We have no indications of malicious activity using this vulnerability against Retool. The vulnerability was disclosed publicly by the Node.js project on October 21, 2026, at 3:38 AM PDT, as part of its October 2026 security releases.

We will communicate further updates here, should such become necessary.

The CVSS scores above are specific to Retool. They reflect how an attacker reaches this vulnerability through Retool, which in most cases requires a user with permission to create or edit resources or queries that send requests to URLs they choose. NVD hasn't scored CVE-2026-111497 at the time of writing. Google, the CVE Numbering Authority for this vulnerability, scored the underlying Node.js issue 9.2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N).

Am I affected?​

Retool Cloud has been patched, and Cloud customers don't need to take any action.

Self-hosted instances running a version earlier than the fixed versions are affected. To exploit this vulnerability, an attacker needs to make your instance send an HTTP request to a server they control and receive its response. Retool sends HTTP requests to user-configured URLs in several places, including:

• REST API, GraphQL, OpenAPI, and MCP resources.
• OAuth 2.0 authentication, which sends token requests to the access token URL configured on a resource.
• Custom AI providers configured with a custom base URL.

This is possible for:

• Users with permission to create or edit these resources or AI providers, or to edit apps or workflows that contain their queries.
• Anyone who controls, or has compromised, a server that one of these resources already sends requests to.
• App users who can supply a request URL, if an app builds request URLs from user input.
• Anyone who can intercept and modify unencrypted HTTP traffic between your instance and a server.

Integrations that only connect to a fixed vendor endpoint, such as Stripe or Google Sheets, are lower risk. Exploiting them would require compromising the vendor or intercepting encrypted HTTPS traffic.

Retool images also ship a separate system Brotli library that curl and git use. Refer to System Brotli libraries for that narrower path.

What are the mitigations or remediations?​

The only complete fix is to upgrade your instance to a fixed version.

Until you can upgrade, mitigate your exposure by doing the following:

• Review which users can create or edit resources, AI providers, apps, and workflows, and limit these permissions to users who need them.
• Review your resources and queries for request URLs and OAuth 2.0 access token URLs on hosts you don't recognize.
• Use HTTPS for resources that send HTTP requests so that responses can't be modified in transit.
• Review which Source Control remotes your instance connects to, and prefer HTTPS remotes you control.

What is the impact?​

An attacker who exploits this vulnerability can run code in the Retool service that received the malicious response. This is the DB_CONNECTOR service for resource queries, and the MAIN_BACKEND service for OAuth 2.0 token requests and custom AI providers. From there, they could access the resource credentials and query data that pass through the service, and reach any internal systems that the service has network access to.

MAIN_BACKEND runs in the api container. By default, DB_CONNECTOR also runs inside the api and workflows-backend containers, as described in System architecture. Code running in these containers has access to everything they can access, including your encryption key and the Retool database.

System Brotli libraries​

Retool images also ship a system Brotli library that is separate from the decoder bundled in Node.js:

• On Debian-based images, this is the Debian libbrotli1 package, pulled in because git and curl depend on libcurl.
• On hardened Chainguard/Wolfi images, this is libbrotlidec and related packages.

Git uses that library when it fetches over HTTP. An attacker who can make your instance's git client fetch from a server they control, and who returns a crafted Brotli-compressed response, could trigger the vulnerability in the system library. Source Control clone and fetch operations use this path when they talk to an HTTP or HTTPS remote.

This path is narrower than the Node.js path described above. It isn't reachable through a REST API resource query. It requires control of, or a compromise of, a Git remote that Source Control connects to, or the ability to intercept that Git traffic. Upgrading to a fixed version updates both the Node.js runtime and the system Brotli libraries.

What are indicators of compromise (IOCs)?​

A failed attempt to exploit this vulnerability is likely to crash the process. A successful attempt can lead to activity that Retool services don't normally perform. Check the api and workflows-backend containers, and any separate DB_CONNECTOR containers, for:

• Unexpected crashes or restarts, especially processes that end with a SIGSEGV signal.
• Unexpected processes started inside those containers.
• Outbound connections to internal systems those containers don't normally contact, such as your cloud provider's metadata service.

Also check for resources or queries that point to unfamiliar hosts, including OAuth 2.0 access token URLs, and for recent changes to them in your audit logs. For the system Brotli path, also check Source Control remotes and recent git clone or fetch activity.

Vulnerabilities in this release​

The Node.js October 2026 security release fixes the following vulnerabilities in Node.js 22, the version Retool uses. The severity is the rating from the Node.js project. The impact describes Retool's assessment of how each vulnerability affects Retool.

The sections above describe CVE-2026-111497 in detail. The release also updates the versions of c-ares, OpenSSL, SQLite, undici, and the root certificates bundled with Node.js.

CVE-2026-106069 and CVE-2026-106072: TLS certificate hostname validation​

In some cases, Node.js could accept a TLS certificate that doesn't match the host it connects to. CVE-2026-106069 applies when a hostname loosely resolves to an IP address. CVE-2026-106072 applies when a host is an IPv4 address written in a non-canonical form, such as 127.1 or 0x7f.0.0.1, which lets a certificate issued for a DNS name authenticate an IP address.

Retool relies on Node.js to validate certificates when it connects to resources over HTTPS or TLS. An attacker who can intercept traffic between Retool and a resource could use these vulnerabilities to impersonate that resource. This could expose the credentials and query data that Retool sends to it. Resources configured with an IP address as their host are the most exposed. Until you upgrade, prefer DNS hostnames over IP addresses in resource configurations.

CVE-2026-105482: DNS resolution of names with NUL characters​

The Node.js dns.resolve functions truncate a hostname at the first NUL character, so they can resolve a different name than the one requested. Retool uses these functions in checks that block requests to private IP addresses. In those checks, Retool reads the hostname from a parsed URL, which can't contain a NUL character. Based on our assessment, this vulnerability isn't exploitable in Retool.

CVE-2026-105481: HTTP keep-alive responses​

When Node.js reuses a connection for more than one HTTP request, it could treat data that a server sent before a request as the response to that request. Retool reuses connections for outbound HTTP requests, including resource queries. Retool only reuses a connection for requests to the same server, so a malicious server can only affect responses that already come from that server. We assess the impact on Retool as low.

CVE-2026-106073: Permission model bypass​

The Node.js permission model restricts which files a process can access, and fs.realpathSync could bypass these restrictions. When AI App Builder runs tests for an app inside its sandbox, Retool uses the permission model as an extra restriction on which files the tests can read. A bypass could let test code read other files inside the sandbox. The sandbox's own isolation still applies, so we assess the impact on Retool as low.

Vulnerabilities that don't affect Retool​

Some vulnerabilities in the release don't affect Retool:

• CVE-2026-106074 causes values from crypto.randomUUID() and crypto.randomInt() to repeat across processes started from a user-land startup snapshot or a single executable application. Retool doesn't use either feature.
• CVE-2026-105483, CVE-2026-106070, and CVE-2026-106071 only affect Node.js 24 or Node.js 26. Retool uses Node.js 22.

What versions are affected?​

Self-hosted Retool only.

What versions contain the fix?​

Self-hosted Retool only.

Revision history​

• October 23, 2026: Initial publication with fixed Stable versions 4.34.12 and 4.0.25.
• October 29, 2026: Added Edge 4.81.0 and Stable 3.334.32. Documented the separate system Brotli library path (Debian libbrotli1 and Wolfi libbrotlidec).

Questions​

For the full Node.js advisory, refer to the Node.js October 2026 security releases. If you have any questions or concerns, contact security@retool.com.

• Retool 4.34.12
• Retool 4.0.25

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

• Retool 4.34.10
• Retool 4.0.23

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

• PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is an upstream PHP vulnerability.
• Retool is not affected. PHP does not run on anything internet-facing, nor does it run in our production environments.
• No action required.

What Happened​

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a set of vulnerabilities in PHP. Retool became aware of them and opened an investigation on October 21, 2026.

Customer Guidance​

Retool is not affected, no customer action is required.

Impact​

PHP does not run on anything internet-facing, nor does it run in production or on anything connected to production. Retool is still reviewing third-party vendors for exposure and will update this page when we have completed our investigation.

Revision History​

• 2026-10-21 — Initial publication.

Gemini 4 Argon is now available in Retool through Google and Google Vertex AI. It is available to Enterprise organizations that bring their own key.

Use Gemini 4 Argon with AI resource queries and building apps.

Enterprise organizations can now implement multi-instance releases for apps using any supported SCM provider: AWS CodeCommit, Azure Repos, BitBucket, GitHub, and GitLab.

To enable multi-instance releases, navigate to Settings > Source control > Edit settings and turn on Enable multi-instance releases.

This feature enables you to publish different release versions across instances, making it possible to test a newer version on staging or development instances before promoting to production. Get started with multi-instance releases for apps.

• Retool 4.34.9

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

Retool now supports the following new AI models:

• GPT 6.1 Sol through OpenAI for AI resource queries and building apps.
• Claude Sonnet 5.5 through Anthropic and Amazon Bedrock for AI resource queries and building apps.

Organizations on paid plans can prompt the app building agent to use resource environments in published apps. Resource environments enable you to run a function against different configurations of the same resource, such as staging and production, and were previously only available in Edit mode for apps.

Optionally, prompt the agent to add a UI element that allows app users to switch between resource environments.

In addition, you can use the _environment URL query parameter to open an app in a different environment, such as ?_environment=staging. This URL parameter works automatically and does not require prompting.

Organizations on the Business plan now have access to Retool-provided AI models for app building. These models, prefixed with Retool, have been tuned by Retool for enhanced performance and speed for app building.

The following Retool-provided models are supported:

• Retool Mini
• Retool Power

• Retool 4.34.8
• Retool 4.0.21

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

• Retool 4.34.7

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

Business and Enterprise organizations can now use the Retool API to authenticate apps that are embedded in an app or website external to Retool.

Once configured, the custom authentication flow exchanges an API token for an embed URL. When a parent app authenticates a user using your preferred authentication method, the parent app makes an API request to Retool to generate an embed URL. This embed URL is a secure, single-use link on the domain of your published app. Loading it in the iframe exchanges the link for a session, sets the cookies the app needs, and then displays the app.

Standard authentication through Retool remains supported.

You can now prompt the app building agent to create REST API or PostgreSQL resources directly from the app builder.

Describe the resource that you want to create, and the agent initiates the resource creation process. You'll be asked to provide credentials or more details where applicable.

Retool now supports the following new AI models for AI resource queries:

• GPT 6 Luna.
• GPT 6 Sol.
• Enterprise only: GPT Image 2.5 Flare. Must bring your own key.
• Enterprise only: GPT Image 2.5 Sunburst. Must bring your own key.

• Retool 4.34.6
• Retool 4.0.19
• Retool 3.334.31

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

Organizations on the Team plan can now use Retool-provided AI models for app building, in addition to the full catalog of supported models. These models, prefixed with Retool, have been tuned by Retool for enhanced performance and speed for app building.

The following Retool-provided models are supported:

• Retool Mini
• Retool Power

Claude Opus 5.5 is now available in Retool through Anthropic for all paid plans and through Amazon Bedrock for Enterprise plans. It can be used in the following ways:

• For AI resource queries with your own key.
• For app building with a Retool-managed key or with your own key.

• Retool 4.34.5
• Retool 4.0.18

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

The drag-and-drop experience for building and maintaining classic apps is still available. For an AI-powered building experience, Retool recommends using the new app builder. Converting your classic apps to the new app builder is free for Team, Business, and Enterprise organizations.

If you have any questions, reach out to the Community Forum or your account manager.

Retool Email remains available to organizations on the Team, Business, and Enterprise plans.

Who is affected​

This change affects cloud-hosted organizations on the Free plan that use Retool Email. Organizations on paid plans are not affected.

What to do​

To avoid disruption to apps and automations that depend on Retool Email, either upgrade your organization to a paid plan or switch to another email resource before January 1, 2027.

Retool supports several other ways to send emails:

• SendGrid.
• Gmail.
• SMTP.
• Your email service provider's API, using a REST API resource.

After you configure a new resource, update any queries that use Retool Email to use the new resource instead.

If your custom authentication steps use any of these libraries, you can migrate to Node.js built-in equivalents, such as crypto and Buffer, well ahead of the removal date. Migrating before then avoids any disruption to your authentication flows.

Only REST API, GraphQL, OpenAPI, and gRPC resources that use Custom Auth with a JavaScript step that loads a preinstalled library are affected. JavaScript steps that use Node.js built-in modules, such as crypto, continue to work without changes.

Who is affected​

Any customers who have resources that use Custom Auth as its authentication method and one of its JavaScript steps loads a preinstalled library. Custom authentication steps that only use Form (modal), API Request, or Define a variable steps aren't affected, and neither are JavaScript steps that don't call require().

What to do​

To check whether a resource is affected:

1. On the Resources page, open a REST API, GraphQL, OpenAPI, or gRPC resource that uses Custom Auth.
2. Review the code in each JavaScript step of the authentication flow.
3. Look for require() calls that load a preinstalled library, for example require('jsonwebtoken').

Calls that load Node.js built-in modules, such as require('crypto'), don't need any changes. For the full list of preinstalled libraries, refer to Custom authentication JavaScript libraries.

Migrate to a supported replacement library​

Each library that custom authentication JavaScript steps commonly load has a replacement that is built in to Node.js or JavaScript. The following table lists the recommended replacement for each.

JavaScript steps don't have access to the global fetch() function. To make HTTP requests, use the https module or add a separate API Request step. For more information, refer to "Replace request and axios" below.

If your step uses a library that isn't listed here, contact Retool Support for help identifying a replacement.

const jwt = require('jsonwebtoken');

return jwt.sign({ sub: userId }, jwtPrivateKey, {
  algorithm: 'RS256',
  expiresIn: '1h',
});

const crypto = require('crypto');

const base64url = (obj) => Buffer.from(JSON.stringify(obj)).toString('base64url');
const now = Math.floor(Date.now() / 1000);

const header = base64url({ alg: 'RS256', typ: 'JWT' });
const payload = base64url({ sub: userId, iat: now, exp: now + 3600 });
const signingInput = `${header}.${payload}`;

const signature = crypto
  .sign('sha256', Buffer.from(signingInput), jwtPrivateKey)
  .toString('base64url');

return `${signingInput}.${signature}`;

const signature = crypto
  .sign('sha256', Buffer.from(signingInput), {
    key: jwtPrivateKey,
    padding: crypto.constants.RSA_PKCS1_PSS_PADDING,
    saltLength: crypto.constants.RSA_PSS_SALTLEN_DIGEST,
  })
  .toString('base64url');

const jwt = require('jsonwebtoken');

return jwt.sign({ sub: userId }, jwtSecret, { expiresIn: '1h' });

const crypto = require('crypto');

const base64url = (obj) => Buffer.from(JSON.stringify(obj)).toString('base64url');
const now = Math.floor(Date.now() / 1000);

const header = base64url({ alg: 'HS256', typ: 'JWT' });
const payload = base64url({ sub: userId, iat: now, exp: now + 3600 });
const signingInput = `${header}.${payload}`;

const signature = crypto
  .createHmac('sha256', jwtSecret)
  .update(signingInput)
  .digest('base64url');

return `${signingInput}.${signature}`;

const crypto = require('crypto');

const base64url = (obj) => Buffer.from(JSON.stringify(obj)).toString('base64url');
const now = Math.floor(Date.now() / 1000);

const header = base64url({ alg: 'ES256', typ: 'JWT' });
const payload = base64url({ sub: userId, iat: now, exp: now + 3600 });
const signingInput = `${header}.${payload}`;

const signature = crypto
  .sign('sha256', Buffer.from(signingInput), {
    key: jwtPrivateKey,
    dsaEncoding: 'ieee-p1363',
  })
  .toString('base64url');

return `${signingInput}.${signature}`;

const jwt = require('jsonwebtoken');

return jwt.decode(token);

const [, payload] = token.split('.');

return JSON.parse(Buffer.from(payload, 'base64url').toString('utf8'));

return new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'short',
  timeStyle: 'long',
}).format(new Date());

const { v4: uuidv4 } = require('uuid');

return uuidv4();

const crypto = require('crypto');

return crypto.randomUUID();

const axios = require('axios');

const response = await axios.post('https://example.com/oauth/token', { userId });

return { status: response.status, body: response.data };

const https = require('https');

const body = JSON.stringify({ userId });

return await new Promise((resolve, reject) => {
  const req = https.request(
    'https://example.com/oauth/token',
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Content-Length': Buffer.byteLength(body),
      },
    },
    (res) => {
      const chunks = [];
      res.on('data', (chunk) => chunks.push(chunk));
      res.on('end', () => {
        const data = Buffer.concat(chunks).toString('utf8');
        try {
          resolve({ status: res.statusCode, body: data ? JSON.parse(data) : null });
        } catch (err) {
          reject(err);
        }
      });
    }
  );
  req.on('error', reject);
  req.write(body);
  req.end();
});

Test your migrated flow​

After you update each JavaScript step, confirm that the authentication flow still works:

1. Click Save changes.
2. Click Test auth workflow and complete any form steps.
3. Review the JavaScript step output in the log and confirm that it returns the value your API expects. For a JWT, you can decode the token to compare its header and claims with the token the previous step produced.
4. Run a query that uses the resource to confirm that your API accepts the new credentials.

If a step fails with an error such as Cannot find module 'jsonwebtoken', the step still loads a preinstalled library. Replace the remaining require() call using the examples in this post.

Hardened images are intentionally minimal and don't include the additional third-party libraries and utilities that Windows Authentication relies on. Microsoft SQL Server resources with Connect using Windows Auth enabled will eventually stop working, so plan to migrate before your resources are affected.

Who is affected​

This change only affects self-hosted organizations with Microsoft SQL Server resources that have Connect using Windows Auth enabled.

What to do​

Update each affected Microsoft SQL Server resource to use Username and password authentication with a SQL Server login:

1. Create a SQL Server login with the permissions your apps and workflows need.
2. Open the resource from the Resources page.
3. Disable Connect using Windows Auth.
4. Enter the SQL Server login in Database username and Database password. Use configuration variables or Retool secrets to store the credentials.
5. Click Test connection, then save your changes.

These images are used by Retool for its cloud-hosted platform and are available for self-hosted organizations to adopt. Eventually, all images used by Retool will be hardened.

Hardened images are built on a minimal, tightly controlled base to improve supply-chain security and reduce the attack surface. They also benefit from a smaller, more tightly curated set of included software, which reduces the risk of security vulnerabilities.

Retool is continuing to work on new and existing hardened images. Over time, this means some existing features and bundled libraries will no longer be supported in their current form. If a feature or library will no longer be available, or if a change requires updates to your current configuration, Retool will share this information in a changelog post with specific information and any relevant migration guidance.

Each changelog post will provide as much advance notice as possible so that you have time to review and implement any changes that may be needed.

Organizations on the Free plan now use Retool-provided AI models for app building. These models, prefixed with Retool, have been tuned by Retool for enhanced performance and speed for app building. Access to models from other providers is now only available on paid plans.

Builders using these models will notice comparable quality and faster speeds when compared with other models previously available on the Free plan.

The following Retool-provided models are supported:

• Retool Mini
• Retool Power

Retool now supports using external MCPs as resources in the app builder. The app building agent creates function calls to utilize tools from your connected MCP servers, which can be used while building or at app runtime. For example:

Users of the published app can only trigger MCP tools for which they have permission.

The Retool CLI is now available in public beta. It enables you to build, manage, and publish Retool-native React apps from the command line and with the help of your chosen code development agent harness, like Claude Code or Codex.

With this tool, you can write and validate app code directly on your machine. You can use the CLI independently or pair it with a local development agent. Follow the installation instructions to get started, learn how the CLI works, or compare the CLI to the MCP.

• Retool 4.34.4
• Retool 4.0.17

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

You can now embed apps in other apps, in classic apps, and in apps or websites outside Retool using an iframe. To enable app embedding, an organization admin adds Content Security Policy directive rules that name the pages that are allowed to frame your app.

Refer to the Embed apps guide to learn how.

• Retool 4.34.3
• Retool 4.0.16

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

Retool now supports the following new AI models:

• GPT 5.4 Mini through OpenAI for AI resource queries.
• GPT 5.4 Nano through OpenAI for AI resource queries.
• GPT 6 Astra through OpenAI for AI resource queries.
• Claude Fable 5.1 through Anthropic and Amazon Bedrock for AI resource queries.
• Gemini 3.8 Flash through Google and Google Vertex AI for AI resource queries.

• Retool 4.34.2
• Retool 4.0.15

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

Retool previously documented this as a breaking change and recommended converting array values with .join(',') before using them with STRING_SPLIT. The restriction was broader than documented: it applied to any query parameter set to an array value, whether or not the query used STRING_SPLIT. Version 3.0 removes the restriction entirely, so queries that pass array values no longer need to be rewritten. Queries that already use .join(',') produce the same value and continue to work without changes.

This was the only known breaking change between version 1.0 and version 3.0. You can now update an existing Microsoft SQL resource from version 1.0 or version 2.0 to version 3.0 without changing your queries. Versions 1.0 and 2.0 are deprecated and will be removed, so Retool recommends updating any resource still using them.

Query parameters set to an object are not supported and cause the query to fail. Convert an object to a string before using it in a query, for example with JSON.stringify.

Retool introduced several features to help Enterprise organizations manage AI usage.

Use the new centralized settings page, AI visibility, to view AI credit usage and BYOK AI token usage. Navigate to Settings, and select Retool managed keys or Bring your own key from the dropdown at the top of the page. You can filter AI usage by instance, model, user, and feature.

Enterprise organizations can also use the new Get AI credit usage endpoint to measure the number of credits consumed for each AI resource that uses a Retool-managed key. You can view the number of credits consumed by resource, user, and surface area.

Learn more about credit and token monitoring.

• Retool 4.34.1
• Retool 3.334.30
• Retool 4.0.14

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

Cloud Retool organizations can now connect to Gmail as a resource to read, send, and manage email using the Gmail API.

Cloud organizations can authenticate using Retool's hosted OAuth app.

Retool now supports manual file management of apps from the Code tab of the app builder. This enables builders to exercise finer-grained control over code files without needing to prompt the agent and consume credits.

Builders can manually add:

• Folder: A new empty folder inside the frontend or backend directory of your app.
• Frontend component: A new TypeScript file that represents a React component, which Retool populates with a basic structure of the component.
• Frontend file: A new generic frontend file. Provide the full file name, including the file extension.
• Backend function: A new TypeScript file that represents a function, which Retool populates with the basic structure of a function.
• Backend file: A new generic backend file. Provide the full file name, including the file extension.

Builders can also delete certain files or folders, including those that define components and backend functions, or other temporary or user-written files.

You can now queue messages in Chat tab of the app builder. While the agent is working, you can send up to five messages, which will be automatically sent in a batch once the agent responds.

You can edit or remove messages from the queue before they are sent, or clear the queue of all messages.

• Retool 4.0.13

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

Retool introduced finer controls on branches in the app builder. You can now rename branches from the Change History panel by hovering over a branch name and clicking the icon.

You can also copy the branch name, which enables builders using Source Control to transition between development in the app builder and development locally. Learn more about switching development environments.

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 4.34 release notes.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, BigID resources will stop working. Queries in apps and workflows that still point at those resources will fail. Cloud and self-hosted organizations will not have a BigID connection option after removal.

Organizations can keep querying BigID after removal by creating a REST API resource. Retool will not migrate BigID resources or their query references automatically.

1. Create a REST API resource. To use guided query creation, select Use an API spec and enter the specification URL https://sandbox.apps.mybigid.com/BigAPI.yaml or the BigAPI.yaml URL for your BigID instance, with the environment server variable set to your BigID hostname. Otherwise, select Manual queries and set the base URL to https://HOSTNAME/api/v1.
2. Set Authentication to Custom Auth. Add an API Request step that sends POST /api/v1/refresh-access-token with your BigID user token in the Authorization header. Add a Define a variable step named SYSTEM_TOKEN with value {{ http1.body.systemToken }}. Add an Authorization header on the resource that uses {{ SYSTEM_TOKEN }}. Enable Run this custom auth workflow without prompting the user. Configure a refresh auth workflow that repeats the exchange after a non-200 response. Generate the user token in the BigID UI and exchange it as described in BigID's token authentication.
3. Open each app, workflow, and Query Library query that uses the BigID resource. Change the query to use the new resource, then test it. If you used an API spec, select the same operation. Otherwise, recreate the request as method and path, such as GET /ds-connections. If the query editor shows an Authorization parameter, leave it empty.

Custom authentication is not supported in public apps. If you have a large number of BigID queries and need help finding them, contact Retool Support.

• Retool 4.0.12

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

The app builder now includes a debug console to help you inspect your app, surface issues, and resolve them with the agent. Open it from the status bar at the bottom of the app builder.

The console has three tabs:

• Errors: Function, build, and frontend errors. Hover a row to add its context to the chat or ask the agent to fix it, or click Fix all to resolve every error at once.
• Logs: Logs emitted by the app or the agent, including function, build, frontend, sandbox, agent, and git events.
• Timeline: A record of function runs with the elapsed time and the success of each, useful for diagnosing performance issues.

The agent has access to the same information available to builders in the debug console. This enables the agent to disagnose and address issues more quickly, and it can write more performant functions.

Multi-instance releases are now supported for apps built in the new app builder, in addition to classic apps and workflows. To enable multi-instance releases, navigate to Settings > Source control > Edit settings and turn on Enable multi-instance releases.

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

Multi-instance releases work slightly differently for apps and classic apps. Learn more about the difference, or get started with multi-instance releases for apps.

The drag-and-drop experience for building and maintaining classic apps is still available. For an AI-powered building experience, Retool recommends using the new app builder. Converting your classic apps to the new app builder is free for Team, Business, and Enterprise organizations.

If you have any questions, reach out to the Community Forum or your account manager.

Enterprise organizations can use access policies to define which data each group of users can read or write on a resource. Retool enforces access policies on every query that runs against the resource. A policy can grant access to whole tables, specific columns, or specific rows.

For example, you can use an access policy to restrict an EMEA group's access on a table to only the customer rows for their own region. Retool applies that restriction to every query the group runs against the resource, so it holds regardless of which app, query, or agent the request comes from.

One policy covers queries from apps, the query library, raw SQL, and agents. Workflow queries against an enforced resource are blocked, so account for any workflows using the resource before you turn enforcement on. Retool supports access policies on PostgreSQL resources.

Access policies are enabled by default on cloud instances. On self-hosted instances, navigate to Settings > Beta and toggle on the feature flag for Enforce data security using access policies. To create a policy:

1. Open a PostgreSQL resource and select the Access Enforcement tab.
2. Turn on Data access enforcement.
3. Create a policy, choose the groups and environments it covers, and define its rules.
4. Activate the policy, then click Save changes.

Turning on data access enforcement closes the resource by default in every resource environment. Access policies apply only to the resource environments you select, so grant broad access first and narrow it once your policies are in place. Refer to Configure access policies for more details.

Access policies operate by granting access, not denying access. Refer to Access policies and Data access enforcement for more information.

You can now use Plan mode for further control over the actions that the app building agent takes.

1. Click to switch from Build mode to Plan mode and tell the agent what changes you want it to make.
2. The agent creates a comprehensive plan, which is written as a Markdown file in the .plan folder. Click Review to view the file.
3. Review the plan, and switch to the Markdown tab to make any changes. You can also ask the agent to update the plan.
4. When you're ready, click Build plan.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, Vertica resources will stop working. Queries in apps and workflows that still point at those resources will fail. Retool will no longer ship the Vertica JDBC driver. Cloud organizations will not have a Vertica connection option after removal.

Self-hosted organizations can keep querying Vertica after removal by creating a JDBC resource and adding a Vertica JDBC driver that you provide. Retool will not migrate Vertica resources or their query references automatically.

1. Download the Vertica JDBC driver from Vertica.
2. Add the .jar file to your self-hosted instance. Follow the JDBC configuration steps for JDBC_DIRECTORY_PATH.
3. Create a JDBC resource with Driver name com.vertica.jdbc.Driver, connection string jdbc:vertica://HOSTNAME:5433/DATABASE?user=USERNAME&password=PASSWORD&DisableCopyLocal=true, and schema query select table_name, column_name, data_type, table_schema from columns. Include DisableCopyLocal=true on the connection string.
4. Open each app and workflow query that uses the Vertica resource. Change the query to use the new JDBC resource, then test it.

JDBC resources do not support Retool-managed SSH tunnels. If your Vertica resource uses an SSH tunnel, or you have a large number of Vertica queries and need help finding them, contact Retool Support.

• Retool 4.0.10
• Retool 3.334.28

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

Gemini 3.6 Flash is now available to cloud organizations through Google. It can be used with AI resource queries when you connect Google with your own API key. Support for self-hosted Retool is coming in an upcoming release.

• Retool 4.0.9
• Retool 3.334.27

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

Organization admins can now add shared building context that applies to all apps built with the new app builder. Building context is applied as custom instructions in the system prompt when the user makes any changes via prompting in the Chat tab, similar to the way AGENTS.md files work. Building context is valuable for defining design practices, coding conventions, data usage recommendations, and other guidelines across your organization.

To add shared context, navigate to Settings > Building context. Add your instructions in Markdown format, and click Publish to apply your changes to all apps.

Building context applies to all apps in your organization. If you have Spaces enabled, it applies to all apps in your space.

Admins on the Enterprise plan can now complete each step in the Get started section of the Overview page using guided step-by-step wizards instead of navigating through separate Settings pages to complete configuration.

You can now directly configure from the Overview page:

• SSO
• Resources
• Source control
• Spaces
• Permissions

The Get started section is aimed at providing a better onboarding experience for admins of new organizations, and will help identify what configurations still need to be set up for admins or existing organizations. For example, setting up spaces walks you through choosing custom spaces or a Dev/Staging/Prod environment split, naming and configuring each space, and optionally copying over your existing SSO settings, before creating every space at once.

The Overview page also includes an Action center that contains important notifications and pending join requests, suggested users, and seat upgrade requests, so admins can act on what needs attention, as well an at-a-glance overview of your organization stats, such as total users, apps, workflows, and AI credit usage.

Retool introduced several features to help Enterprise organizations manage AI token spend when using their own API key for AI resources.

Use the new Get BYOK AI token usage endpoint to measure the number of tokens consumed for each AI resource that uses your own key. You can view the number of tokens consumed by resource, user, and surface area.

In addition, you can also view BYOK AI token usage in Settings. Navigate to the Usage Analytics page, and click the AI tab. You can filter AI usage by model, user, and feature.

Learn more about credit and token monitoring.

Self-hosted Retool instances can now connect to Gmail as a resource to read, send, and manage email using the Gmail API.

Self-hosted instances authenticate using your own Google Cloud OAuth client, so this integration is available now without waiting on Google's app-verification process for Retool's shared OAuth client.

The app builder now supports multiple chat conversations (threads) working on the same branch rather than a single thread per branch.

A thread is a single chat conversation with the agent in the Chat tab. Threads are intended to help you keep your work organized by task or theme. For example, use one thread for updating your app theme, and another thread for editing a chart on that page. Manage threads from the Chat tab.

A branch is a set of changes to your app, associated with an app preview, and with its own change history. A branch is the unit of work that you publish, and you create a new branch to begin a distinct line of work. For example, create a new branch when you want to change the resources that your app uses, or when you want to overhaul a page. Manage branches from the Change History tab in the navbar.

When using Source Control, branches in the protected app builder map to branches in your external git repository.

Claude Opus 5 is now available to cloud organizations through Anthropic. It can be used with AI resource queries and with Retool Agents. Opus 5 requires you to bring your own key for AI resource queries; Retool Agents can use Opus 5 with a Retool-managed key. Support for self-hosted Retool is coming in an upcoming release.

This deprecation will first take effect on cloud instances on August 24, 2026. It will then take effect in the next edge and stable releases that follow.

Version 3.0 has been available since February 2, 2026 for cloud instances and the 3.334 stable release. If you haven't intentionally created a resource on an older integration version, your resource is likely already on version 3.0 and requires no changes.

To upgrade an existing resource, open its settings from the Resources page, change Connector version to Version 3.0, and save your changes.

Versions 1.0 and 2.0 will be removed entirely from cloud instances in Q4 2026, followed by the subsequent edge and stable releases. After that, apps, workflows, and queries that depend on Microsoft SQL resources still using version 1.0 or 2.0 will stop working.

For Enterprise organizations that use Source Control to protect apps, you can now use the app builder to check out a branch that you created outside of Retool. This enables you to transition your changes from a local development environment to the app builder. This can be useful for visually validating your changes in the preview canvas.

When prompting in the Chat tab of the app builder, the agent asks clarifying questions to better understand your intent and create your desired outcome. The agent can ask multiple-choice or open-ended questions.

You can now build apps with more AI models: Claude Sonnet 5, the GPT-5.6 models (Sol, Terra, and Luna), and Claude Fable 5. Choose a model for each thread in the app builder's Chat tab. Admins can set the organization's default app building provider and model in the AI settings.

Claude Sonnet 5 can be used on paid plans with a Retool-managed key or your own key. The GPT-5.6 models and Claude Fable 5 require you to bring your own key, which is available on the Enterprise plan.

• Retool 4.0.7
• Retool 3.334.25
• Retool 3.334.24
• Retool 3.300.34

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

You can now upload files to be used as assets in your app through the Chat tab in the app builder. Previously, uploaded files could only be used as context for the agent.

Common use cases for uploaded files as assets include:

• Embedding PDFs.
• Adding a company logo to the app header.
• Presenting images within the app.

• Retool 4.0.6
• Retool 3.334.23

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

• Retool 4.0.5
• Retool 3.334.22
• Retool 3.300.33

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

Retool now supports object roles—a new role type that grants groups Use, Edit, or Own access to specific apps, workflows, resources, and agents. Object roles are separate from organization roles, which control access to admin settings like billing and SSO.

When you create an object role, you set an access level for each object type and choose how the role applies:

• Universal access—The role applies to all current and future objects of that type across the organization.
• Individual access—Access is scoped to specific objects or folders, which you define when assigning the role to a group.

Object roles are assigned to groups from the Groups page. Once assigned, all members of the group inherit the role's permissions. You can view a group's or user's full object-level access from the Object permissions tab on their detail page in Settings.

Updates to organization roles​

As part of this launch, organization roles have been updated to cleanly separate admin settings access from object-level access. The Create Role button on the Roles & Permissions page is now a dropdown where you choose between creating an object role or an organization role. A filter control on the roles list lets you view all roles, object roles only, or organization roles only.

To get started:

• Object roles—Understand how object roles work, including universal vs. individual access and folder inheritance.
• Create an object role—Step-by-step instructions for creating and managing object roles.
• Organization roles—Updated UI for managing organization roles, including a new role type selector and filter controls on the Roles & Permissions page.
• Assign roles to groups—Assign object or organization roles to groups.

Claude Sonnet 5 is now available on paid plans through Anthropic and Amazon Bedrock. It can be used with AI resource queries and Retool Agents.