Bolt.new Guide: Build Full-Stack Apps in Your Browser

Who this is for: founders, freelancers, and product people who want a working full-stack app - frontend, backend, and database - without setting up a local dev environment first. If you already run Node and a terminal daily, other tools will fit you better; keep reading if the setup step itself is what's stopping you from shipping.

Bolt.new is StackBlitz's browser-based AI app builder: you type a prompt, it writes a full project (React/Vite by default, but it can scaffold Next.js, Astro, Vue, or a plain Node backend), and the whole thing runs live in a WebContainer - a Node.js environment compiled to WebAssembly that executes inside the browser tab, no server round-trip. That's the part people miss: there's no remote sandbox spinning up somewhere. Your npm install, your dev server, your terminal - all of it runs locally in V8, which is why a fresh Vite app boots in under two seconds.

What Bolt.new Actually Does Differently

Most AI coding tools (Cursor, Windsurf, GitHub Copilot) attach to a project already on your machine. Bolt.new skips that step entirely. You get:

• A file tree, code editor, and terminal in one browser tab, backed by StackBlitz's WebContainer runtime
• An AI agent that can run shell commands, install packages, edit multiple files, and see build errors - then fix them, in the same loop
• One-click deploy to Netlify (native integration) or export to GitHub
• A Supabase integration for a real Postgres database with auth, added from inside the chat panel

The practical effect: for a landing page, an internal tool, or an MVP with a handful of screens, you can go from blank prompt to a shareable URL in under 20 minutes without opening a terminal on your own machine.

The WebContainer Constraint You Need to Know

Because everything runs in-browser, Bolt.new cannot run native binaries. No Python backends, no sharp image processing that needs native bindings, no Docker. It's Node/JS only. If your app needs a Python ML pipeline or a native compiled dependency, Bolt.new is the wrong entry point - you'd prototype the frontend there and move the backend elsewhere.

Getting Started: Your First Build

1. Go to bolt.new and sign in (GitHub or email).
2. Write a specific first prompt. "Build me a SaaS" gets you generic scaffolding; "Build a waitlist landing page with a hero, three pricing tiers at $9/$29/$99, an email capture form that posts to a Supabase table called waitlist_signups, and a dark theme" gets you something close to done.
3. Watch the terminal panel while it installs dependencies and starts the dev server - the preview pane updates automatically.
4. Use the chat to iterate: "make the pricing cards equal height" or "add a loading spinner on submit" works better than re-describing the whole app.

Tip: Front-load constraints. If you need Tailwind, TypeScript, or a specific component library, say so in the first prompt. Retrofitting a design system after Bolt.new has already committed to plain CSS costs more tokens and more of your time than specifying it up front.

Adding a Real Database with Supabase

Bolt.new's Supabase integration (button top-right of the chat panel) is the single biggest reason to pick it over a pure frontend generator like v0. Once connected:

• It creates tables via SQL migrations that live in your project (supabase/migrations/), so schema changes are versioned, not clicked together in a dashboard
• Row Level Security policies get generated alongside the tables when you ask for auth-gated data
• Supabase Auth (email/password, magic link, OAuth) wires into the frontend with working session state

A realistic migration Bolt.new produces for a leads table:

create table if not exists public.leads (
  id uuid primary key default gen_random_uuid(),
  name text not null,
  email text not null,
  phone text,
  source text default 'website',
  created_at timestamptz default now()
);

alter table public.leads enable row level security;

create policy "Allow public insert"
  on public.leads for insert
  to anon
  with check (true);

Warning: Bolt.new will happily generate an "Allow public insert" policy like the one above and move on. That's fine for a lead form, dangerous for anything with select or update open to anon. Always read the generated policies before you deploy - this is the single most common security gap in vibe-coded Supabase apps.

Deploying: Netlify in One Click, Or Export Out

The built-in Netlify deploy button pushes a production build straight from the browser - no CLI, no repo required to get a live URL. For anything beyond a demo, though, connect a GitHub repo first (also one click) so you get real version history and can move the project into a proper CI pipeline later. If your target host is Vercel or Firebase instead, export via the GitHub sync and deploy from there - see Vercel vs Firebase Hosting for which fits your stack.

Where Bolt.new Breaks Down

Every builder in this category has a ceiling. Bolt.new's shows up around:

• Complex state management. Once an app has more than 5-6 interdependent screens with shared state, the agent starts making changes that fix one screen and quietly break another. You end up doing manual review of every diff, which erodes the speed advantage.
• Long-running agent sessions. Token usage climbs fast in multi-turn sessions because Bolt.new resends large chunks of file context each turn. A day of heavy iteration on a mid-size app can burn through a paid plan's monthly token allowance in under a week.
• Custom backend logic beyond CRUD. Webhooks, background jobs, queues, or anything needing a long-running process don't fit the WebContainer model. You'll want a real backend (Node on Railway/Render, or Firebase Functions) for that layer.
• Design precision. Bolt.new is fast at "a working thing" but resists pixel-perfect matching to a Figma file. If you have exact mockups, pair it with Figma to Code in 2026 or hand the final polish to a human.

Cost: What You're Actually Paying For

Bolt.new bills on tokens, not seats. As of mid-2026:

Token burn scales with project size, not just prompt count - editing a 40-file app costs more per turn than a 5-file one, because the agent re-reads more context to make a safe change. If you're building one focused MVP, Pro at $20 covers it comfortably. If you're iterating daily on a growing app, budget for Pro 50 - teams underestimate this line item constantly.

Bolt.new vs the Rest of the Field

If you're deciding between these for a specific project, Vibe Coding Tools 2026: The Full Shootout compares them head to head on real builds, and Lovable: Full App Build Walkthrough is the closest direct alternative if Supabase-first product apps are your target rather than general full-stack scaffolding.

When to Use Bolt.new vs When Not To

Use it for:

• Landing pages and waitlists that need a real form-to-database pipeline
• Internal admin tools with basic CRUD
• Rapid prototypes to validate an idea before hiring a developer
• Teaching yourself full-stack concepts without local environment friction

Skip it for:

• Anything requiring native dependencies or a non-Node backend
• Apps with more than roughly a dozen interacting views
• Projects where a specific design system must be matched exactly from day one

For a broader framework on making that call across all AI builders, not just this one, see Vibe Coding: When to Use It (and When Not To). And once a prototype needs to become a real, maintained product, run it through Vibe Code to Production: The Checklist before you put a client's name on it.

FAQ

Is Bolt.new free to use?

Yes, with a daily token allowance (roughly 1M tokens/day as of mid-2026) that resets each day. It's enough to build and test a small app, but you'll hit the ceiling fast on anything with a database and multiple screens - most people upgrade to the $20/month Pro plan within their first serious project.

Can Bolt.new connect to a real database?

Yes, through its native Supabase integration, which gives you Postgres, Row Level Security, and Supabase Auth, all generated as versioned SQL migrations inside your project. It's the main differentiator versus frontend-only generators.

Does Bolt.new export clean code I can keep using?

Yes. Every project is a real file tree - Vite/React or your chosen stack - that syncs to GitHub with one click. There's no proprietary lock-in format; you own the source and can hand it to any developer or move it to Cursor, VS Code, or another IDE afterward.

What's the difference between Bolt.new and Replit Agent?

Bolt.new runs entirely client-side in a WebContainer inside your browser tab, which makes it near-instant to start but limited to Node-compatible stacks. Replit Agent runs on an actual cloud VM, so it supports Python, native binaries, and persistent hosting, at the cost of a slower cold start and a slightly heavier interface.

Why did my Bolt.new app break after I asked for one small change?

Large multi-file edits from an AI agent can introduce regressions in unrelated screens, especially past 5-6 interdependent views, because the agent doesn't always have full visibility into every consumer of a shared component or state value. Ask for the smallest possible change, review the diff before accepting, and keep a GitHub sync running so you can roll back.

Is Bolt.new secure enough for a production app with real user data?

Not by default - review every Row Level Security policy it generates before launch, since it will sometimes leave select or update open to anonymous users on a table it just created. Treat generated policies as a first draft, not a final answer, and read Vibe Coding Security Risks before you put customer data anywhere near a vibe-coded backend.

Ready to Move Past the Prototype?

If Bolt.new got you a working MVP but you need it hardened, redesigned, or connected to a real backend before customers see it, that's exactly the kind of handoff we do. Book a free 30-minute call through the contact form or message us directly on wa.me/972585802298.

Sources

• bolt.new
• StackBlitz WebContainers documentation
• Supabase documentation
• Netlify documentation