We’ve said it before: never use the root filesystem from your application image to persist state. At best, it’s ephemeral. After a machine restart or an update, there’s no guarantee your data will still be there.
We’ve seen users learn this the hard way, storing important data on the root filesystem only to have it vanish at the worst possible moment.
The root filesystem isn’t backed up. It should never be trusted to hold valuable data. That part isn’t changing. But we get it: starting from a completely clean slate can also mean losing caches that take time to rebuild.
That’s where persist_rootfs comes in. It’s a machine knob that has actually been around for more than a year, but it wasn’t exposed by the API until now. It accepts three values:
never: The root filesystem is ephemeral. It will not persist across restarts or updates. (Default.)restart: The root filesystem persists across restarts, but not across updates.always: The root filesystem persists across both restarts and updates.
To use it in fly.toml, add it under the [[vm]] section:
[[vm]]
size = 'shared-cpu-1x'
persist_rootfs = "restart"
See the full docs for the vm section.
Or, if you’re using the Machines API directly, set it under the machine’s guest config:
...
"guest": {
"cpus": 2,
"memory_mb": 1024,
"persist_rootfs": "always"
},
...
Full reference is in machine config object docs.
Even with persistence enabled, the root filesystem is not a reliable place for critical data, it is not the most performant block device either. It may still be wiped if required for maintenance or recovery. Use a Fly Volume if you need durability and performance.
Happy persisting! 
Now I can remove a wonky hack I was using for temporary but essential data.