Lovable to Next.js: do you still need to convert, and how to do it
Lovable does not build Next.js apps and you cannot pick it as a framework. So a Lovable to Next.js conversion is something you do yourself, with Claude Code, Codex or Cursor doing most of the typing. Before you start, check why you want it. Most people want Next.js because Google could not read their app. For new Lovable apps that reason is gone.
Lovable cannot build Next.js
Every Lovable project uses the same stack: TanStack Start for apps made since 13 May 2026 (22 June 2026 on Enterprise), React with Vite for older ones. There is no choice of framework. If you need a different stack, Lovable says to keep a repository in sync with Git sync and continue the work outside Lovable.
So converting to Next.js is also a decision to leave the Lovable editor for this project. You cannot convert and then keep prompting Lovable.
Lovable itself went the other way. In August 2026 it moved lovable.dev, a Next.js app on Vercel with 42M+ monthly unique visitors and close to 400 routes, to TanStack Start hosted on Lovable. The post says Vercel "performed admirably". The main reason was to use their own product. It also says: "don't be surprised if we let you import Next.js apps in the not-so-distant future". Today you cannot.
Why people convert, and is it still true?
| Reason | Still true in October 2026? |
|---|---|
| Google and AI search cannot read the app | Not for new apps. TanStack Start renders pages on the server. Older Vite apps can upgrade to TanStack Start inside Lovable |
| Backend code has to live in separate edge functions | Not for new apps. TanStack Start has server functions next to the components that use them |
| I want to host on Vercel | You do not need Next.js for that. Vercel deploys Lovable TanStack Start apps with zero configuration |
| My team knows Next.js, not TanStack Start | Yes, a real reason |
| I want to merge this app into an existing Next.js product | Yes, a real reason |
| I need a Next.js feature (image optimization, Proxy, a specific library) | Yes, a real reason |
If your only reason was SEO, upgrade the project to TanStack Start inside Lovable instead. Most upgrades cost 10 to 35 credits (Lovable docs, checked 26 October 2026), the project keeps working in Lovable and you can undo it from version history. Lovable SEO after you move has the steps and shows how to check what crawlers see.
First, check which stack your app is on
The steps are different for each. Open package.json. If it lists @tanstack/react-start in its dependencies, it is TanStack Start. If not, it is the older React with Vite stack, which uses React Router. Is your Lovable app TanStack Start or Vite? has the details.
Before you start
- Back up the database. The conversion does not touch it, but you will change the code that talks to it. See Back up the database of a Lovable app.
- Connect the project to GitHub and clone the repository. See Export a Lovable project to GitHub.
- Create a new branch for the conversion. Lovable edits and syncs one branch at a time, usually main. Commits on other branches do not reach Lovable until you merge them. So do not merge the Next.js branch into the synced branch while you still use Lovable.
- Write down your environment variables and secrets. The .env file in the repository has the public VITE_ values. Secrets that server code reads are not in the repository.
- Move your Lovable Knowledge into a file your coding agent reads. See Take your Lovable Knowledge to CLAUDE.md or AGENTS.md.
Then open the repository in your coding agent. The Lovable to Claude Code, Lovable to Codex and Lovable to Cursor guides set each one up step by step.
Path A: an older Vite app to Next.js
Next.js has an official guide for this: How to migrate from Vite to Next.js. Give your agent the link and ask it to follow the guide step by step, one commit per step, without changing anything else.
The guide first gets the app running on Next.js as a single-page app, with React Router still in place. Only after that do you move pages to Next.js routing. Its nine steps, in short:
- Install Next.js: npm install next@latest.
- Create next.config.mjs with output: 'export' and distDir: './dist'. This keeps the app a single-page app for now.
- Update tsconfig.json with the changes the guide lists.
- Turn index.html into a root layout in src/app/layout.tsx and move the title and description into the metadata object.
- Create a catch-all page in src/app/[[...slug]]/page.tsx that loads your existing App in the browser only.
- Fix static image imports. In Next.js an imported image is an object, so <img src={logo} /> becomes <img src={logo.src} />.
- Rename environment variables from VITE_ to NEXT_PUBLIC_. In a Lovable app that means VITE_SUPABASE_URL becomes NEXT_PUBLIC_SUPABASE_URL, and the same for the other Supabase values.
- Change the package.json scripts to next dev, next build and next start, and add .next and next-env.d.ts to .gitignore. Run npm run dev and open http://localhost:3000.
- Clean up: delete main.tsx, index.html, vite-env.d.ts, tsconfig.node.json and vite.config.ts, and uninstall the Vite packages.
After step 9 you have Next.js, but no server rendering yet. The app is still a single-page app, so for SEO nothing changed. You get server-rendered pages only after you move from React Router to the Next.js App Router, page by page. That is the real work.
Your Supabase edge functions are not part of this. They live in the supabase/functions folder and run on Supabase, so they keep working. If you also move off Lovable Cloud, see Deploy Lovable edge functions with the Supabase CLI.
Path B: a TanStack Start app to Next.js
There is no official guide for this, from Next.js or from Lovable. Both frameworks render on the server, so you mostly translate one set of patterns into another. A coding agent is good at this, as long as you go page by page and check each one.
| In the Lovable TanStack Start app | In Next.js |
|---|---|
| Routes in TanStack Router | Folders with page.tsx files in the app directory |
| Server functions (createServerFn) | Server Functions ('use server'), or Route Handlers for an address other services call |
| Public variables with the VITE_ prefix | Variables with the NEXT_PUBLIC_ prefix |
| Server-only variables (no prefix) | Variables without NEXT_PUBLIC_, which only the server can read |
| Build config from @lovable.dev/vite-tanstack-config and Nitro | next.config.mjs |
Lovable used the same idea when it moved its own site. Most of the code (components, helpers, data logic) did not depend on either framework. Right before they removed Next.js, the Next.js-specific code was 3% of their web codebase. For your app it means the components and Tailwind styles mostly copy over. The routes, data loading and server functions are what you rewrite.
Logins: Supabase auth works differently in Next.js
With server rendering, the session has to be in cookies so the server can read it. The Supabase guide for Next.js uses the @supabase/ssr package:
- Install it: npm install @supabase/supabase-js @supabase/ssr.
- Create two clients: one for code that runs in the browser and one for Server Components, Server Actions and Route Handlers.
- Add a Proxy that refreshes the session cookie before each request. On Next.js 16 the file is proxy.ts, on Next.js 15 and earlier it is middleware.ts.
- Protect pages with supabase.auth.getClaims(). Supabase says never to trust getSession() in server code.
A static export does not support Proxy. So on Path A, this part comes after you remove output: 'export'.
Then add the new address of the app to the allowed redirect URLs in Supabase. If logins bounce back to the old address, see Fix Lovable login redirects after a move. If your app uses Lovable Cloud auth, first see Move Lovable auth to your own Supabase project.
Where to host the Next.js app
- Vercel. It is one of the verified adapters that run the full Next.js test suite. The Lovable to Vercel guide has the steps for a Lovable app.
- Your own server. Run npm run build and npm run start on any server with Node.js. This supports all Next.js features. Docker works too, and output: "standalone" gives a smaller image.
- A static export, on any host that serves files, like Nginx, Apache or S3. Features that need a server do not work. If you followed Path A and kept output: 'export', this is what you have. Once you remove it, you need a host that runs Next.js.
Before you point your domain to the new host, check that crawlers see real page content. Lovable SEO after you move shows how. For the domain itself, see Move a Lovable custom domain to a new host.
So, should you do it?
Convert to Next.js if your team already works in Next.js, you are merging the app into a Next.js product or you need something only Next.js gives you. Do it on a branch, with your coding agent, page by page.
Do not convert if what you wanted was SEO, server code or Vercel hosting. A TanStack Start app already has all three and it still works in Lovable. If you only want to keep building the same app outside Lovable, the Lovable to Claude Code, Lovable to Codex and Lovable to Cursor guides do that without changing the framework.
Sources
- Lovable docs: FAQ
- Lovable docs: Upgrade a project to TanStack Start
- Lovable docs: GitHub integration
- Lovable docs: Git sync overview
- Lovable docs: Deploy and host outside Lovable
- Lovable blog: Building apps using TanStack Start
- Lovable blog: How we migrated lovable.dev away from Next.js
- Next.js docs: How to migrate from Vite to Next.js
- Next.js docs: Mutating Data
- Next.js docs: Environment variables
- Next.js docs: Static exports
- Next.js docs: Deploying
- Supabase docs: Creating a Supabase client for SSR
- Vercel docs: Deploy a Lovable app on Vercel