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.

A new AI-powered app builder is now available. Build production-ready React apps using natural language in the app builder or through your favorite coding agent via MCP. Whatever or however you build, everything inherits the security standards your organization has already approved and implemented.

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.

Admins can use the configuration guide to set up their organization to use the new app builder.

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

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.

Support for multiple Secrets Manager configurations is now available in public beta. Once enabled, self-hosted organizations can create additional configurations and retrieve secrets data from multiple locations.

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

You can now unpublish workflow releases from the Releases tab.

This feature is also available for workflows protected with Source Control. When unpublishing a release on a protected workflow, the latest saved version on the main branch will be live to users.

Retool now supports hardened images, which are available on the self-hosted edge release channel. These images are designed to improve supply-chain security, reduce the attack surface, and support modern infrastructure while remaining functionally compatible with existing deployments. Learn more about hardened images in the conceptual guide.

Plan your migration​

Use the following high-level steps to evaluate and roll out hardened images.

1. Review requirements and environment​

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

2. Test hardened images in non-production​

Retool strongly recommends testing hardened images on non-production instances first, for example:

• A development or staging instance in a separate Virtual Private Cloud (VPC) or cluster.
• A temporary test environment built using the Docker 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 protect an agent with Source Control from the dropdown next to the agent name, or from the dropdown on the All agents page.

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

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

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

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