Lovable moved to TanStack Start. What does that mean for my app, and should I migrate?

If you built something on Lovable last year and somebody built something on Lovable last month, you are not using the same product any more. The underlying application is different in a way that changes how it is hosted, what search engines see, which of your code runs where, and which advice on the internet applies to you.

Nobody told most people this, because it arrived as a changelog entry rather than an announcement to existing users, and existing projects were deliberately left alone. So there are now two populations of Lovable app quietly diverging, and a great deal of confused troubleshooting comes from advice written for one being applied to the other.

Here is what changed, what it fixed, what it broke, and how to decide.

What changed and when

From around 13 May 2026, new Lovable projects are built with TanStack Start and deployed to Cloudflare Workers, replacing the previous arrangement of a browser-only React application served as static files. The enterprise default followed on 22 June 2026. On 28 July 2026 an upgrade tool arrived for existing projects — opt-in, costing somewhere between ten and thirty-five credits, never running without confirmation, and reversible through version history.

That last sentence is the most important operational fact in this article. Your existing app has not changed and will not change unless you ask.

What it means in plain terms

The old arrangement worked like this. A visitor asks for a page. The server sends back an almost empty HTML file plus a large bundle of JavaScript. The visitor's browser runs that JavaScript, fetches the data, and constructs the page. Everything that makes your page your page happens on the visitor's machine.

The new arrangement can do the work first. The page can be assembled on the server, with its real content in it, before it ever reaches the browser.

For a human on a fast connection the difference is mostly invisible. For everything that is not a human with a browser, the difference is total.

The problem this fixes, which is bigger than it sounds

There has been a persistent, badly understood complaint about apps built this way: share a link to a specific page and the preview shows your homepage's title and description rather than the page's own. Product listings, profiles, articles — all of them share as the same generic card. Sitemaps behave oddly. Search results look thin.

The explanation is in Lovable's own hosting documentation and it is more interesting than "SEO is broken". Older apps did serve rendered pages — but only to verified search engine crawlers, social preview bots and AI crawlers. Not to ordinary visitors.

Read that carefully, because it explains everything. It was a bot-only prerender. Which means a whole class of problem became almost impossible to diagnose: you test the page, it looks fine; you share it, the preview is wrong; you look at the source, and what you see depends entirely on what the server thought you were. Two people could check the same page and get different answers and both be telling the truth.

The new stack renders for everyone. That is the fix, and for anything that depends on being found or shared, it is a real one.

There is a corollary worth stating plainly, since a lot of the advice you will read is now out of date: "Lovable ships a browser-only app so search engines cannot see it" is no longer true for new projects. It is still true for older ones.

What it broke

Deploying anywhere other than Cloudflare. This is the loudest complaint and the most confusing symptom. The build now targets Cloudflare's runtime and emits a server handler shaped for it. Take that same repository and deploy it to another platform and the build often succeeds and then the site serves the host's own not-found page. It reads exactly like a broken route and it is not one — it is a mismatch between what the build produced and what the host expected. Several people describe an identical repository deploying happily to Cloudflare and failing on their previous host on the same afternoon.

Libraries that assume a browser. Code that touches the window, the document or browser storage at the top level now runs on the server, where none of those exist. This is the standard cost of adopting server rendering anywhere, and it is not unique to Lovable, but it lands on people who never chose server rendering.

Environment variables split in two. Values available to server code and values compiled into the browser bundle are now genuinely different categories, with different handling. Getting this wrong is how a secret ends up in the published output, which is a problem I have written about separately in are my API keys exposed.

The assistant itself. A recurring note in the reports from May and June is that the agent had a harder time resolving bugs in the new stack than in the old one, and several people said in so many words that they had not had these problems before the change. That is a normal transitional cost — there is less of this pattern in the world for a model to have learned from — but it is a real one if you are relying on the assistant to get you unstuck.

Cached progressive web apps may hold onto the old version and need a manual nudge, which produces a bewildering support conversation where a customer insists nothing has changed.

The trap that catches anyone working outside the editor

This one deserves its own section because it costs the most hours per person affected, and because it is not documented by the vendor.

A developer described the following in July 2026. Frontend on Lovable, their own Supabase project, repository connected, server-side functions and database migrations authored in a separate editor and pushed through git.

Functions and migrations the Lovable assistant writes deploy automatically. The same files, written elsewhere and brought in through repository sync, sync but are never deployed or applied. The dashboard shows the older bundle with a recent-looking timestamp, so everything reads as current. They spent hours debugging code that was not running.

The detection is simple once you know to look: make a request that only the newest version could possibly satisfy — a new route, a changed response, anything with a fingerprint on it — and see whether you get it. The fix is to explicitly instruct the assistant to force a redeploy of functions and apply outstanding migrations.

I want to be honest about the status of this one. It is a detailed and credible first-hand report that matches the general direction of the platform binding deploys to the assistant's own workflow, and it is not something the vendor documents. Treat the behaviour as reported rather than confirmed — and check for it anyway, because if you are doing rescue work on a Lovable project from an external editor, this will cost you an afternoon before you find it.

Should you migrate?

Yes, fairly promptly, if being found or shared matters. A public product, a marketplace, anything with content pages, anything where a link gets posted somewhere. The bot-only prerender was never going to serve you properly and the new stack is the intended answer.

No, or not yet, if the app lives behind a login. Internal tools, dashboards, client portals. All the benefit is in what unauthenticated visitors and crawlers see, and by definition they see nothing. The migration is cost without return.

Carefully, if you have significant custom work, particularly anything written outside the editor, browser-only libraries, or a heavily customised build. Not a reason to avoid it — a reason to do it on a copy first.

And there is a fourth answer worth naming: if you were already planning to move off the platform, do not migrate. Spending credits to modernise an app you intend to leave is effort in the wrong direction, and the older browser-only build is in some ways easier to lift and re-host elsewhere. That decision has its own article in rescue or rebuild.

How to tell which one you are on

View the source of a live page. Right-click, view page source — the raw HTML, not the developer tools element inspector, which shows you the page after JavaScript has run and will therefore always look fine. Search that raw text for a sentence you know is on the page. Present means server-rendered. Absent, with a mostly empty container and a pile of script tags, means the old stack.

Or check when the project was created. Anything before roughly mid-May 2026 is on the older stack unless somebody has since upgraded it.

Or share a link to a deep page into any chat application and see whether the preview shows that page's own title or your homepage's. That test takes ten seconds and answers the question that probably brought you here.

If you do migrate, the order to do it in

Duplicate the project first. The upgrade is reversible through version history, but a copy is better than a rollback and costs you nothing but a moment.

Take a database export before you start, for the reasons in what happens if the platform locks you out — not because migration is likely to lose data, but because taking one is free and this is a natural moment.

Run the upgrade on the copy. Confirm the confirmation, watch the credits, and let it work.

Then check four things in this order: does every page still render, does authentication still work end to end, do the pages that were browser-only still function, and does the raw page source now contain your actual content.

Then look at your metadata, because this is the payoff. Per-page titles and descriptions and preview images now actually reach the people they were meant for, and if they were written once and never revisited — which is usual, since they never worked — this is the moment they start earning.

Then redeploy properly and re-share a deep link to confirm the preview is right.

If you would rather have somebody do this

Migrating a small app is genuinely a job you can do yourself with the tool's own upgrade path, and I would not talk anybody out of trying it on a copy.

Where it stops being a self-service task is when the app has custom work outside the editor, an external database, server-side functions somebody wrote by hand, or an integration that assumed the old hosting shape. That is when the upgrade stops being a button and starts being a migration.

I do a Production-Ready Audit that covers this ground: which stack you are actually on, what in your app will break under server rendering, whether your functions and migrations are genuinely deployed or only synced, what the hosting change means for wherever you deploy, and a written plan with the honest cost of each step. From $499, back in five to seven days.

You can also just send me your live URL. I can tell you which stack it is on and whether the metadata is reaching anybody, in about a minute, at no charge and with nothing attached.

Build and migration work is described on the MVP development page, and repair work on existing apps is on the AI SaaS rescue page. If your symptom is that things work in the editor and break once deployed, the general version of that problem is in why your app works in preview but breaks in production. And for how the platforms compare on the things that matter once real users arrive, there is Lovable vs Bolt vs Replit vs Cursor for production.