Deploy a Lovable App to Vercel: What Moves

To deploy a Lovable app to Vercel today, you connect the project to GitHub in Lovable, import that repository at vercel.com/new, and click deploy. That’s the whole official process, and for a current Lovable project it works, because Lovable apps are TanStack Start under the hood and Vercel added zero-config detection for them. What the two-step guide doesn’t tell you is which half of your app actually moved.

We checked this on November 11, 2026 against Vercel’s Lovable guide, its TanStack Start docs, and the source of @lovable.dev/vite-tanstack-config 2.27.0, the package that holds a Lovable project’s whole build setup.

Check one version first

Open package.json and find @lovable.dev/vite-tanstack-config. Vercel says zero-config detection needs ^2.6.2 or newer. Anything recent is fine; the current release is 2.27.0, from late October.

If your project is older than mid-2026 you may not have that package at all. Older Lovable apps were plain Vite single-page apps with no server, and those deploy to Vercel as a static site, which is simpler and also a different post.

Here’s why it works without config, straight from the package’s own type definitions. A Lovable build runs Nitro, and Nitro’s default target is cloudflare-module, because that’s where Lovable hosts your app. But Nitro’s own platform detection wins over that default. On Vercel’s build machines, Nitro sees it’s on Vercel and builds for Vercel Functions instead. Lovable’s own builds set LOVABLE_NITRO_PRESET, so the two never fight.

If you build in your own CI and want to pin the target, the package takes nitro: { preset: "vercel" } in vite.config.ts. The same file warns you not to add the TanStack, React or Tailwind plugins yourself, and that warning is serious: you get duplicate plugins and a broken build. One more trap from the source: the old cloudflare option was removed in v2, so a config copied from an early-2026 tutorial gets a warning and the setting is ignored.

What actually moves

Your frontend and the server rendering. That’s it.

If the app runs on Lovable Cloud, the database, sign-in, storage buckets, edge functions and their secrets all stay on Lovable Cloud. The app on Vercel talks to the same backend it talked to before. That’s convenient (nothing to migrate, same users, same data) and it’s also why this is not “leaving Lovable”. You still pay Lovable Cloud usage, and if your balance hits zero the backend can pause, wherever the frontend is hosted.

The connection details come from the repo’s .env file, VITE_SUPABASE_URL and the publishable key. Vite bakes VITE_ variables into the build, so they have to be there at build time. Lovable commits that file with the project, so the first Vercel build usually just works. If someone deleted it or added it to .gitignore (a developer tidying up the repo will do exactly that, it looks like a secrets file), add the same variables in Vercel’s project settings and redeploy. The publishable key is meant to be public; your row level security is what protects the data, not the key.

Things that change on the day you switch

Sign-in links. Password reset and magic link emails point back to a URL your auth settings allow. If that list only knows the .lovable.app address, users on the new domain get bounced to the old one, or to an error page. Test a password reset on the Vercel URL before you move the domain, not after.

The domain. If your custom domain is connected in Lovable, its DNS points at Lovable. Move it to Vercel only when the Vercel deployment has been tested, and expect a short window where some visitors still hit the old host.

Previews. Every push to GitHub now builds on Vercel, including every commit Lovable makes while you prompt. That’s 30 deployments on a busy afternoon. Free, but noisy, and each one is a public preview URL unless you turn on Vercel’s deployment protection.

The plan. Vercel’s Hobby plan is for personal, non-commercial projects. A product with paying users belongs on Pro, which is $20 a month per seat.

Is it worth it?

Honestly, often not. If the only goal is “my app on my domain”, Lovable already does that. Moving the frontend to Vercel makes sense when you want Vercel’s preview deployments for a team, your company already runs everything on Vercel, or you need edge config or logs Lovable doesn’t expose.

If the real goal is to stop depending on Lovable for hosting and billing, the frontend is the easy half. The backend is the part that matters, and it doesn’t move by importing a repo. That’s a Cloud to Supabase migration (from $150, usually 1 to 2 days, everything moves, priced by table count), after which the app runs on a Supabase project you own and can sit on Vercel, Cloudflare or your own server. Not sure what either setup would cost you each month? The free Lovable cost check reads the repo and tells you.