Replit app lost data after publishing: causes and fixes

Why a Replit app shows no data after publishing

Every Replit App has two databases. Replit's docs describe the development database as the one where you and Agent experiment and build, holding test data, and the production database as the one that stores the live data powering your published app. The Project Editor keeps using development after you publish. The published app uses production. They are two separate PostgreSQL databases, and nothing moves between them unless you ask.

Two rules from the docs decide most cases. First, publishing applies the structural changes Agent made in development, new tables and columns, to production, but it does not copy rows. Second, Agent is not able to modify the production database at all. So when the live app looks empty, the data is usually sitting in development, where the preview showed it, and production simply never had it.

There is a reason the two are kept apart. In July 2025 a Replit agent deleted a live database during SaaStr founder Jason Lemkin's public build, and The Register reported Replit's CEO calling it unacceptable and rolling out automatic dev/prod database separation in response. The separation stops that. It also creates the confusion this post is about.

Which database your published Replit app is reading

Before fixing anything, find out where the data is. Fifteen minutes here saves a restore you didn't need.

1. Open the Database tool in the workspace and look for two tabs or a selector: development and production. If there is no production entry, the published app has nothing to read. A forum thread from October 2025 reported exactly that: a production database that was never created after publishing, which another member fixed by publishing through the advanced settings rather than republishing.
2. Compare the two.Select production, open My Data, and check the tables your app needs. Then do the same in development. If development has your records and production doesn't, read the next two sections.
3. Check the connection string the live app uses. Replit's migration guide says to open Publishing, then Adjust Settings, then Secrets, and find DATABASE_URL. Compare it to the one in the Database tool's settings. The docs say a URL containing neon.tech is a legacy Neon database and one containing heliumis Replit's current infrastructure. Two different hosts means two different databases, which is normal; the question is whether the production one has data.
4. Read the first lines of the deployment log.In a forum post from April 2026, a founder lost most of a day because Agent assumed one database served both environments and kept writing to development. The startup log line showing the runtime pool was what proved development was on Helium and production on Neon. Agent's claims about what is in the database are guesses; the log and the Database tool are facts.

One more check from Replit's troubleshooting docs: secrets you set in the Project Editor do not carry over to the published app. If the live app shows "database connection failed" rather than empty tables, add the production secrets in the Publishing pane and publish again. That is a missing secret, not lost data.

Replit production database empty after the first publish

This is cause one, and the most common. Replit's docs say that on current infrastructure the production database is created at publish time, provided development contains data, and on legacy Neon databases you turn on Create production database in the publish settings. Either way the new database starts with your structure and no rows, unless you also turned on Set up your production database with your current development data. Most founders never saw that toggle.

The fix

1. Decide whether development data is fit for real users. The docs warn it can include test accounts, sample records, and incomplete content. Delete the junk in development first.
2. Publish again with the copy option on. The migration guide says publishing then sets DATABASE_URL to the new production database automatically.
3. Only do this if production is empty or disposable. The same guide states that copying development data to production overwrites any existing production data. If real customers have already signed up on the live app, do not copy; move the missing rows by hand or with a script instead.
4. Open the live app and check the records are there.

If the copy toggle isn't offered, or publishing says it succeeded and production still doesn't appear, try the forum workaround of publishing from the advanced settings, then contact Replit support with the deployment time. Don't let Agent "fix" it: it can't reach production, so it will create tables in development and tell you it's done. If you'd rather hand this check to someone, what access to give a developer covers Replit apps too.

Data added in the editor doesn't show in the live app

Cause two looks like cause one but happens after launch. You added products, pages, or users while working with Agent, published, and the live app doesn't have them. A February 2026 forum thread asked whether development data gets pushed to production on deploy; the answer, matching the docs, was that data entered in development does not get copied into production automatically, and the first-publish copy is a one-time event. Production changes only through the live app or a direct edit.

The fix depends on how much data it is. For a handful of rows, Replit's docs describe editing production directly: open the Database tool, select the production database, open My Data, and toggle Edit. For more, export from development and import into production with the Postgres tools in the Shell, which the migration guide shows:

# Export just the table you need from development
pg_dump -Fc "$DATABASE_URL" -t products --no-owner --no-privileges -f products.dump

# Import into production (use the production URL from Publishing > Secrets)
pg_restore --no-owner --no-privileges -d "<production DATABASE_URL>" products.dump

For content you change often, this is the wrong setup. Build an admin page in the app so you edit production through the live app, as the docs intend, and keep development for building. An app where the founder edits data in the Agent chat will keep losing it.

Uploaded files disappear after publishing a Replit app

Cause three has nothing to do with the database. Replit's troubleshooting docs say the file system in published apps is not persistent and resets every time you publish, and that if uploaded files or generated data disappear after publishing, you should store them in a database or storage service instead of the app filesystem. Agent-built apps often save profile photos, PDFs, or CSV exports to an uploads/ folder on disk. Every publish wipes it. The database rows that point at those files survive, so you see broken images and missing downloads rather than empty tables.

The fix is App Storage, which Replit's docs describe as persistent cloud storage shared between the development and production environments of the same app, formerly called Object Storage. Ask Agent to move uploads to App Storage and save the object key in the database. The files already lost are gone unless the users still have them: there is no restore for the deployment disk. Re-request them, and fix it before the next publish.

Production data deleted by a rollback, a misclick, or the Agent

Cause four is real deletion, and it's rarer than people fear. Three ways it happens, and what Replit can restore for each.

A checkpoint rollback

Replit's docs say rollback restores the app to an earlier checkpoint and removes all changes made after that point, including code edits, but that by default rollbacks do not change your database. The development database is only included if you choose Database under Additional rollback options, and production is never touched by rollback. So a rollback can lose code and a feature, but not live customer data. If you rolled back too far, the docs say you can roll forward from the history view in the Agent tab, as long as you haven't made new changes since.

Deleting the production database

In a November 2025 forum post, a founder meant to delete production and replace it with development, clicked delete twice, and lost three weeks of data. Replit's docs say a removed database has a 7-day soft delete period during which it can be restored, with support's help, and after 7 days it is hard deleted and unrecoverable. If you removed it, write to Replit support today, not next week.

Point-in-time restore

For data that was overwritten or wiped inside a database that still exists, Replit's data recovery docs give the steps: open the Database tool, select the production database, go to Settings, expand Scheduled backups under Advanced, select View all backups, choose the restore point, type restore, and continue. Every plan starts with 7 days of history; Core keeps up to 7 and Pro and Enterprise up to 28, set in the database settings. One thing the docs stress: restoring the database doesn't restore your code, and rolling back code doesn't restore the database. To put both back to the same moment, restore the database, roll back to the matching checkpoint, and publish again.

Restores can fail. An October 2025 forum post described losing every record in the only database and the 7-day revert failing with a "Something is wrong" error. Try the restore, keep a screenshot, and open a support ticket in the same hour. The window is counted in days, and a ticket's reply time eats into it.

The Agent itself

Since the separation, Agent cannot modify production, so the SaaStr scenario of an agent dropping live tables shouldn't repeat on a current app. What Agent can still do is drop or rewrite development tables, which then arrive in production as structure changes at the next publish. The docs name the dangerous ones: removing columns the code still uses, changing data types, and adding required fields without defaults. The deployment preview the docs describe, a temporary isolated copy of production, exists to test those before real users see them.

Remixed Replit apps and the shared database shutdown

Cause five hits apps that were remixed or forked from another app. Under Replit's legacy system, the docs explain, remixing reused the same database and forking copied DATABASE_URL, so two apps shared one database and changes in one affected the other. Those shared legacy databases were shut down on June 8, 2026. Replit's migration guide says the affected apps are ones remixed from an app that had a database before January 9, 2026, and ones showing database connection errors after the upgrade.

The guide's check: get NEON_DATABASE_URL (or DATABASE_URL) from the source app's Database panel, then open Publishing, Adjust Settings, Secrets in the published app, and compare its DATABASE_URL. If they match, the live app was reading the other app's database. The fix is a full export and import:

# 1. Export the old database
pg_dump -Fc "<old database url>" --no-owner --no-privileges -f backup.dump

# 2. Delete the old DATABASE_URL secret, reopen the Database panel

# 3. Import into the current development database
pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges \
  --exit-on-error -d "$DATABASE_URL" backup.dump

# 4. Publish with "Create production database" and the copy option on

If the old database is already unreachable because of the shutdown, the guide says to contact Replit support. If users are still saving data, do the export in a short maintenance window so nothing lands between the dump and the publish.

Replit lost data: symptom, cause, and fix

How to stop a Replit app losing data again

Once the data is back, make the next scare boring. None of this needs code changes, and all of it comes from Replit's own docs.

The weekly dump matters most. Every restore above depends on Replit's window, Replit's support queue, or a restore that may fail. A file you hold is the only backup you control. The same rule applies to any vibe-coded app, which is why it sits on my vibe-coded app launch checklist.

When to move a Replit app's data to your own setup

Fix it yourself if it's a clear case above: an empty production database on first publish, uploads on disk, or a missing secret. Get a developer when customers have already lost orders or accounts, when the app has had several rounds of Agent edits and you can no longer say which table the live app trusts, or when you're relying on a 7-day window for data a business depends on. At that point the problem isn't one toggle; it's that nobody owns the data.

What a developer does is move the database somewhere with backups you control, with migrations that run the same way every deploy, and often move the app itself. I start with a Launch-Ready Reviewto find where the live data really is and what's unrecoverable, then a Production Sprint to fix it and set up backups and a safe deploy. What each costs is in the cost to fix a vibe-coded app, and the full service is vibe-coded app rescue.

The pattern is familiar. The Chat Company came to me as a buggy demo the founder had generated with AI tools; I kept about 20%, rewrote the rest, and launched in nine weeks for $20,000. It now serves 30+ businesses and handles 100K+ messages a day, which is not a workload you want sitting on a database with a 7-day history. On the social challenge app, an agency had left AI-generated code half-built with security, login, and payment problems; users stake real money, so wallets and payouts had to be right before launch. I reviewed the code, kept what was solid, rewrote the rest, and launched in eight weeks for $16,000. It now has 10,000 users and $40K staked, data nobody gets to lose.

Lovable apps have a similar move, written up in moving a Lovable app to your own hosting. If data loss is one worry among several, start with when a vibe-coded app needs a developer. Otherwise, send me the app's link and what the Database tool shows.