Next.js vs React + Hono + Private Supabase: Picking a Stack AI Can't Wreck
Vibe-coded apps leaked 1.5M API keys this year, and most of it traces to one question: where do the secrets live? Why AI-assisted builders are choosing an explicit three-piece stack over the blended framework.
If you're building with AI (Cursor, Claude Code, Lovable, v0, whatever your agent of
choice), the most consequential decision you'll make isn't the prompt. It's the stack,
because the stack decides what your agent can get catastrophically wrong.
And 2026 has receipts on "catastrophically wrong." One high-profile breach this year
exposed 1.5 million API keys and 35,000 user emails
because AI-generated code shipped a database key into client-side JavaScript with
row-level security disabled. A scan of 20,000+ indie launches found
11% exposing database credentials in their frontend,
and security researchers keep finding the same pattern
across AI-built apps regardless of which tool built them. None of these are exotic
attacks. They're one question, answered wrong, at scale: where do the secrets
live?
Why agents struggle with the blended shape
Next.js App Router is a genuinely impressive piece of engineering, and this isn't a
hit piece. If you have a content-heavy site that lives on server rendering, or a team
that wants one framework's rails and deploys where it's happiest, it remains a strong
choice. Even Vercel describes the App Router as
"easy, but not simple",
and that distinction is exactly where AI-assisted building goes wrong.
Here's the App Router's core idea in plain terms: code that runs on your server
(where secrets are safe) and code that ships to every visitor's browser (where nothing
is secret) live interleaved in the same folder tree. What separates them isn't a
wall: it's naming conventions and annotations. A special comment at the top of a
file. A prefix on an environment variable's name that silently decides whether it's
public. The App Router was designed for a reader with trained instinct: the experienced
Next.js developer who applies these conventions without thinking, an audience it
serves brilliantly. An AI agent is a different kind of reader: it applies conventions
mostly correctly, at very high speed. And "mostly," at speed, is exactly how a
database credential ends up shipped to every browser on earth. The difference isn't
quality. It's fit: one architecture is optimized for human expertise, and the question
is what your primary author actually is.
There's a second difference for anyone who cares about owning their infrastructure:
Next.js is at its very best on the platform built for it:
its richest features are first-class on Vercel,
which is a genuine strength if that's where you want to live, and a consideration if
you'd rather run on servers you control.
The legible alternative
The stack this site runs on (and the one we generate for every Vibecarbon app) is
deliberately boring. Three separate pieces: a React app that runs entirely in the
browser (built with Vite), a small API server (Hono) that holds every secret, and
private Supabase, a Postgres database you host yourself. They talk to each other
over the network, and that's the whole trick: the boundary between public and private
isn't an annotation someone can forget. It's physically two different programs.
Both shapes can be secured. Only one makes the safe thing the default thing.
- The browser bundle is public by definition. Everything under the client
directory ships to users; there is no directive to forget, because there's no
server code in the tree at all. An agent physically cannot put a database
credential "on the wrong side" of a boundary that is the network itself.
- Secrets live in one process. The Hono server owns every private key, and it's
a small, explicit codebase an agent (or you) can read end to end.
- The database defends itself. Row-level security (RLS, the database itself
refusing to show one customer another customer's rows) is the real story behind
every breach above. Supabase's public key is designed to be public; it's only
dangerous when RLS is off. With RLS enforced as a rule rather than a hope, the
public key is harmless by construction. The React team itself points app builders to Vite
these days; the "you need a framework" era is over for app-shaped products.
- It self-hosts like it's normal, because it is. Docker containers, plain
Postgres, a plain HTTP server. No platform-shaped features to re-implement.
And the classic objection, that single-page apps (sites that render entirely in the
browser, like this stack's React piece) are invisible to Google and now to AI search,
is an engineering problem with a known solution, not a reason to adopt a framework:
this site ships build-time markdown mirrors, llms.txt, and server-injected metadata
precisely so crawlers read full content while the SPA stays a SPA.
This is what we mean when we talk about developer experience for AI-assisted
building. It isn't autocomplete speed. It's how the architecture feels under an
agent: fewer ways to be subtly wrong, boundaries a machine can't misread, and a
codebase where you (the person who understands the principles, if not every line)
can actually tell what's public and what's private by looking at the folder names.
The part no stack fixes
Honesty section: the legible shape removes a class of accidents, it doesn't make your
app secure. RLS still has to be written and enforced. Inputs still need validation.
Deploys still need to not expose Studio to the internet. If you're vibe-coding on any
stack, the missing piece isn't intelligence. It's mandatory guardrails: rules your
agent must follow and checks that fail loudly when it doesn't.
That's the actual design center of Vibecarbon:
vibecarbon create generates this exact stack with auth, billing, teams, email, docs,
and i18n wired, and it's architected for software built by agents. The generated
project ships an agent team with security rules the agents are required to follow (RLS
on every table, auth checks, input validation), a secret scanner that blocks
credentials from being committed, and confirmation gates on destructive operations.
The CLI then deploys and operates the whole thing (Docker Compose or Kubernetes on
the provider of your choice, automated backups, multi-region failover) so "private
Supabase" is a default, not a weekend project
(here's what that involves if you'd rather do it by hand).
The honest chooser
| Your situation |
Pick |
| Content-heavy site where server rendering earns its keep |
Next.js (or Astro) |
| Team already fluent in App Router, happy on the hosted platform |
Next.js |
| App-shaped product (dashboard, SaaS, tool) built with AI assistance |
React + Hono + private Supabase |
| You want the agent-safety guardrails included, not homemade |
Vibecarbon |
| You'd rather assemble the three pieces yourself |
Great. This post is your map |
On licensing, as always: the Vibecarbon CLI is Fair Source (FSL-1.1-MIT), not open
source; each release becomes MIT two years after publication, and the generated app
code is MIT from day one: yours outright.
Whatever you pick: turn on RLS, keep secrets out of the client, and scan what your
agent commits. The stack can make those defaults easy or hard. That's the whole
argument.