To deploy a Lovable app to Vercel, sync the project to GitHub, identify whether it uses TanStack Start or the older React and Vite stack, and import that repository into Vercel. The two stacks need different deployment settings. A legacy Vite app builds to static files in dist and needs a single-page-app rewrite. A TanStack Start app uses server-side rendering and needs Nitro so Vercel can deploy its server code as functions.
Lovable and Vercel are not alternatives. Lovable builds the app, Vercel hosts it, so this is a handoff and not a choice between two products.
Here are the settings, before the explanation.
| Setting | Legacy React and Vite app | TanStack Start app |
|---|---|---|
| Framework Preset | Vite | TanStack Start, detected by Vercel |
| Build Command | npm run build | npm run build |
| Output Directory | dist | Leave as detected, never force dist |
| Node.js Version | 22 | 20 or newer, 22 to match Lovable |
SPA rewrite in vercel.json | Required for nested routes | Do not add it |
Nitro plugin in vite.config.ts | Not used | Required before the import |
Those settings come from Lovable’s external-hosting guide, which recommends Node 22 with npm run build and dist, and from Vercel’s TanStack Start guide, which requires Node.js 20 or newer and the Nitro plugin.
This guide reflects Lovable and Vercel documentation checked on August 6, 2026. It is evidence-based deployment guidance, not a claim that every generated Lovable project has been tested hands-on. Inspect the files in your own repository before changing production.
First, identify which Lovable stack you have
Lovable’s current FAQ says new apps use TanStack Start with server-side rendering, with the rollout beginning on May 13, 2026. Older apps use React and Vite, and eligible older projects can now use Lovable’s in-place TanStack Start upgrade. Project age is only a clue. Check package.json and vite.config.ts, or ask Lovable, What stack is this project on?
| Check | Older React and Vite app | TanStack Start app |
|---|---|---|
| Typical dependency | No @tanstack/react-start package | @tanstack/react-start is present |
| Production output | Static frontend in dist | Client assets plus server output through Nitro |
| Routing on Vercel | SPA fallback rewrite to /index.html | Server routing handled by TanStack Start and Nitro |
| Build configuration | npm run build, output dist | Let Vercel detect TanStack Start once Nitro is configured |
| Runtime | Browser only for the deployed frontend | Browser plus Vercel Functions for SSR and server code |
This distinction matters because Lovable’s general external-hosting guide still documents Vite static settings. Do not force dist as the output directory on a TanStack Start project just because an older Lovable tutorial says to do so.
Prerequisites and access
Before starting, confirm that you have:
- edit access to the Lovable project;
- workspace or project owner or admin access to make the GitHub connection;
- permission to create or connect the GitHub repository;
- access to the Vercel team that will own production;
- access to the app’s public configuration, server secrets, authentication settings, and DNS;
- a known-good Lovable deployment or Vercel deployment to return to if validation fails.
Moving the production frontend does not require moving the database. It does make you responsible for the Vercel deployment pipeline, frontend environment variables, preview configuration, logs, rollbacks, and domain routing.
Step 1: connect Lovable to GitHub
Follow Lovable’s GitHub connection flow from Project settings → Git → GitHub, or from Workspace settings → Git → GitHub. A workspace or project owner or admin links the GitHub identity, installs the Lovable GitHub App, and connects the project. Lovable creates a repository and begins two-way synchronization: changes made in Lovable sync to GitHub, and commits pushed to the active branch sync back into Lovable.
Treat the repository path as stable. Lovable warns that deleting the repository, renaming the GitHub account or organization, or transferring the repository elsewhere breaks the sync. Also remember that an edit made in Lovable can create a commit on the default branch, and Vercel will normally deploy that commit automatically after the repository is connected.
Git sync is the export route Lovable documents, and its own external-hosting guide states that every hosting scenario in it requires a GitHub connection. Third-party ZIP downloaders exist and will get a copy of the code onto Vercel once, but a hand-uploaded copy gives up Lovable-triggered redeploys and Preview deployments per branch. Manual and CLI deployments still create Vercel deployments that can be promoted or rolled back, but they do not create the Git automation.
Expected result: the repository contains your project files and the latest Lovable commit, and a normal local install and build can read the lockfile without changing it.
Step 2A: Vercel settings for a legacy React and Vite Lovable app
In Vercel, create a project and import the GitHub repository. For an older static Lovable app, confirm these settings:
Framework Preset: Vite
Build Command: npm run build
Output Directory: dist
Node.js Version: 22Lovable’s external-hosting documentation recommends Node 22. If the repository already pins another supported version in package.json, .nvmrc, or a tool-version file, resolve that mismatch before deploying instead of changing production by guesswork.
The dashboard Git import is the path this guide documents, and it is the one that keeps automatic redeploys. Vercel’s guide also supports installing the Vercel CLI and deploying from a terminal, which is useful for a one-off test but does not set up the push-to-deploy loop on its own.
Legacy Lovable apps normally use client-side routing. If the home page loads but refreshing /dashboard or another nested path returns 404, add a Vercel rewrite that serves index.html for routes that are not static files:
{
"rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}Commit vercel.json, redeploy, and test a direct visit and browser refresh on every important route. This rewrite belongs to the static Vite path. Do not add it to a TanStack Start app, where it would bypass server routing.
Step 2B: Vercel settings for a TanStack Start Lovable app
A TanStack Start deployment is not just a static frontend upload. SSR, server routes, and server functions need a Vercel-compatible server build. Vercel’s current TanStack Start guide uses the Nitro Vite plugin for that output.
Check vite.config.ts. If Nitro is already imported from nitro/vite and registered beside tanstackStart(), do not add it again. If it is missing, install nitro and update the configuration in a reviewed branch:
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { defineConfig } from "vite";
import viteReact from "@vitejs/plugin-react";
import { nitro } from "nitro/vite";
export default defineConfig({
plugins: [tanstackStart(), nitro(), viteReact()],
});Vercel requires Node.js 20 or newer for the documented TanStack Start path. Using Node 22 also matches Lovable’s current hosting recommendation. Once Nitro is present, import the repository and confirm that Vercel detects the framework as TanStack Start. Do not override it with the Vite preset or a static dist output directory.
Expected result: the deployment summary includes server functions, the initial page contains server-rendered content, nested routes work on direct requests, and server functions return responses. If the build succeeds but routes return 404, verify that nitro() is present and that Vercel detected the project root and TanStack Start preset correctly.
What Vercel’s zero-config import does and does not do
You have probably seen the claim that Lovable apps import to Vercel with zero config. It is true in the narrow sense that matters at import time: Vercel reads the repository, detects TanStack Start and Nitro, and applies the correct settings without you filling in a build command or an output directory.
What it does not do is put Nitro in the repository for you. Vercel’s own TanStack Start guide, last updated July 16, 2026, still walks through installing nitro and adding the plugin to the plugins array in vite.config.ts by hand. Detection reads what is already there.
That is the gap behind most failed zero-config imports. A repository with no nitro() in vite.config.ts can still import cleanly and still build green, because nothing in that flow needs the server output until a request arrives. Then every route returns 404, because the deployment has client assets and no server to route them. Check vite.config.ts first, before you start changing project settings in the Vercel dashboard.
Step 3: configure environment variables by execution boundary
GitHub synchronization does not copy a private Lovable or local environment into Vercel project settings. Add each required value in Vercel and scope it deliberately to Production, Preview, or Development.
For Lovable Cloud or Supabase-backed browser code, the common public values are:
VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY
VITE_SUPABASE_PROJECT_IDLovable’s external-hosting guide says to read those three values from the .env file in Lovable’s code editor or in the synced GitHub repository, then paste them into Vercel. Server-side keys are a different store: those live under Secrets, which you reach by opening the More menu in the project toolbar and selecting Cloud. Nothing from either place appears in Vercel until you put it there yourself.
A VITE_ prefix means Vite can embed the value in browser JavaScript. Use it only for configuration designed to be public, such as a Supabase URL and publishable key. Never place a database password, service_role key, Stripe secret, webhook secret, or private provider key in a VITE_ variable.
TanStack Start also has server-side execution. Keep server-only secrets unprefixed and read them inside server functions or server routes through process.env. TanStack’s environment guidance warns that code is isomorphic by default, so confirm that secret reads stay behind an explicit server boundary.
Vercel applies environment-variable changes only to new deployments. Add or change the value, then redeploy. That’s the reason the same code works on your laptop and breaks the moment it’s live on Vercel. The source can be identical while the build-time or runtime configuration is different.
Step 4: decide what happens to backend and edge functions
For a legacy Vite app, Vercel hosts the compiled frontend. Lovable Cloud, a connected Supabase project, authentication, storage, Realtime, database functions, and Supabase Edge Functions stay with the existing backend. Their secrets stay there too. Do not copy a backend secret into Vercel unless code running on Vercel genuinely needs it.
TanStack Start adds a second case. Lovable’s upgrade documentation says backend code used only by the app can move into the TanStack template, while endpoints called directly by external services keep their existing addresses. When that repository is deployed through Nitro, its TanStack server code runs on Vercel Functions. Inventory both categories before cutover:
- browser calls to Lovable Cloud or Supabase remain external backend calls;
- TanStack server functions and SSR code deploy to Vercel;
- Supabase Edge Functions remain in Supabase unless separately migrated;
- fixed webhook, scheduled-job, or external integration URLs must keep working at their documented address.
Actually leaving Lovable Cloud’s backend is a bigger job with its own checklist, export limits and all. A frontend deployment and a backend migration are separate projects.
Step 5: separate Preview from Production
Vercel creates Preview deployments for non-production branches and pull requests. A Preview URL is a separate frontend deployment, not a separate database. If Preview receives the Production Supabase or Lovable Cloud variables, tests against that URL can read or modify production data.
Use Vercel’s Preview environment-variable scope and point it at a test backend where possible. If no test backend exists, document the risk, restrict who can access the preview, and do not perform destructive tests there. Environment variables on old preview deployments remain unchanged until those deployments are rebuilt.
For TanStack Start, validate both halves of Preview: server rendering and functions on Vercel, plus calls to the selected backend. For legacy Vite, validate routing and the backend calls from the browser.
Step 6: update OAuth redirects and the custom domain
Before moving real traffic, add the production domain to the application’s allowed post-authentication destinations. For Supabase Auth, set the production Site URL and add the exact app paths used by redirectTo; Supabase’s redirect guide documents a separate pattern for Vercel Preview URLs. Test sign-up, sign-in, password recovery, invite links, and sign-out from the final domain. A working home page does not prove that an authentication callback is allowed.
Check the OAuth provider separately. If Supabase or Lovable Cloud brokers the login, the provider callback normally points to that auth service, while the auth service redirects the user back to the Vercel domain. If a TanStack server route on Vercel owns the OAuth callback, register that exact Vercel route with the provider. Avoid a broad wildcard unless the provider documents it and the exposure is understood. A dedicated test backend and OAuth client is the cleaner Preview setup.
After the Vercel URL passes validation, add the custom domain in Vercel and apply the DNS records it provides. Keep the previous Lovable deployment available during the cutover. Moving the domain changes where the frontend is served; it does not move the database or copy its contents.
Deployment validation checklist
Do not treat the green build as the finish line. Verify the deployed behavior that depends on each execution boundary:
- 01 Open the home page and every important nested route through a direct URL, then refresh each route
- 02 For TanStack Start, inspect page source for server-rendered content and exercise every server function or API route
- 03 Create a test account, sign in, sign out, recover a password, and complete each configured OAuth callback on the final domain
- 04 Read and write a test record, upload and retrieve a test file, and confirm Realtime behavior if the app uses it
- 05 Exercise every Supabase Edge Function, webhook, paid API call, and scheduled integration without exposing its secret to the browser
- 06 Check Vercel build and function logs plus backend logs for errors, then repeat the checks from a Preview deployment with Preview variables
A green build is not a working app
I have seen the gap between a green build and a working app up close. In one client-side CRM dashboard I audited, the Next.js config had ignoreBuildErrors and ignoreDuringBuilds both set to true, layered over a strict: true TypeScript setup nobody was actually enforcing anymore. That pair of flags was already hiding a real duplicate-member error sitting in the code. None of it stopped the build. The builder’s auto-deploy pushed every commit straight through regardless, and the one automated check that might have caught it was the exact thing switched off. Point that same repository at Vercel and it deploys exactly as green as it already was.
In the 26-app audit corpus, 22 carried at least one confirmed-critical finding. Those findings did not necessarily prevent a successful build because compilation, deployment, access control, billing integrity, and recovery are different checks. That evidence is a reason to validate the important workflows after deployment, not evidence that Vercel caused or fixed the findings.
Vercel deployed your interface. It didn’t deploy your database, your keys, or the proof that the app can take real customers.
Whether the app built on Vercel and whether people can safely rely on its important workflows are separate questions. The first is answered by the deployment; the second is part of deciding whether an AI-built app is ready for real use. Whether a Lovable app specifically clears that bar is its own question, and it does not move just because the frontend now lives on a different host.
When the Vercel deployment fails: symptom, cause, fix
Most failures on this route are one of six things. Match the symptom before you change settings.
| Symptom | Likely cause | Fix |
|---|---|---|
| 404 on a nested route after a refresh, home page fine | No SPA rewrite. Legacy React and Vite apps only | Add the vercel.json rewrite from Step 2A, commit, redeploy, retest every route |
| Build fails with exit code 1 | Node version mismatch, or a real TypeScript or lint error that the Lovable preview never ran | Read the build log’s first error. Align the Node version, then fix the code error rather than muting it |
| Blank white screen, build was green | A VITE_ variable was missing at build time, so the browser bundle shipped with an undefined value | Add the variable in Vercel, then redeploy. Existing deployments never pick up new values |
Runtime error such as process is not defined, or an env var reads as undefined in the browser | A server-only value is being read from browser code | Move the read into a server function or server route, and keep public values on the VITE_ prefix |
| 404 on every route in a TanStack Start app | nitro() missing from vite.config.ts, or the Vite preset overriding framework detection | Register the Nitro plugin, remove any forced dist output, redeploy and confirm server functions appear |
| Login works, then the callback is rejected | The Vercel domain is not on the auth service’s redirect allow list | Add the production domain and the exact callback paths in the auth service, then retest sign-in end to end |
Rollback if the Vercel deployment fails
Before changing DNS, record the current Lovable domain and DNS values. Vercel can roll a project back to a previous deployment by reassigning the production domain, but an older deployment also retains the environment values it was built with. If the first Vercel cutover itself is the failure, restore the previous DNS or domain assignment so traffic returns to the known-good Lovable frontend.
Do not delete the GitHub repository, Lovable project, old deployment, backend, or database during this rollback window. Fix the failure in a branch, create a new Preview deployment, rerun the validation checklist, and only then promote or cut over again.
Common questions about deploying Lovable to Vercel
How do I deploy a Lovable app to Vercel?
Connect the Lovable project to GitHub so it syncs to a repository, then create a Vercel account and import that repository. Choose the settings for your stack: a legacy React and Vite app uses the Vite preset with npm run build, output dist, and an SPA rewrite in vercel.json, while a TanStack Start app needs the Nitro plugin in vite.config.ts and is then detected automatically. Add your environment variables in Vercel and redeploy, because a variable added after a build does not reach that build. Test the deployed URL, including nested routes and login, before you point the custom domain at it.
Why does my Lovable app show a 404 when I refresh a page on Vercel?
On a legacy React and Vite app, this means the SPA fallback rewrite is missing: routing happens in the browser, so a direct request for /dashboard looks for a file that is not there. Add a vercel.json with a rewrite from /(.*) to /index.html, commit it, and redeploy. On a TanStack Start app the cause is the opposite one, a missing server build, so add the Nitro plugin instead and never add the SPA rewrite there.
Why is my Vercel build failing with exit code 1?
Exit code 1 just means the build command stopped with an error, so the answer is always in the first error line of the build log, not in the exit code. The two common causes on this route are a Node version mismatch between Vercel and what the repository expects, and a real TypeScript or lint error that the Lovable preview never ran. Fix the underlying error rather than switching off type checking or lint in the build config, because a build that ignores errors will ship them.
Can I deploy any Lovable app to Vercel with the same settings?
No. Older React and Vite apps use a static dist build and SPA rewrite. Newer TanStack Start apps use SSR and need Nitro so Vercel can deploy server output. Identify the stack from the repository before choosing the preset and output settings.
Does deploying Lovable to Vercel move my database?
No. The existing Lovable Cloud or Supabase backend remains in place unless you run a separate backend migration. TanStack server code in the repository can move to Vercel Functions, but that does not move the database, storage, auth service, or Supabase Edge Functions.
Why does my Lovable app work in the Lovable preview but fail on Vercel?
The common causes are the wrong stack preset, missing Nitro in a TanStack app, no SPA rewrite in a legacy Vite app, a Node-version mismatch, missing environment variables, or an OAuth callback that does not allow the Vercel domain. Use the build and function logs to identify which boundary failed.
Do Lovable environment variables transfer to Vercel automatically?
No. Add the required values to Vercel and scope them to the correct environment. Keep browser-safe VITE_ values separate from unprefixed server secrets, then redeploy so the new deployment receives them.
Can I keep using Lovable after deploying to Vercel?
Yes. GitHub synchronization can keep Lovable as the development environment while Vercel deploys from the repository. Remember that changes reaching the production branch can trigger a production deployment, so use branches, reviews, Preview variables, and a rollback path.
Does deploying to Vercel mean I can cancel my Lovable plan?
Not by itself. Hosting the frontend somewhere else does not replace the builder or the backend: if you keep editing the app in Lovable you still need the account that does the editing, and if the app runs on Lovable Cloud then the database, auth, storage, and edge functions are still there serving traffic. What changes is where the pages are served from and who owns the deployment pipeline. Dropping the plan entirely is a separate project, because it means moving the backend and giving up Lovable as the place you build.
Can I add a custom domain to a Lovable app hosted on Vercel?
Yes. Add the domain in the Vercel project and apply the DNS records Vercel gives you, after the generated Vercel URL has passed the validation checklist. Update the auth service’s Site URL and redirect allow list to the new domain at the same time, or logins will break on the very first real visit. Moving the domain changes where the frontend is served and nothing else, so the database and its contents stay exactly where they are.
Ready to move off the builder?
We move your working app off the builder, keep what works, and set up the hosting, data, and release path needed afterward.
