Don't Ban the Builders - Govern Them

Key points:

• AI coding tools have turned non-technical employees - sales, finance, product, even CEOs - into builders who ship real applications with company data
• When this happens on Lovable, Bolt.new, or Replit, it's Shadow IT with database access. Every app is a compliance surface your security team can't see
• Banning AI builder tools kills innovation. The business value is too real
• The answer is a governed builder platform: same one-click experience, but on your infrastructure, under your control
• We built the RDE Portal with a split architecture where your code never leaves your cluster and your cluster is never exposed to the internet

Six months ago, not a single client asked me about this. Today, I hear it in every conversation.

I was with the CTO of a company backed by one of our investors ten days ago. Same story. I talked to a Head of Platform at a European fintech the week before. Same story. I had a call with a security-focused SaaS company. Same story. I brought it up at our last board meeting three weeks ago because the pattern was impossible to ignore.

Everyone in your company is a builder now. Not a coder - a builder. And your infrastructure is not ready for it.

Everyone Builds

Here is what's happening. AI coding tools - Lovable, Bolt.new, Cursor, Replit - have collapsed the barrier between "having an idea" and "shipping a working application." A product manager opens Lovable, describes a client-facing dashboard, and has a running app in twenty minutes. A finance analyst builds a retention analysis tool connected to the company database. A sales ops lead builds a pipeline tracker plugged into the CRM.

None of these people filed a ticket with engineering. None of them asked IT for permission.

I've talked to over 200 CTOs in the last few years. The conversations in the last three months have been different from anything I've heard before. One Head of Platform at a European fintech told me:

This isn't an isolated case. The same person told me they'd already changed their roadmap:

And they're not in the awareness phase anymore. They're in execution:

The cards are being redistributed. The role of the platform team has fundamentally changed. You're no longer just setting up databases for developers. You're building the blocks that let the entire company build.

Shadow IT on Steroids

Here's the problem. When business teams use external AI builder platforms with company data and zero governance, every application they ship is a compliance surface your security team can't see.

I wrote about Shadow IT and vibe coding last week. That article focused on AI coding agents with OAuth access to your repos and cloud accounts. This is the next layer of the same problem - but with non-technical builders, the blast radius is even harder to control because they don't know what they don't know.

Here is what your CISO sees when someone in sales builds an internal tool on Lovable or Bolt.new:

• Your code and data live on shared multi-tenant infrastructure you don't control. No VPC peering. No private networking. No way to reach internal APIs securely.
• API keys and database credentials sit on the vendor's servers. If the vendor gets breached, your credentials are in the blast zone.
• No meaningful audit trail. Who deployed what, when, with access to which data? Good luck answering that during a compliance audit.
• No environment separation. That "quick internal tool" might be connected to your production database. There's nothing stopping it.

One Head of Platform described it to me bluntly:

And that's exactly the tension. You have two types of companies right now. Companies that embrace the wave - where the platform team reorganizes to support builders across the entire org. And companies where IT puts on the brakes, creating friction and driving builders further underground into tools they control even less.

Banning AI builder tools doesn't work. The business value is too real. Kill the tools, kill the innovation. The backlog of "build me this small thing" requests goes back to engineering, where it sits for weeks. Business teams get frustrated. The competitive advantage disappears.

The Permanent Tension

There's a tension that I see in every conversation with CTOs and Heads of Platform. It comes down to three words: speed, ease, security.

That quote is from the same Head of Platform I mentioned earlier. And he's right. But here's the thing most people get wrong - they treat this as a tradeoff. Move fast or be secure. Pick one.

It's not a tradeoff. It's an architecture problem.

A business is built on trust. You can privilege velocity at all costs, but the risk is compromising that trust - and once trust is gone, it's gone. The companies that win will be the ones that figure out how to give builders maximum velocity without ever compromising security. Not through policy documents that nobody reads. Not through approval workflows that take three weeks. Through architecture.

What We Built: The RDE Portal

At Qovery, we've been working on this for months. We started because our existing clients kept asking for it - so many that we flagged it at our board meeting as a potential inflection point. We didn't anticipate it six months ago. But when the pull is this strong, you don't ignore it. You build.

The Remote Dev Environments Portal is a self-service web application where platform engineers define blueprint environments, and builders - engineers and non-technical team members alike - create their own isolated cloud workspaces with one click.

Here is what it does:

• One-click workspaces from blueprints. Platform engineers create blueprint environments tailored to each team. Finance gets a blueprint with access to the analytics database. Sales gets one with CRM credentials. Marketing gets the content API. Builders pick a blueprint, click Create, and they're working.
• Built-in AI tools. Every workspace includes a terminal with Claude Code and an OpenCode chat panel. Pre-configured, ready to use. No setup.
• Live preview. Builders see their running application directly in the browser. Desktop, tablet, mobile viewports. No deployment step needed during development.
• Publish workflows with approval gates. When a builder wants to go to production, they submit a request with a subdomain. Admins review and approve before anything goes live. Trusted users can bypass this - but trust is granted per-user and revocable.
• Blueprint access control. Restrict which blueprints are available to which users - by email, by domain, or open. Users only see what they're authorized to use.
• Full audit trail. Every workspace operation - create, start, stop, delete, publish - is logged. Who did what, when, on which blueprint.

One thing I keep coming back to in conversations with our clients: my finance lead doesn't know what an API is. She built her own retention analysis tool last week. That's the bar. If someone who has never written a line of code can build and deploy a useful internal tool in a controlled environment - you've won.

And for the platform team, here's what matters: you see everything. Every workspace across the org. Per-user environments, permissions, cost controls. No shadow IT - because the official path is faster and easier than the workaround.

Secure by Architecture, Not by Policy

This is the part I care about the most. Because anyone can slap an SSO page on a hosted IDE and call it "enterprise-ready." The real question is: where does the code live, where does the data flow, and what's exposed to the internet?

We built the RDE Portal around three security principles. Not as features we added later - as the foundational architecture decisions.

Your code stays on your infrastructure

The portal uses a split architecture. The portal itself - the UI and API - is hosted by Qovery at rde.qovery.com. But workspace containers run entirely on your Kubernetes cluster. Source code, AI conversations, terminal history, application data - none of it ever leaves your infrastructure.

The portal's database stores configuration metadata only: access control rules, theme settings, publish workflow state. Zero source code. Zero user data. Zero AI conversations.

Your cluster is never exposed

This is the most important security property. Your Kubernetes cluster runs Qovery agents that maintain persistent outbound TLS/gRPC connections to the Qovery control plane. Your cluster never exposes inbound ports to the internet. It is never directly addressable from outside your network.

All portal operations - terminal sessions, live previews, deployments - flow through this cluster-initiated tunnel. The control plane can only communicate with your cluster through a tunnel that your agents initiated. If the agents stop, the tunnel closes. The control plane has no way to reach your infrastructure.

No inbound ports. No public endpoints. No direct access to your cluster. Period.

Everything is streamed, nothing is stored

Terminal sessions and application previews are streamed in real time from your containers through the cluster-initiated tunnel to the user's browser. The portal relays data in memory without persisting it. When a session ends, nothing is recorded on the portal side.

AI tools (Claude Code, OpenCode) run inside the workspace container on your cluster. The AI process communicates with the LLM provider directly from the container. The portal streams the terminal UI to the browser - it does not intercept or store AI conversations. If your org requires AI traffic to stay within your network, you can configure a custom LLM endpoint in the blueprint settings.

Additional security controls

• One-time shell tickets with 30-second TTL - prevents token leakage in connection URLs
• AES-256-GCM encryption for admin API tokens and LLM API keys at rest
• Workspace isolation via separate Qovery environments with per-project RBAC scoping
• Compliance inheritance - workspace containers inherit your cluster's posture. If your cluster is SOC 2, HIPAA, or GDPR compliant, your workspaces are too

For a detailed technical breakdown, see our Security & Data Residency and Architecture documentation.

The Wave Is Here

I'll end with something I said to a Head of Platform during one of these conversations. It stuck with me because it captures what this moment feels like from the inside:

In the life of a company, there are waves that drastically change your trajectory. You can't always anticipate them. But you have to be ready when they come - you have to recognize the swell forming, and you have to take the wave.

This is one of those waves. Six months ago, I wouldn't have bet on it. Now I see it in every conversation, at every company, in every industry. Non-technical people are building. The companies that provide them a governed platform will capture the innovation. The companies that ban the tools will watch their best people build in the shadows anyway.

Don't ban the builders. Govern them.

Try Qovery free - or book a demo to see the RDE Portal in action.