Where Does Docmost Store Data?
Where Docmost keeps uploads inside its container, which named volumes persist them, and what lives in Postgres instead.
Last updated
A self-hosted Docmost splits its data three ways. Uploaded attachments, avatars, and space icons land in /app/data/storage inside the app container. The Postgres database in db_data holds all application content, and Redis keeps queue and cache state you can afford to rebuild.
The compose file persists storage through a named volume called docmost, so the files survive container updates. Prefer a host folder instead and you can bind mount any path onto /app/data/storage. Either way, back up the volume together with a database dump, since neither half restores a workspace alone.
Where Docmost stores this, by platform
/app/data/storage
Container path for attachments, avatars, and icons, arranged per workspace with numeric IDs. The compose file maps the docmost named volume here. Postgres data sits in db_data and Redis in redis_data, so include a pg_dump in every backup. S3 variables can replace this volume entirely.
Frequently asked questions
how do I back up a self-hosted Docmost
Back up the docmost named volume for files plus a pg_dump of the db_data volume for everything else. Redis holds only queue and cache state, so it can be rebuilt. Bind mounts need matching UID and GID or the app fails to write.
can Docmost store files in S3 instead
Set the S3 compatible storage variables and the local volume becomes unnecessary for attachments. Existing files in /app/data/storage must be uploaded to the bucket during migration. The database and Redis volumes stay exactly as they are.
why does Docmost fail to write uploads
The app runs as a fixed user inside the container, so a host directory owned by someone else gets permission denied. Either chown the host path to the container user or switch to named volumes, which sidestep the ownership problem entirely.
Notice an outdated path? Let us know.