What persists between deploys

Every deploy on the versioned strategy replaces the whole application directory. Anything written at runtime is gone unless it lives somewhere else, and that somewhere is /mnt/data/website/shared.

Handled for you

Three of these are done by the Webslice provider as the application boots, with nothing to configure. It happens whenever the WEBSLICE environment variable is set, which the platform does for you.

• Form submissions, so entries stay readable in the Control Panel after a deploy.
• Logs, so you can look back past the last release.
• The generated image cache, so resized images are not rebuilt from scratch every time you deploy.

Uploaded assets take one extra step, which .webslice/build.sh does. Assets committed to the repository are copied into shared storage on every build, then public/assets is replaced with a symlink to it. Both sources end up in the same place: the repository stays authoritative for anything tracked, and uploads made in the Control Panel are left alone.

The reason it cannot all happen in the provider is timing. By the time the application boots, committed assets are already sitting in the deploy directory, and putting a symlink over them would hide every one. Seeding has to happen during the build, before anything runs.

The application key is the other thing the build takes care of. If you have not set APP_KEY in the Console, the first deploy generates one and writes it to shared storage, and every deploy after that reuses the file. Without somewhere to keep it, a fresh key would be generated each time, rotating cookie and session encryption and logging everyone out of the Control Panel on every deploy.

If you add a database

Statamic is flat file and needs no database at all, so the simplest setup is to keep it that way. If you do need one, link a managed database in the Console rather than reaching for SQLite: the platform serves your files from network storage shared between instances, and SQLite's file locking behaves badly on it.