Your Bolt app is working.
Now make it production-ready.

First: what kind of Bolt project do you have?

Bolt.new can output two very different things — a Vite + React SPA, or a Next.js App Router project. The migration path differs significantly between them. Check before you start:

# Look at your project root:
vite.config.ts present, no next.config.*  → You have a Vite project
next.config.ts or next.config.js present  → You have a Next.js project

If you have a Vite project, there's a framework-level difference to bridge before anything else. If you have a Next.js project, you're on the same framework as Already — the migration is mostly mechanical.

If your Bolt project is Vite: convert env vars first

Vite uses import.meta.env.VITE_* to access env vars. Next.js uses process.env.NEXT_PUBLIC_*. You need to rename these throughout your codebase before copying code into Already:

# Search and replace in your Bolt project:
import.meta.env.VITE_SUPABASE_URL    → process.env.NEXT_PUBLIC_SUPABASE_URL
import.meta.env.VITE_SUPABASE_ANON_KEY → process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
import.meta.env.VITE_*               → process.env.NEXT_PUBLIC_*

Your .env key names change the same way: VITE_FOO → NEXT_PUBLIC_FOO.

The .bolt/ directory

Delete it. The .bolt/ directory contains Bolt's editor metadata and configuration — it's not application code. It has no function outside the Bolt.new environment.

Bolt auth varies — check which one you have

• Supabase Auth. Best case. Copy the project URL and anon key into Already's .env.local, point at the same Supabase project, and your users are untouched.
• Clerk. See the FAQ below. Requires a decision: keep Clerk for auth and wire Supabase separately, or migrate to Supabase Auth.
• No auth. Fresh setup. Already's quickstart has you running with Supabase Auth in ~20 minutes.

Cloning from StackBlitz

Bolt runs in StackBlitz's browser-based Node environment. When you export and clone the project locally, do not copy node_modules/. StackBlitz installs packages differently from a local environment — you'll get mismatched binaries.

# Always install fresh after cloning:
pnpm install

Why migrate from Bolt?

Bolt is outstanding at getting you to a working demo without setup friction. The moment you need to charge customers, isolate their data, or run the app reliably under load — you need a production foundation that Bolt doesn't ship.

Already is that foundation. It's the same shadcn/ui + Next.js stack Bolt uses, with auth, billing, multi-tenancy, background jobs, and 12 more production modules already wired in. Move your product logic in; leave the plumbing to Already.

What carries over without changes

• Your UI components. Bolt generates shadcn/ui components with Tailwind. Copy your components/ directory into Already's — zero redesign, zero re-theming.
• Your business logic. Server actions, API routes, and utility functions translate directly into Already's App Router structure.
• Your Supabase data. If your Bolt app uses Supabase, point Already at the same project. Your tables, RLS policies, and data stay exactly where they are.

What needs migration work

• Auth setup. If your Bolt app didn't use Supabase Auth, you'll set it up fresh in Already — about 20 minutes with the quickstart guide. Your UI stays untouched.
• Route remapping. Move pages into Already's group structure: authenticated product under app/(app)/, auth flows under app/(auth)/, public pages under app/(public)/. Bolt tends to use flat app/ routes.
• Data layer. Add Drizzle schema declarations for your existing tables so Already's query helpers can use them with full type safety.
• Env vars (Vite only). Replace all import.meta.env.VITE_* with process.env.NEXT_PUBLIC_*.

Step-by-step migration

Bolt: app/dashboard/page.tsx  → Already: app/(app)/dashboard/page.tsx
Bolt: app/login/page.tsx     → Already: app/(auth)/login/page.tsx
Bolt: app/page.tsx           → Already: app/(public)/page.tsx

already migrate bolt --source ../my-bolt-app

Frequently asked

My Bolt project uses Clerk for auth, not Supabase. What do I do?

Already is built entirely around Supabase Auth — the middleware, RLS policies, and multi-tenant model all assume it. You can technically keep Clerk for the auth layer and wire the user identity into Supabase manually for the DB layer, but in practice most teams find it cleaner to migrate to Supabase Auth. Clerk's user export tool (under Dashboard → Users → Export) gives you a CSV you can import into Supabase. Passwords don't transfer (Clerk uses their own hashing), so users will need to reset via email — a one-time friction most teams send a simple email about.

My Bolt app doesn't use Supabase. Is that a problem?

Already is built on Supabase Auth throughout. If you're coming from a different auth setup, you'll set up a new Supabase project and migrate users. The quickstart covers this. For apps with a small user base it's a one-evening job.

Will my Tailwind styles transfer cleanly?

Yes. Bolt and Already both use Tailwind CSS v4. Your utility classes and component styles transfer without modification.

What if my Bolt app uses a different database?

Already's Drizzle ORM layer connects to Supabase's Postgres. If your Bolt app uses a different database, you'll need to migrate the data to Supabase. The Drizzle schema files make this straightforward — declare your schema, run migrations, import your data.