How to put your app back to the version that worked

You pushed a change. Now the app is white, or the login button does nothing, or a customer just emailed you a screenshot of something that shouldn't exist. Your chest is tight and you are already typing another instruction into the chat, asking it to fix what it just did.

Stop typing. Just for two minutes. Putting the app back to the last version that worked is usually one button, and it is almost always the right first move. It gets your users onto something functional while you figure out what happened.

The alternative — asking the AI to patch a broken thing while it is live and while you are panicking — is how a small break becomes a big one. Going back is not giving up. It is putting the app somewhere safe while you think.

Why does going back restore the code but not the data?

Because they live in completely different places. There is the code — the pages, the buttons, the logic. And there is the data — your users, their accounts, their orders, everything anyone typed in since you launched.

Lovable is explicit about this. Their documentation says reverting restores only your project's code, that your database stays exactly as it is, and that reverting therefore cannot undo data changes made after that version.¹

That sentence is good news and bad news at once. The good news: nobody who signed up in the last three hours disappears. Their orders are still there. For most broken deploys, you genuinely lose nothing.

The bad news: if what broke was the shape of your data — a column removed, a table renamed, records wiped — putting the code back does not bring any of it back. That is a different job, further down this page.

Replit is the exception worth knowing about. Its App History snapshots code and data together. Neon, which builds the underlying branching, makes the point directly: if your schema changed or data was deleted, restoring just the code won't give you a working app.² Going back there is more complete — which also means it can undo data you wanted to keep.

How do I find the last version that worked?

Work out when it broke, not what broke. Every one of these tools keeps a timestamped list of versions, and the timestamp is the only thing you need right now.

In Lovable it's the History toggle in the top bar, or the menu next to the message input. In Replit it's the history view spanning every Agent session and every deployment. On Vercel it's the list of deployments on your project overview. Scroll to just before the change you regret.

Then look at it before you restore it. Lovable lets you open any version in a snapshot view and click around without changing anything, with a "Back to latest" button to get out.¹ Replit lets you build a previous checkpoint into a temporary environment and use it.

RapidDev's guide makes the case plainly: the issue sometimes started earlier than you think, and you may need to go back further.³ That is the real risk here — not going back too far, but not going back far enough, restoring something that was already quietly broken, and ending up with two problems and no way to tell them apart.

Where is the button, and what happens when I press it?

1. 1
   Lovable: Restore

   Press Restore on the version you just previewed. If the button is greyed out, that isn't a fault — it means the project is mid-task, and you wait for it to finish.
2. 2
   Replit: deployment history

   Hover over a previous deployment, open the actions menu, confirm. Replit describes it as restoring a previous successful deployment in one click; the build already exists, so it just points traffic back at it.⁴
3. 3
   Replit: check the keys it shows you

   It surfaces the differences in secrets — the passwords and keys your app needs — between the current version and the one you're going back to, so you can pick the right values rather than silently shipping the old ones.⁴
4. 4
   Vercel: Instant Rollback

   It's on the Production Deployment tile on your project overview, described as a way to quickly revert to a previous production deployment after breaking changes or bugs. The live address simply starts pointing somewhere else.⁵
5. 5
   Check your plan before you rely on it

   Vercel's docs say Pro and Enterprise teams can go back to any deployment that was previously live, while Hobby accounts can only go back to the immediately previous one.⁵ If you deployed three times this morning trying to fix it, you can only step back one.

What does a rollback quietly not fix?

Three things, and they are where a rollback that "didn't work" usually went wrong. All three are documented by Vercel, and the same shape of problem exists wherever settings live outside your code.

First, your settings don't come back. Vercel's documentation says the configuration used for a rolled-back deployment may become stale, and that changes you made to environment variables in project settings won't be applied.⁵ Those are your keys and connection strings. If part of the break was changing one, you change it back by hand.

Second, scheduled jobs go back with it. Anything set to run on a timer — a nightly email, a cleanup task — reverts to the state of the deployment you rolled back to.⁵ A job you added in the version you're undoing stops existing.

Third, your live address stops updating itself. Vercel turns off auto-assignment of production domains after a rollback.⁵ People lose an afternoon here: they fix the bug, deploy, refresh, see the broken version, assume the fix failed. It didn't. The site is pinned, and you have to point it forward deliberately.

What if it was the data that broke?

Different problem, harder problem. If a change deleted records or dropped a column, no code rollback helps — you need a copy of the database from before, and whether you have one depends on what you're paying.

Point-in-Time Recovery — a paid add-on that keeps a running record so you can restore to a moment rather than to yesterday — is what Supabase recommends when a day's worth of data matters, with restore granularity down to seconds. It lives in the Point in Time settings in the dashboard, with a date and time picker.⁷

Restoring is not instant either. Supabase's troubleshooting note says restore time depends heavily on how much has been written since the last full backup, not just the size of the database.⁸ Plan for the app being down while it happens.

This is not hypothetical. On Replit's community forum, someone described asking the Agent to add something to the database and having it wipe the existing one — unrecoverable, a new one created in its place, weeks of work gone.⁹ That thread is a request for exactly the capability Replit later built.

What should I change so this hurts less next time?

Bookmark your good versions. Lovable's history panel has a Bookmarks tab alongside the full list,¹ and a bookmarked version is one you find in ten seconds instead of scrolling through forty entries at 11pm.

Turn on database backups if you don't have them. If nothing has broken yet and you just realised you have no copy of your data, this is the ten minutes of your week that matters most.

And ship one change at a time. Not because it's tidy — because when one change goes out and something breaks, you already know what broke it. When six go out together, going back means throwing away five things that were fine.

Don't change any code yet. List every file you modified in your last three changes, grouped by change, with a one-line summary of what each change was for. Then tell me which single change is most likely to have caused this symptom: [describe what your users are seeing]. I want to decide whether to revert one change or all three before you touch anything.

What to do in the next ten minutes

If it's broken right now: find the last good version, preview it, restore it, then check your keys and settings, then check whether your live address is pinned. That's the whole sequence.

Later today, when your hands are steady, bookmark the version you just restored to and confirm your database backups exist. Lovable's docs end on a genuinely calming note: nothing gets lost along the way, because changes made after the point you went back to stay in the chat and can be reapplied.¹