Uploaded files disappear after you redeploy on Replit? Fix it

Users upload profile photos or documents, everything works, and after your next publish the images are broken links. Nothing errored. This is how Replit deployments work: Replit's troubleshooting docs say the file system in published apps is not persistent and resets every time you publish. Autoscale instances also start and stop with traffic, so files on one instance's disk are not shared with the others. Anything that must last belongs in storage built for it.

Symptoms

• Uploaded images show as broken after a republish.
• Generated files (PDF invoices, exports) are missing a day later.
• Some users see a file and others get 404, depending on which instance answers.
• A local SQLite or JSON file used as a database loses data.

Likely causes

1. Uploads are written to a local folder with multer, fs.writeFile or Python open().
2. The app uses a local SQLite or JSON file for data.
3. Several Autoscale instances each have their own disk.
4. The database stores a local file path that no longer exists.

Step-by-step fix

1. Find every write to disk

Search the code for multer, diskStorage, writeFile, createWriteStream, uploads/ and .sqlite. Files written only to /tmp during a single request are fine; everything else needs to move.

2. Create an App Storage bucket

Open the App Storage tool in your workspace. Agent can provision a bucket and the client library for you. The same bucket is available to the published app.

3. Upload to the bucket, store the key

Keep the file in memory or in /tmp, upload it to the bucket, and save only a key such as avatars/USER_ID/FILE_ID.jpg plus metadata (owner, type, size) in your database.

# Python, Replit App Storage SDK
from replit.object_storage import Client
storage = Client()
storage.upload_from_bytes(f"avatars/{user_id}/{file_id}.jpg", data)
# later
data = storage.download_as_bytes(f"avatars/{user_id}/{file_id}.jpg")

4. Serve files through a route

Add a route like GET /files/:key that checks the user may see the file, then streams it from storage. This also keeps private documents private.

5. Replace local databases

If data lives in SQLite or JSON files, move it to the Postgres database. See Replit dev vs production database.

6. Clean up old references

List database rows that point to local paths. Mark them as missing so the UI asks for a new upload instead of showing broken images.

Copy-paste prompt for Replit Agent

Open a new Agent chat (a fresh chat keeps old attempts out of its context) and paste this:

Files uploaded in my published Replit app disappear after I republish. Please move file storage to Replit App Storage:
1. Find every place the code writes files to local disk (multer diskStorage, fs.writeFile, uploads/ folder, SQLite or JSON data files) and list them.
2. Set up an App Storage bucket and change uploads to store files there under keys like <type>/<userId>/<fileId>.<ext>.
3. Store only the key, owner, content type and size in the database.
4. Add a GET route that checks permissions and streams the file from storage.
5. Validate file type and size on upload.
Do not delete existing database rows; mark rows that point to missing local files instead.

How to verify the fix

• Upload a file on the live URL, republish, and confirm the file still loads.
• The App Storage pane shows the uploaded object under the expected key.
• A logged-out user, or another user, cannot open a private file's URL.

Uploads are also a common security gap. Check the file-related items in the Replit Agent security checklist.

FAQ

Is the Replit deployment filesystem persistent?

No. Replit's docs state that the file system in published apps is not persistent and resets every time you publish. Use a database for data and App Storage for files.

Can I recover files lost after a Replit redeploy?

Not from the published app, because its disk was replaced. If copies exist in the development workspace or with your users, upload them again to App Storage.

Should I store images in the database instead?

Store the file itself in object storage and keep the key and metadata in the database. Large binary data in Postgres makes backups and queries slower.