LovabletoVercelandSelf-Hosting:WhyEveryRoute404s,andWhatElseBreaksWhenYouLeaveLovableHosting

The short version

The app works on lovable.app. You synced it to GitHub, imported the repository on Vercel, the build went green, and every route returns 404. Maybe the home page loads and nothing else does. Maybe you found a tutorial, added the vercel.json rewrite it told you to add, and now the home page is gone too. Nothing about the app changed. The host did.

Here is the short version. Lovable has generated two different stacks, and the switch happened on 13 May 2026. Projects from before that date are React and Vite single-page apps, and a static host has to be told to answer index.html for every path. Projects from after it are TanStack Start, which is a server, and a server needs a build in the shape its host expects. For a few weeks after the switch, Lovable's config package built for Cloudflare by default and Vercel got nothing it could run. Since July, Vercel detects a current Lovable project with zero configuration. So there are three states, one fix each, and every tutorial describes exactly one of them as if it were the only one.

Fixing the 404 is the first ten minutes. What comes after it is the rest of this page: the variables that were baked into the build, the secrets that never left Lovable, the database and auth that did not move with the frontend and were never going to, the redirect URLs still pointing at the old domain, the domain hand-over, and whether to keep Lovable as your editor once the code lives somewhere else. Then it tells you who should close the tab and stay exactly where they are, which, in Lovable's own words, is most teams.

Why does a Lovable app 404 on Vercel?

Because the host is serving the wrong shape of build for your stack. That is the whole diagnosis, and the reason it takes people three hours instead of ten minutes is that they do not know there are two stacks to choose between.

Start with the older one, because it is the one every tutorial was written for. A React and Vite project builds to a folder called dist that holds one HTML file and a bundle of JavaScript. Routing happens inside the browser. When a visitor lands on the home page, the bundle loads and React Router takes over, and clicking through to /dashboard never asks the server for anything. Refreshing on /dashboard does. The browser asks the server for a file at that path, there is no such file, and a static host does what static hosts do: it returns 404. Lovable's own guide to hosting outside Lovable states it plainly. Lovable projects use client-side routing with React Router and BrowserRouter, so your web server must return index.html for all routes. It adds a warning worth keeping: do not rely on a storage-level error page for this, because those return a 404 status code and search engines and monitoring tools will read it as one.

A fallback rewrite is the rule that makes a static host return index.html, with a 200 status, for any path that does not match a real file, so the browser gets the app shell and the app's own router can take it from there. Every static host has a one-line version of it. Vercel's Vite guide puts it this way: for a single-page app, deep linking will not work out of the box. It gives the fix as a vercel.json file at the root of the project:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Netlify's version is a single line in a file called _redirects, which its documentation describes as serving index.html instead of giving a 404 no matter what URL the browser requests:

/*  /index.html  200

Cloudflare Pages needs nothing at all. Per Cloudflare's docs, if your project does not include a top-level 404.html file, Pages assumes you are deploying a single-page application and routes every path to the root. If you are on the old stack and you are 404ing, one of those three lines is your fix, along with the build settings Lovable's guide lists: build command npm run build, output directory dist, Node 22.

Now the newer stack, and the reason the rewrite made things worse for some of you. A TanStack Start project is not a folder of files. Server-side rendering is the pattern where a server builds each page into finished HTML before sending it, and that needs a process running on the host to answer every request. A rewrite that tells the host to serve index.html for every path is telling it to serve a file that a server build does not produce in that form. Applied to a working TanStack Start project, it does not fix the 404, and if the host was already detecting the framework correctly it can break the detection. That is the state where the home page vanishes after the fix. The fix for a server build is to give the host a server build it recognises, and the next section is how to tell which state you are in.

Which of the three states is your project in, and which fix is yours?

Open the root of your repository and look at the Vite config. That one file tells you the stack in under a minute, and the version number beside it tells you the state.

Lovable's FAQ is the primary source for the split, and it is one sentence: new Lovable apps created from 13 May 2026 use TanStack Start with server-side rendering, and older apps use React and Vite. Lovable did not move existing projects across. Its post announcing the change on 1 June 2026 said there was nothing to migrate, nothing to update and no decision to make, and its upgrade page adds that a published site keeps serving the old version until you publish again. So the date your project was created is a strong hint, and the file is the proof. If you want the full test, including the ten-second View Page Source check on your live site, our guide to what Lovable actually generates walks it. The one-line version is this. A vite.config that imports the React plugin directly and pulls componentTagger from lovable-tagger is the old stack. A config that wraps everything in a call to @lovable.dev/vite-tanstack-config is the new one, and the version of that package in package.json is what decides the rest.

Here is why the version matters. When the new stack shipped, that package chose where the build was for, and it chose Cloudflare. A developer who published a walkthrough on 30 May 2026 quoted the comment sitting in his own generated config, which described Nitro as build-only using Cloudflare as a default target. Nitro is the deployment layer under TanStack Start, and TanStack's own hosting documentation calls it an agnostic layer that lets a TanStack Start application deploy to a wide range of hosts. Lovable's June post confirmed the choice from the other side: Lovable runs the new stack on Cloudflare Workers for its own hosting. So in that window, a Lovable project imported on Vercel built happily for a platform it was not on, and Vercel found nothing it could serve. Two separate developers wrote up the same three hours on dev.to, one on 13 May and one on 30 May, and both landed on the same fix: add the Nitro plugin in the Vite config with the preset set to vercel, which one of them described as the line that tells Nitro to output the build in exactly the format Vercel expects.

Then the window closed. On 9 July 2026 Vercel's changelog announced that Lovable applications deploy with zero configuration, because Lovable projects now use Nitro, the same toolkit that powers zero-config deployment for TanStack Start on Vercel. Vercel's integration page, updated 10 July, adds the one condition that matters for you: zero-configuration detection requires @lovable.dev/vite-tanstack-config version 2.6.2 or higher, and if your project uses an older version, update it before deploying. That is the third state, and it needs nothing from you beyond a current package.

Two notes before you move on. First, a state B project is one package update away from state C, and that is nearly always the better fix than hand-writing a Nitro preset, because it keeps your config identical to what Lovable generates and stops the next sync from arguing with you. Second, Netlify and Cloudflare have their own versions of this for the new stack. TanStack's hosting documentation names an official Netlify plugin for TanStack Start and an official Cloudflare Vite plugin for Workers, and says a plain Node server runs the build with node .output/server/index.mjs. Lovable's own guide to external hosting, as of today, describes only the Vite path, with dist as the output and index.html for every route, and does not mention TanStack Start, server rendering or Nitro anywhere. If you are on the new stack and following that guide, that is why it is not working. It is not wrong. It is describing the other stack.

What happens to your environment variables and secrets when you leave?

The public ones travel with the build, and the private ones never leave Lovable. Both of those facts will surprise you at the worst moment if you do not know them going in.

Build-time variables are values that the bundler reads once, while building, and writes into the JavaScript it produces, so changing them afterwards changes nothing until you build again. Vite's docs are blunt about it. Variables prefixed with VITE_ will be exposed in client-side source code after bundling, and adds the warning that VITE_ variables should not contain sensitive information such as API keys, because their values are bundled into your source code at build time. Lovable's hosting guide applies that to a Lovable project directly. A project on the built-in backend needs three values from its .env file set on the new host, VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID, and it repeats the point in its own words: environment variables prefixed with VITE_ are embedded at build time, not runtime, and to change them you rebuild.

So the first thing people do wrong is set the variables after the first deploy and wonder why the app still cannot reach its database. The build that is live was made before the values existed. Redeploy. The second thing they do wrong is panic that the publishable key is visible in the bundle. It is meant to be. That key only reaches what your row policies allow, and the one that is an incident is the secret key, which should never have been in a browser in the first place. Our Lovable security guide covers which key is which and what to do if the wrong one is in the bundle, so this page will not repeat it.

The private values are a different story. Lovable's FAQ says secrets and database data are never copied when a project is remixed, and its hosting guide lists environment variables and secrets as a manual step in every migration scenario. The API keys you pasted into the Cloud tab's Secrets section were stored, in Lovable's words, in your Supabase project, and they never appear in your app's code or repository. That is correct behaviour, and it means the repository you just deployed contains none of them. If those secrets are used by edge functions, they are still where the edge functions can reach them, because the edge functions did not move either, which the next section explains. If your new host needs its own copy of anything, for instance a server-side value on the new stack, you set it on the host by hand, and Lovable's guide is explicit that even its Docker generator cannot generate real secrets and leaves placeholders for you to replace.

The new stack adds one distinction the old one never had. A TanStack Start project has code that runs on the server, and Vercel's TanStack documentation treats that server as a Vercel Function. Server-side values do not carry the VITE_ prefix and are never bundled into the browser. Give a server secret a VITE_ prefix and you have published it. Leave the prefix off a value the browser needs and the client will read undefined. The prefix is the line between public and private, and on a server build that line now runs through your own repository.

Can Lovable be self hosted, and what does self hosted actually move?

The app can. The platform cannot. And the phrase self hosted, as most people use it in a search box, describes something that moves about half of what they think it moves.

Lovable's documentation on deployment and ownership is unusually direct on the first half. The Lovable platform itself, meaning the editor and the AI agent, is a managed service and cannot be self-hosted or deployed inside a customer VPC. There is no version of Lovable you run on your own servers. What you own, in the same document's words, is your code and your data, and it lists three independent layers: the code, which syncs to any Git workflow, the frontend, which can run on managed hosting or your own infrastructure, and the backend and data, which can move to a managed Supabase project or a self-hosted one. Lovable's FAQ answers the ownership question in four words, you as the creator do, and our guide to the generated stack covers what that ownership is worth in practice.

Now the half that catches people. Deploying your repository to Vercel, Netlify or Cloudflare moves the frontend layer and nothing else. The database, the authentication, the storage buckets, the edge functions and the secrets all stay exactly where they were, on Lovable Cloud or on the Supabase project you connected, and the deployed frontend keeps calling them at the same URL it always did. That is why a frontend move is cheap and usually works on the first afternoon. It is also why a founder who wanted everything on infrastructure the company controls discovers, a week later, that the users and their data are still on an account they do not hold.

Moving the backend is a separate project with its own rules, and Lovable's documentation is candid about them. Its Supabase integration page says there is no automatic migration between the built-in backend and your own Supabase project in either direction. Its hosting guide lays out what migrates and how: the database schema and the storage buckets move through the SQL migration files in your repository, and everything else is manual. Authentication providers have to be reconfigured. Secrets have to be re-entered. Table data is exported and imported. Storage files are downloaded and uploaded. User accounts move partially, because, in the guide's words, you cannot export user passwords, so every user goes through a password reset. We wrote that half up in Lovable Cloud vs your own Supabase, including what the export actually contains, and this page will not repeat it.

Self-hosting Supabase itself, on your own machines, is the far end of the scale. Lovable's guide supports it and describes applying the migration files from your project's supabase folder to the self-hosted instance, and it adds two warnings that matter. Running only a standalone Postgres database is not sufficient unless you implement equivalent authentication, storage, realtime and edge services. And once you do it, Lovable does not monitor, operate or debug any part of self-hosted infrastructure. A request for first-class self-hosted Supabase support is still open on Lovable's feedback board at the time of writing, which tells you the platform does not treat it as a solved path yet. If the reason you are here is that the built-in backend is running out of room rather than a wish to hold the data, that is a capacity question and our Lovable backend guide answers it without a migration.

What breaks on day two: auth redirects, edge functions and CORS?

Sign-in. Almost always sign-in, and almost always the day after, once a real user tries the magic link or the Google button from the new domain.

The mechanism is a list. Supabase's auth docs define it. The Site URL in URL Configuration sets the default redirect when the code does not specify one, and that any redirect the code does specify should match the Redirect URLs allow list. Your project's list was written when the app lived at a lovable.app address, and possibly at your custom domain on Lovable's hosting. The new host's address is not on it. A magic link or an OAuth callback that tries to land there gets sent to the Site URL instead, or fails, depending on the flow. The fix is to add the new domain and the host's preview pattern to the list, and Supabase allows wildcards in that list precisely so that preview URLs from deployment providers can be covered in one entry. Then check every OAuth provider you enabled, because Google and GitHub hold their own callback list and it still says lovable.app. Lovable's hosting guide notes one more thing you lose if the backend also moves: managed OAuth configuration and automatic token refresh are only available when the backend runs on the built-in backend, so on your own Supabase project, those become yours to configure.

Edge functions do not break, and it is worth understanding why, because it tells you where they live. Lovable's Supabase page says that when it writes a function, it deploys it to your Supabase project and updates your app to call it. Supabase's own deployment documentation shows the result running at your project's supabase.co address under functions/v1. That address did not change when your frontend moved. The function is a server that belongs to the backend layer, its secrets are in the backend layer, and the new frontend calls it exactly as the old one did. The only way an edge function breaks in a frontend move is if it checks the caller's origin and you have not told it about the new one.

Which is the CORS question. Cross-origin resource sharing is the browser rule that a page on one domain may only read responses from another domain if that domain has said it may. Supabase's API answers any origin by default, so most Lovable apps never hit this. If someone hardened your project by pinning an allowed-origins list in an edge function or in a proxy, the new domain has to be added to it, and the symptom is a request that works in a terminal and fails in the browser with a message about the origin. Our production checklist for Lovable apps covers the allowed-origins decision itself, and the hub is the page to read once this one has your site up.

How do you move the custom domain without downtime?

Deploy on the new host first, verify it on the host's own temporary address, then move the domain. People do it in the other order because the domain feels like the finish line, and then the site is down while they debug.

Lovable's custom domain documentation tells you what is sitting at your registrar. A domain connected to Lovable points an A record at a Lovable address and carries a verification TXT record on a host called _lovable, or a CNAME instead of the A record on some setups. Some of those records were created by Lovable and are locked in its interface. Those records, per the same page, show a lock icon, cannot be edited or deleted by you, and that Lovable removes them when you disconnect the domain from the project. Anything else you must clear yourself, and the same page says to clear DNS settings at your domain provider to completely clear the connection.

The order that avoids downtime is short. Add the domain on the new host first, which gives you the records it wants. Confirm the app answers on the host's temporary address with sign-in working, because of the previous section. Then disconnect the domain in Lovable's project settings, which removes the locked records. Then replace the remaining Lovable records at your registrar with the host's, and wait. Both sides issue certificates automatically, Lovable generates and installs one when a domain connects and Vercel does the same, so SSL is not a step you take, it is a step you wait for.

Two things to know before you start. Lovable is explicit that there is currently no way to remove the project's lovable.app address from the project, so the old address keeps answering, and anything that cached it, a bookmark, a link in an email, a share on social, keeps working and keeps sending people to the old build. Decide whether you want that. And if you shipped a progressive web app, Lovable's upgrade documentation warns that cached versions on people's devices may need a manual follow-up, which is just as true of a host move as of a stack upgrade. A user whose phone is holding the old shell will keep seeing it until the service worker updates.

Should you keep Lovable as your editor after you move?

Yes, by default, and for longer than the migration vendors would like. Nothing about hosting elsewhere requires you to stop building in Lovable, and Lovable documents it.

The mechanism is the GitHub integration, and it runs in both directions. Per Lovable's integration page, changes made in Lovable sync to GitHub and changes pushed to the active GitHub branch sync back into Lovable. Vercel's integration page describes the result from its side: once connected, every change you make in Lovable syncs to GitHub and triggers a new deployment. So the loop after the move is the same loop as before it, with your host at the end instead of Lovable's publish button. Lovable's hosting guide extends that to the backend case too. You can continue using the Lovable editor and preview environments during development after moving to your own Supabase.

The limits are the ones in Lovable's GitHub documentation, and they are worth knowing before a developer joins. Each Lovable project connects to one repository. Lovable edits and syncs one branch at a time, so a push to a different branch will not appear in the editor until it is merged or you switch the synced branch. The same file edited in both places at once can conflict. And the integration only runs one way at setup: you can export from Lovable to GitHub, not start a Lovable project from an existing repository. Sync stopping altogether nearly always traces to one of the reconnection cases the documentation lists, a suspended or uninstalled GitHub app, lost access to the repository, or a deleted repository, and the editor prompts you to reconnect.

What you give up is small and specific. Lovable's hosting guide is clear that production previews are not generated for a self-hosted production environment, and Lovable cannot see your host's logs or debug infrastructure it does not control. What you keep is everything else, including the agent. The honest default is to keep the editor connected until someone is working in the repository every day and finding the sync a nuisance, and then to have that person decide. That is a workflow decision, not a migration one.

One last thing, because half the searches around this topic are about getting the code out at all. Lovable's code editor page spells out the routes. On paid plans, anyone with edit access can click Download codebase at the bottom of the file panel and get a zip. A single file downloads on any plan from the file toolbar. The Free plan's editor is read-only. Enterprise admins can restrict downloads to workspace admins and owners. And for ongoing work outside Lovable, the same page tells you to connect the project to GitHub or GitLab instead of downloading snapshots, because sync keeps the repository and the project in step both ways. A zip is a photograph. Sync is the live feed. If you deployed from a zip, you deployed a photograph, and the next change in Lovable will not reach your host.

Who should not leave Lovable hosting at all?

Most of you. That is not our opinion, it is the first thing Lovable's own guide to hosting outside Lovable says, and it is right.

The guide opens by saying it is intended for teams with specific requirements, such as compliance constraints, data residency needs or organisational infrastructure policies, and then says that most teams never need to migrate, and that you can start on Lovable and move components later if and when you hit real constraints. Lovable's hosting includes custom domains, automatic deployments, managed authentication, preview environments and certified infrastructure. If you are a solo founder, no developer is joining, nobody in compliance has asked, and the site works, moving it buys you a weekend of the work on this page and a hosting bill you did not have. Stay.

Move if one of three things is true. A developer is joining and wants an ordinary repository with pull requests and preview deployments on the host they know. The company needs the frontend running under an account it holds, for a policy reason or a procurement one. Or a compliance requirement names where the frontend and the data must run, in which case you are doing the backend move too and the page you need next is the Cloud versus Supabase one.

And do not move for the wrong reasons, because they are common. A leaking table is not fixed by changing hosts, it is fixed by a row policy, and it will leak from Vercel exactly as it leaked from Lovable. A backend that has run out of room does not get more room from a new frontend host. A site that is not being indexed is almost never a hosting problem, and if that is what brought you here, our Lovable SEO guide is the page you want, because the answer there is about rendering and not about where the files sit.

When is a rebuild the honest answer, and when is a 404 being sold as one?

Never for a 404. There is no version of this problem where the right answer is a different codebase, and the people telling you otherwise are usually paid by the rebuild.

Read back through the page. A rewrite rule. A package version. Six variables in the right scope. A redirect URL list. Two DNS records. A decision about the editor. Every one of those is a line of configuration or a setting inside the application you already have, and the application is ordinary React and TypeScript that Lovable's own June post says was chosen to be easy to deploy anywhere. When an agency looks at a screenshot of a 404 and says the app needs to be rebuilt in a proper stack before it can be hosted properly, ask them which line on this page cannot be done to your repository. There is not one.

The one genuine piece of engineering in this whole territory is not about hosting. It is the upgrade from the old stack to the new one, where Lovable's own documentation warns that some code libraries only work in the browser and can break server rendering in ways the upgrade's checks do not catch. That is real, it is a component-loading fix rather than a rewrite, and it is covered in our guide to what Lovable generates. It has nothing to do with which host you are on.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, and we do not sell rebuilds. Your Lovable app stays your Lovable app, on whichever host makes sense for you. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, and the production checklist for Lovable apps is the hub this page hangs off.

The first step is a written deploy read. Send us the repository and the URL that 404s. A senior engineer names which of the three states you are in, writes the fix, lists every variable, redirect and record that has to change, and tells you honestly whether you should be moving at all. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

Why does my Lovable app 404 on Vercel?

Because the host is serving the wrong shape of build for your stack. Lovable projects created before 13 May 2026 are React and Vite single-page apps, and Lovable's own hosting guide says the server must return index.html for every route, which on Vercel is a rewrite in vercel.json. Projects created or upgraded after that date are TanStack Start, a server-rendered framework. Vercel deploys those with zero configuration when the project carries @lovable.dev/vite-tanstack-config version 2.6.2 or higher. Below that version the package built for Cloudflare by default and every route 404ed on Vercel until the Nitro preset was set to vercel. Adding the Vite rewrite to a TanStack Start project does not fix it and can break a working build.

Can Lovable be self hosted?

The app, yes. The platform, no. Lovable's ownership documentation says the Lovable platform itself, meaning the editor and the AI agent, is a managed service and cannot be self-hosted or deployed inside a customer VPC. The code is yours and syncs to GitHub or GitLab, the frontend can run on any host that serves a static build or a JavaScript server, and the backend can move to a managed or self-hosted Supabase project. Moving the frontend alone leaves the database, auth, storage and edge functions exactly where they were.

Do I need to add a vercel.json rewrite to a Lovable project?

Only if the project is on the older React and Vite stack, where every route must fall back to index.html. A vite.config at the root that imports lovable-tagger or the React plugin directly is that stack. A project whose config wraps @lovable.dev/vite-tanstack-config is TanStack Start, and a rewrite to index.html is the wrong fix for a server build. Delete any rewrite you copied from a Vite tutorial, update the config package to 2.6.2 or higher, and import the repository again.

Does moving my Lovable app to Vercel move my database?

No. Deploying the repository to Vercel, Netlify or Cloudflare moves the frontend only. The database, authentication, storage, edge functions and secrets stay on Lovable Cloud or on the Supabase project you connected, and the deployed frontend keeps calling them at the same URL. Lovable's Supabase documentation says there is no automatic migration between the built-in backend and your own Supabase project in either direction, and its hosting guide says user passwords cannot be exported at all.

Can I keep editing in Lovable after deploying to Vercel?

Yes. Lovable's GitHub integration is two-way on the active branch, so changes made in Lovable commit to the repository and Vercel deploys each commit. Lovable's own hosting guide says you can continue using the Lovable editor and preview environments during development after moving. What you lose is Lovable's production previews for a self-hosted production environment, and Lovable cannot see your host's logs. Keep the editor until a developer is working in the repository every day, then decide.