Where Does Self-Hosted Chatwoot Store Data?
Which named Docker volumes hold Chatwoot uploads, database, and cache, and what a full backup covers.
Last updated
A production Chatwoot stack persists three named volumes: storage for uploads, postgres for conversations, and redis for jobs and cache. The app itself reads /app/storage inside its container regardless of host layout. Older compose files used /data host paths that Mac Docker could not share.
Backups must cover all three volumes plus configuration, since each holds irreplaceable state. The database needs its prepare task on first boot before migrations make sense. Keep env files with the backup; credentials live there, not in the volumes.
Where Chatwoot stores this, by platform
/app/storage
Uploads volume mounted at /app/storage in rails and sidekiq containers. Postgres and redis volumes beside it hold conversations and job state. Back up all three plus compose and env. Older host-path mounts migrated to these named volumes.
Frequently asked questions
how do I back up self-hosted Chatwoot
Back up the storage, postgres, and redis named volumes together, plus the compose file and env. Uploads live in storage_data while conversations sit in postgres. Recent compose files use named volumes; older ones used host paths under /data.
how do I connect Chatwoot to external Postgres
Prepare the database with the documented rails prepare task on first setup, not plain migrate. Point the app at existing Postgres and Redis through env when using managed services. Keep all services on one network for the rails and sidekiq containers.
Chatwoot volumes fail on Mac, why
Check whether your compose file predates the named-volume migration: old files mount /data paths that break on Mac. Update to storage_data, postgres_data, and redis_data volumes. The app storage path inside containers stays /app/storage either way.
Notice an outdated path? Let us know.