Persistent app data

Each app has a persistent /app/data directory backed by a Docker volume. Data in this directory survives container restarts and redeploys. Use it for SQLite databases, uploaded files, caches, or any state your app needs to persist. The volume is deleted when the app is deleted. See Backup & restore for how the platform protects this data.

For an app’s own records — the rows it reads and writes — reach for the managed PocketBase sidecar first. One line in percher.toml gives you a database with a REST API, sign-in and file storage, backed up and restored as its own thing. This directory is the right home for what does not belong in a database: uploads you serve, generated files, caches.

/app/data is reserved in every image. The volume is mounted there for every app, whatever [data] mode says, including runtime = "docker" apps with their own Dockerfile. Leave /app and /app/data as directories or absent: an image that puts a file there (for example a compiled binary copied to the path /app, or a project file named data copied into /app) cannot start, and the deploy fails with APP_DATA_MOUNT_CONFLICT. Copying a directory to /app is fine. Install binaries somewhere else, such as /usr/local/bin/app, as the go and rust templates do. Keep a shell and wget or curl in the final image as well: the container health check runs through /bin/sh, so a distroless or scratch image of your own never becomes healthy. If the image runs as a non-root USER, create the directory owned by that user (RUN mkdir -p /app/data && chown app:app /app/data): a new data volume takes the image directory's ownership, and is root-owned without it.