Hey @MCheseldm
What you’re describing usually happens when n8n’s data directory inside Docker isn’t stored in a persistent volume. When Docker updates the container especially if you were running the nightly build it can start up a fresh container that doesn’t link to your previous data folder. That makes it look like your workflows and execution history have reverted to an older version, because n8n simply started from a clean internal directory.
To confirm this, check your Docker setup and make sure that your n8n container is saving data outside the container itself. The standard setup keeps all workflow data in the /home/node/.n8n directory. If that path wasn’t mapped to a local folder on your server or bound to a named Docker volume, all of your data would live inside the container which gets reset whenever the image updates.
You can also look for existing local data by checking the folder where Docker stores your volumes. If you find your old data directory there, you can manually recover your workflows by importing the JSON files back into n8n from the settings menu. If you were using an external database such as PostgreSQL or MySQL, double-check that your environment variables are still pointing to the correct database, because a mismatch can also make n8n appear to “lose” data.
Going forward, the best practice is to stop using the nightly image since those versions change frequently and can break schema compatibility. Instead, use a stable tagged version, for example the latest release, and always make sure that the container’s data folder is mapped to a local directory on your server. That way, even if you rebuild or update the container, your workflows, executions, and credentials remain intact.
You’re already on the right track with your plan to export workflows regularly. Automating a nightly export to JSON files is an excellent safeguard. You can then sync those files to a Git repository or cloud storage service, so even if something goes wrong, you can restore your entire setup in minutes.
If the data volume was replaced entirely and you don’t have backups, recovery unfortunately won’t be possible because n8n stores everything inside that directory. But once you have persistent storage and version-locked images, this problem won’t happen again.
In summary, what likely happened is that your nightly container updated and didn’t have a persistent data mount, causing n8n to revert to an empty state. Switching to a stable build, mapping the data directory to a local folder, and keeping automated exports will prevent any future data loss.