A feature that saves files to disk works perfectly until the next deploy, and then the files are gone. The code did nothing wrong. Most hosting platforms give an app an ephemeral filesystem: a scratch area that starts fresh from the deployed image each time the instance starts. Anything written there lasts only as long as that instance.
Platform behaviour checked in November 2026.
Why the disk forgets
Platforms reset the filesystem on purpose. Every start is then identical, any instance can be replaced at any moment, and several instances can run the same image without stepping on each other.
The documentation is explicit. Render says its services have an ephemeral filesystem by default and that changes to local files are lost every time the service redeploys or restarts. Heroku says each dyno gets its own ephemeral filesystem and that written files are discarded the moment the dyno stops or restarts, including automatic restarts.
It happens more often than deploys
Restarts are not only the ones you trigger. Heroku cycles every dyno once every 24 hours, plus up to 216 random minutes, so files written to a dyno last a day at most. Platforms also restart apps after crashes, memory kills, scaling events and maintenance. If files vanish at odd times, check the event log for restarts; the exit code 137 page covers the most common unplanned one.
Option 1: a persistent volume
Some platforms let you attach a disk that outlives restarts. Render offers persistent disks on paid services; Fly.io calls them volumes. A volume fits data that has to stay on a local file system, such as an embedded database or a search index.
Volumes have limits worth knowing before you rely on one. A volume usually belongs to one instance in one region, so scaling to several instances needs a different design, and backups are your job. On free plans, volumes are generally not available.
Option 2: object storage
For uploads, generated documents and anything users download, object storage is the usual answer. The app writes the file to an S3-compatible bucket, stores only the object's key in the database, and serves the file from the bucket or through a short-lived link. Files then survive deploys, restarts and any number of instances.
In Java, the AWS SDK and most S3-compatible providers' clients handle this in a few lines. Keep the bucket name and credentials in environment variables, like the database settings on the database connection page.
Option 3: the database
Small files that belong to a record, such as an avatar or a short attachment, can also live in the database itself. It keeps everything in one backup, but makes the database grow quickly, so it suits small and few files better than media libraries.
What may stay on the local disk
The ephemeral filesystem is still useful for anything that can be rebuilt: temporary files during a request, caches, and files unpacked at startup. If losing the file only costs a little time, local disk is fine. If losing it loses data, it needs one of the options above.
Find every place the app writes to disk
Files rarely disappear from the one feature you are thinking of. Check the whole app for local writes before you move to a volume or a bucket:
- An embedded database in file mode. An H2 or SQLite database stored in a file, common in tutorials and prototypes, is reset with every restart. Move the data to a managed database, as on the database connection page.
- Uploads saved to a folder. A path such as
uploads/inside the app directory lives on the ephemeral disk. - Logs written to files. Platforms collect what the app prints to standard output; a log file on the instance is lost with it and fills the disk in the meantime. Log to the console instead.
- Generated reports and exports. Write them to object storage and hand out a link, rather than keeping them until someone downloads them.
Search the code for FileOutputStream, Files.write and new File( to find places you may have forgotten. Every hit is either temporary, and fine, or data, and needs one of the options above.
Next steps
Check what each plan offers before you design around storage: the hosting comparison lists the plans we track. If files disappear together with other odd behaviour, start from works locally, not online.
Sources
