Custom code, finally governed: building on the new Retool

For years, internal tooling forced a bad choice. Stay inside a preset component library and keep your security boundaries intact, or write custom code and lose the audit trail that keeps production compliant. Most teams picked the constraint, because the alternative didn't survive a security review.

The new Retool removes the choice. Native React and custom logic now run inside the same permission and logging architecture that already governs everything else on the platform. You build what operations actually needs, and the compliance layer stays enforced the whole time.

The real blocker was never the code

Writing a powerful workflow was never the hard part. Shipping it was.

To get custom scripts or AI agents into a regulated environment, you had to break the model that kept it compliant. That meant handing over broad database access, or routing around the audit trail. So security flagged the same risk every time: an unmonitored process touching too many systems. The request stalled. Teams either accepted slower, narrower tools or built outside the governed environment and inherited the maintenance debt.

And it was never one checkpoint. A new tool clears procurement, security, and DevOps. That's three separate gates, three timelines, three risk thresholds. Retool is already through all three in most enterprises that run it. That's what makes it the right place to land custom code and agents: no new procurement cycle, no fresh security review. It extends access you've already granted.

Build anywhere. Ship in Retool.

Apps in the new Retool are written in React on the frontend and TypeScript on the backend. The permission boundaries, role controls, and audit logging wrap around your custom code exactly as they wrap around standard components.

That means you can build where you already work, whether that's Claude Code, Codex, Replit, Lovable, v0, or a local repo, and ship the result into Retool as a governed runtime. On import, Retool maps the app's data connections to resources your team has already configured and secured. No rewrite. The constraints that used to block complex interfaces or heavy data transformation are gone. The compliance boundary stays.

One governed layer, underneath everything

Governance can't be something each app implements on its own. It has to be a single layer that sits below all of them.

That's how Retool built it. Data access, permissions, approved resources, and deployment rules live underneath the application layer, not inside the code, so they apply the same way no matter how or where an app was built. The security doesn't live in the AI-generated layer. It lives under it. And it's identical across Retool Cloud, VPC, and on-prem.

Why this matters more as agents arrive

An agentic workflow only scales inside a regulated company if you can say exactly how many data sources it reads, which endpoints it calls, and where its outputs land. Without that, security blocks deployment, and correctly so.

The governance layer is that boundary. Every automated action is scoped, logged, and auditable before it touches live operational data. The resources, permissions, and approved pathways you define become the harness that makes more autonomous software safe to run. You get the speed of automated reasoning without handing your security team a problem they can't see.

What does the new Retool mean for your existing apps?

You can extend what you already run, including custom code and agent-driven workflows, without a full rebuild or a renegotiated security posture. It's an architectural expansion, not a replacement. Refactor specific components into custom code, leave the rest intact, and the governance rules you already configured apply automatically to the new code.

If you've been waiting on a product team to prioritize internal tooling, or watched a first build calcify, this is the moment to extend what you have. The platform now moves at the pace of operations instead of capping it.

Before you migrate: five things to check

You can move incrementally, but a little prep determines how clean it goes.

Start with your permission model. Retool maps an imported app's data connections to resources you've already secured. If your resource configs and RBAC groups are well-documented, import is clean. If permissions have accumulated informally, think super-admin roles handed out as a shortcut, or access groups that no longer match real teams, migration will surface those gaps. Clean them up before you move, not after.

Confirm your environments carry forward. The governance layer is identical across Cloud, VPC, and on-prem, but your production and staging separation is worth auditing before the move.

Pick the right first apps. Not everything needs to migrate. Find two or three apps where custom React or agent capability unlocks something your current build can't do. Move those first and let them inform the rest. Apps that work and aren't hitting a ceiling can wait.

Verify your audit requirements. Every interaction with your data sources logs through the governance layer. If you carry specific retention or export obligations, like a five-year trail for financial services or a particular format for compliance, confirm they're met before moving any workflow that carries those obligations.

Check your SSO. The new builder inherits centralized authentication. If you run Okta, Azure AD, or similar, confirm the integration is stable and documented before adding apps to the governed runtime.

Which Retool partners can build on the new app builder?

Building here takes an engineering team that understands enterprise architecture and compliance baselines, not just low-code configuration. The teams that navigate this well are the ones already contributing to the platform's technical ecosystem, with direct lines to its engineers, who've spent years building tools that survive security reviews.

We work directly with teams across Retool on multiple products, including some that haven't shipped yet. We built the custom-component effort that now lives in Retool's official library, then handed it over to Retool to own. And Retool named us among its enabled service partners in the launch announcement, a group given early access to the new app builder and hands-on enablement before public release. Our first enterprise engagements are already running on it.

If you want to see how this applies to your stack, talk to us and we'll walk through your current architecture. For a technical breakdown of how we structure deployments, read the architecture behind governed creative operations.

The new Retool app builder launched publicly on 17 June 2026. It's available now for Retool Cloud customers, and in the Retool 4.x stable release for self-hosted deployments.

Frequently asked questions

Does the new Retool replace the platform we already use?

No. It's an expansion, not a replacement. Native custom code and agent support sit on top of the Retool you already run. Your current apps and queries keep working exactly as they do today, and you bring in custom components or workflows on your own timeline.

Is the new Retool available now?

Yes. The new app builder launched on 17 June 2026. It's live now for Retool Cloud customers, and ships in the Retool 4.x stable release for self-hosted deployments.

Do we need to hire a new agency to build on the new Retool?

Not necessarily. But check that your current team has actually shipped governed custom code and worked inside enterprise permission models. This layer takes real engineering discipline, not low-code configuration. If your team hasn't done it, bring in one that has.

Does the new Retool change how Retool handles data residency and compliance?

No. The compliance and data residency frameworks stay exactly as they are. You get to write more complex code while the enterprise controls stay fully enforced.