Is bolt.new production hosting?

Not really. bolt.new (StackBlitz) is a development environment with WebContainer-based runtime in the browser. For production, you connect bolt to Netlify, Vercel, Cloudflare Pages, or Supabase, and bolt deploys your code there. The bolt.new URL is for development and sharing previews. So the migration target is 'bolt for dev + Vercel or Netlify for prod' rather than bolt as a hosting platform.

What's the difference between bolt.new and Lovable or Replit?

All three are AI-native development platforms. bolt.new uses WebContainers, so the entire Node.js runtime runs in your browser. That makes prototyping incredibly fast but limits production deployment. Lovable focuses on full-stack apps with managed Supabase backends. Replit gives you a real Linux container with shell access. For migrating a base44 app, Replit and Lovable are usually closer matches; bolt is the best fit if you want fast iteration before deploying to Vercel or Netlify.

Will bolt.new's AI rebuild my base44 app from a description?

Partially. Paste your base44 export into bolt and the agent can analyze the codebase and propose changes. It is better at scaffolding new features than at restoring an existing complex app. Most teams use bolt to rebuild from scratch with a feature-by-feature approach, prompting the agent to recreate each screen rather than ingesting the export wholesale. Plan for an iterative rebuild, not a one-shot port.

Does bolt.new support backend functions and databases?

WebContainers run Node.js so you can build full-stack apps. For data, bolt integrates with Supabase out of the box. For backend functions, you build them as Node.js routes in your app and deploy to Vercel/Netlify, where they become serverless functions. The bolt environment itself does not host long-running backend services.

What does bolt cost compared to base44?

bolt has a free tier with token-based limits. Pro is $20/mo for individuals, Teams $50/user/mo. Production hosting on Vercel or Netlify adds $0–$20/user/mo. Supabase backend $0–$25/mo at small scale. Total comparable cost: $20–$80/mo, often cheaper than base44's mid-tier plans. Token consumption on bolt is more transparent than base44 credits, which helps with budgeting.

Should I migrate to bolt or just to Vercel directly?

If you want AI-assisted development for the rebuild itself, bolt accelerates that phase by weeks. If you have an experienced engineering team that prefers writing code by hand, going directly to Vercel + Supabase skips bolt entirely. Bolt is a means, not the end; the production stack is whatever you deploy to.

Can I use bolt.new offline or self-hosted?

No. bolt.new requires StackBlitz's hosted infrastructure. The WebContainer technology is proprietary. If self-hosting matters, this is the wrong destination — see our self-hosted migration playbook.

Migrate Base44 to bolt.new: WebContainers, StackBlitz, and the AI-Native Stack

bolt.new is more an accelerator than a destination. Most teams who migrate from base44 to bolt are really migrating to "bolt for development plus Vercel or Netlify for production." This playbook covers both halves.

If you want a single platform that hosts your production app long-term, bolt is the wrong target. Lovable and Replit are closer matches for that. Read this one if you want the fastest possible rebuild loop and you are happy deploying to a separate production host.

Why migrate to bolt.new

Three reasons we see teams pick bolt:

Speed of rebuild. bolt's AI agent + WebContainer runtime gets you to a running prototype faster than any other tool. For a base44 app you already know inside-out, bolt can scaffold the new version in days, not weeks.
Full Node.js compatibility. Unlike base44's sandboxed Deno runtime, bolt runs real Node in WebContainers. Any npm package works. Any Node API works. Many bugs you fight on base44 are simply non-issues on bolt.
Direct integration with Vercel, Netlify, and Supabase. bolt deploys to real production hosts with one click. The handoff from "AI development" to "production deployment" is automatic.

The trade: bolt itself is not your production host. You are committing to a two-platform model.

What you keep, what you rebuild

Layer	What you keep	What you rebuild
React components	80–95%	SDK calls (`@base44/sdk`)
Routing	URL structure	If switching frameworks
Schema	Field names + types	DDL on Supabase or chosen backend
Database rows	Data	None
Authentication	User identifiers	Supabase Auth, Clerk, or Auth.js
Backend functions	Function bodies	Wrap as Vite/Next API routes
File uploads	Files	Re-upload to chosen storage
Webhooks	Endpoint URLs	New URLs at production host
Scheduled jobs	None	Build at deployment target
AI agent	None	Trade base44 agent for bolt agent

The shape of the rebuild is the same as the Vercel migration; bolt just accelerates the development phase.

Architecture: source vs target

Base44 (current):

[browser] → CSR React (base44 hosted)
              ↓
        @base44/sdk
              ↓
       base44 backend (managed)

bolt.new + Vercel + Supabase (target):

DEVELOPMENT:
[bolt.new in browser] → WebContainer (Node.js in tab)
                          ↓
                    your code, full hot-reload
                          ↓
                    (push to git, deploy via bolt)

PRODUCTION:
[user browser] → Vercel (Next.js SSR/Edge)
                   ↓
              Supabase (Postgres + Auth + Storage)

You develop inside bolt. You deploy to a real production stack. The two are connected by Git and bolt's deploy integration.

Step-by-step migration plan

Phase 1 — Discovery (Week 1)

1. Inventory base44 surface area

Standard inventory: entities, functions, integrations, webhooks, scheduled tasks. Grep your SDK calls.

2. Pick your production target

bolt deploys to Netlify, Vercel, Cloudflare Pages, or Supabase Hosting. Pick before starting:

Target	Best for	Note
Vercel	Next.js apps, full SSR	Strong AI-platform ecosystem
Netlify	Static-heavy sites, Jamstack	Good built-in forms, identity
Cloudflare Pages	Edge-first, global low-latency	Workers integration
Supabase Hosting	Tightly-coupled with Supabase backend	Newer, simpler

We default to Vercel + Supabase for most migrations. See the Vercel migration playbook for the deeper dive on that target.

Phase 2 — bolt setup (Week 1)

3. Open bolt.new and start a new project

Visit bolt.new. Sign in. Create a new project.

bolt prompts you for an initial description. Paste a high-level summary of your base44 app:

I'm migrating an app from base44. It's a project management tool for
small teams. Tables: users, projects, tasks, comments. Auth via email
+ magic link. Stripe for billing. Slack webhook for notifications.
Use Next.js 15, Supabase for backend, deploy to Vercel.

bolt scaffolds a starting structure: Next.js project, Supabase client, basic auth flow.

4. Provision Supabase

bolt's integration creates a Supabase project for you on first prompt. The connection details land in the project's .env:

NEXT_PUBLIC_SUPABASE_URL=https://xxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=...
SUPABASE_SERVICE_ROLE_KEY=...

Phase 3 — Rebuild iteratively (Weeks 1–3)

5. Drop in your base44 components

Upload your src/components/ from the base44 export. bolt's editor handles the file tree. The agent can analyze the components and suggest the data-layer rewrites.

6. Prompt the agent feature-by-feature

Do not ask the agent to "rebuild the whole app." That hits the same regression-loop class of problems base44 has. Ask for one feature at a time:

Add a /projects route. Server component. Fetches projects from
Supabase where owner_id = auth.uid(). Lists them in a table.
Use the existing ProjectList component from src/components/.

Verify it works. Snapshot. Move to the next feature.

7. Recreate the schema in Supabase

Same shape as the Supabase migration. Use the Supabase SQL editor or write migration files.

-- supabase/migrations/0001_init.sql
create table public.projects (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null references auth.users(id) on delete cascade,
  name text not null,
  status text not null default 'draft',
  created_at timestamptz not null default now()
);

alter table public.projects enable row level security;

create policy "owner_can_select" on public.projects
  for select using (auth.uid() = owner_id);

bolt's agent can write these migrations from a description. Verify before applying.

8. Replace SDK calls

Mechanical work, same as every migration:

// before
const projects = await base44.entities.Project.find({ filter: { ownerId } });

// after (Server Component)
const supabase = createClient();
const { data: projects } = await supabase
  .from("projects")
  .select("*")
  .eq("owner_id", ownerId);

bolt's agent will do the bulk of this if you point it at one component at a time.

Phase 4 — Backend functions (Week 3)

9. Port backend functions to API routes

Each base44 function becomes a Next.js Route Handler:

// app/api/create-invoice/route.ts
import { NextResponse } from "next/server";
import { createClient } from "@/lib/supabase/server";
import Stripe from "stripe";

export async function POST(req: Request) {
  const { project_id, amount } = await req.json();
  const supabase = createClient();
  const stripe = new Stripe(process.env.STRIPE_SECRET!);

  const invoice = await stripe.invoices.create({ customer: "...", auto_advance: true });
  await supabase.from("invoices").insert({ project_id, stripe_id: invoice.id, amount });

  return NextResponse.json({ id: invoice.id });
}

These deploy as Vercel serverless functions when you deploy.

Phase 5 — Data backfill (Week 3–4)

10. Export from base44, import to Supabase

Standard backfill script via @supabase/supabase-js. Run from bolt's terminal or locally — both work because the WebContainer has Node.js.

// scripts/import.ts
import { createClient } from "@supabase/supabase-js";
import projects from "./export/projects.json";

const sb = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE!);

for (const batch of chunk(projects, 500)) {
  const { error } = await sb.from("projects").insert(batch.map(toRow));
  if (error) throw error;
}

Phase 6 — Deploy to production (Week 4)

11. Connect Vercel

In bolt, click Deploy. Connect your Vercel account. bolt creates a Git repo, pushes the code, and triggers the first Vercel build.

# bolt + Vercel handles all of this for you
git init
git remote add origin git@github.com:yourorg/your-app.git
git push -u origin main
# Vercel picks up the push and deploys

You now have a real production URL with SSL, edge functions, preview deploys per branch, and proper logs. Add your custom domain.

12. Configure Vercel Cron

Same pattern as the Vercel migration. vercel.json with crons entries.

Phase 7 — Cutover (Week 4–5)

13. Dual-run + DNS swap

Standard cutover playbook. Dual-write for one to two weeks. Validate parity. Swap DNS at low-traffic hour.

Phase 8 — Sunset

14. Decommission base44

Cancel after thirty days of stable Vercel + Supabase production. Keep base44 export for ninety days.

Common pitfalls

1. Treating bolt as the production host. It is not. Always deploy to Vercel, Netlify, or another real host before going live.

2. Letting the agent rebuild everything in one prompt. Same regression-loop class of problem as base44. Build feature-by-feature. Snapshot between turns.

3. Token budget overruns. bolt is more transparent about tokens than base44 is about credits, but heavy use still adds up. Watch your token consumption per session.

4. WebContainer limitations. Some packages with native bindings (sharp, canvas, certain database drivers with node-gyp) do not work in WebContainers. Test in bolt before relying on them; fall back to deploying directly to Vercel without bolt for those builds.

5. Bolt's agent is good but not your senior engineer. It will write code that compiles and looks right. It will not always pick the secure pattern, the performant pattern, or the consistent pattern. Code-review every commit.

6. SEO transition. Same warning as every migration. Map old URLs to new ones; ship 301s on day one of cutover.

Timeline + team

Three to five weeks with this team:

One full-stack engineer. Drives the bolt rebuild and Vercel deploy. Forty hours per week.
One product owner. Validates parity and reviews agent output. Five to ten hours per week.

bolt's accelerator effect makes this one of the faster migrations on paper. The risk is that the agent ships features that look right but fail in subtle ways. Plan extra QA time, not less.

Cost

Migration tiers:

Tier	Price	What you get
Small	$6,000	3–4 weeks, simple app, Vercel + Supabase
Medium	$12,000	4–6 weeks, custom integrations, complex auth
Enterprise	$25,000+	Compliance, white-glove cutover, on-call support

Bolt: $20/mo (Pro) or $50/user/mo (Teams). Vercel Pro: $20/user/mo. Supabase: $0–$25/mo at small scale. Total ongoing: $40–$120/mo for most teams.

DIY vs hire decision

DIY this if:

You have shipped at least one Next.js + Supabase app before.
Your app has under twenty entities and standard auth.
You are comfortable working with AI agents and reviewing their output critically.

Hire help if:

Your app has paying users and you cannot risk an agent-written bug shipping to production.
You have not used bolt before and need a fast turnaround.
Your team is base44-only.

This is the migration that is most often DIY because bolt does so much of the mechanical work. Hire if speed and reliability are both required.

Want a free migration assessment?

Tell us about your app. We will scope it. Free thirty-minute call.

Book a free migration assessment

Base44 to Replit — closest peer in AI-native development with real container access.
Base44 to Lovable — alternative AI-native stack with managed backend.
Base44 to Vercel — the production target most bolt migrations end up on anyway.