Files and persistent storage
A deployment replaces the application filesystem with the files built for that version. Data written by the running app needs a persistent directory when it should survive that replacement.
Last updated
Use /tokay/data for new code, or mark an existing application directory as persistent.
Code resets while app owned data persists
Files included in the build are recreated on each deploy. This makes a deployment and rollback reproduce the version that was built.
Files under /tokay/data are different. They belong to the Service across deployments and restarts. Tokay also provides the path through TOKAY_DATA_DIR so the code can avoid hardcoding it.
A file written beside the source, such as ./uploads/photo.jpg, is temporary unless that directory is marked persistent.
Keep an existing application path
Open the Persistent Storage section in Service settings and add the directory the app already uses. Tokay also suggests write paths it detects in the code.
A newly attached persistent directory starts empty. If the build contains files at the same path, the empty persistent directory covers them on the next deployment. The confirmation explains this before the change is applied.
Detaching a directory stops mounting it but keeps its stored data. Deleting the data is a separate action. If important files already exist in a temporary path, rescue them before the current instance changes. See Service files.
Persistent data is protected outside the VM disk
Tokay replicates persistent directories away from the virtual machine's local disk. Periodic offsite snapshots provide another recovery point for severe failures or data that was deleted and later permanently purged.
Choose persistence based on the kind of file
User uploads, generated reports, and a SQLite database file need persistent storage. Caches and temporary files usually should reset with the release.
Project databases such as Postgres, MySQL, MongoDB, and Redis manage their own durable storage. See Databases.