After the Dify Docker Compose installation was brought down, when brought back up, there were no previous records.

[qjwqw]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

After the Dify Docker Compose installation was brought down, when brought back up, there were no previous records.Knowledge base, plugins, and user information were lost.

[dosubot[bot]]

The most common reason for losing all records after restarting Dify with Docker Compose is a problem with data persistence—usually the database or storage volumes were not mapped to persistent host directories, or those directories were deleted, empty, or inaccessible. Even if your docker-compose.yaml looks correct, double-check that your host directories (like ./volumes/db/data for PostgreSQL, ./volumes/app/storage for user files, and similar for plugins and vector stores) actually contain your data and weren't overwritten or recreated during the restart. If these directories are empty or missing, Dify will initialize a new, empty database, which matches your symptoms. See the official volume mappings in the docker-compose.yaml.

Other frequent causes include running docker compose down --volumes (which deletes named volumes), not marking database volumes as external (so they get deleted on down), disk permission issues (especially on Docker Desktop), or a change in the ENCRYPTION_SECRET or SECRET_KEY environment variable, which can make existing data unreadable and force a new setup. Running Docker Compose with sudo (e.g., sudo docker compose up -d) can resolve permission issues and restore access to your data if it appears lost after restart reference.

For production, use PostgreSQL instead of SQLite, as SQLite is file-based and unreliable in Docker unless the database file is mounted to a persistent volume. If you must use SQLite, ensure your Compose file mounts a persistent volume for the database file and implement regular backups reference.

If your database files are present but you still can't log in or see your data, check for authentication/configuration issues like mismatched CORS or API URL environment variables, token expiration, or clock skew between containers. These can cause symptoms similar to data loss even if the database is intact reference.

To prevent future data loss: always back up your volumes, mark critical volumes as external in your Compose file, keep your .env file unchanged, and use appropriate permissions when starting Docker Compose.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}