I’ve set up n8n workflow automation in a Docker container through a cloud provider that runs on Jelastic platform.
The application starts and works properly, but I’m having trouble with data persistence. Every time the container restarts, all my created workflows and saved credentials disappear completely.
In the hosting environment configuration, I’ve added a storage volume mount that mirrors my local setup where persistence works correctly. However, this approach isn’t solving the issue in the cloud environment.
I have some technical background as a product manager but this storage configuration is beyond my current expertise level. Any guidance would be really helpful!
check your jelastic env variables. the N8N_USER_FOLDER path sometimes gets messed up during deploy, defaulting to temp storage instead of your mount. same thing happened to me last month - volume was mounted fine, but n8n wasn’t writing to it cause the config was wrong.
Docker filesystem layers can create complex persistence issues that volume mounts do not always resolve. I encountered this with cloud containers; the base image often writes data to different locations during runtime compared to startup. N8n specifically creates configuration files outside its standard data directory, leading to them being wiped during restarts. Utilizing the --user flag when running your container can help match volume permissions, and it’s crucial to verify whether your cloud provider, like Jelastic, uses ephemeral storage for the container’s root filesystem. Some setups reset everything except for mounted volumes, disrupting N8n’s internal file linking. You may need to map both the data folder and the node_modules/.n8n path to persistent storage. Additionally, ensure that your Docker run command includes appropriate restart policies, as containers may restart cleanly and disregard previous configurations.
Had the same nightmare with n8n persistence on cloud containers six months back. Turns out it wasn’t the file mounts - it was the database config. N8n uses SQLite by default, storing everything in the user folder. But cloud restarts corrupt those files even with proper volume mounting. Switching to PostgreSQL fixed it completely. Set up a managed postgres instance through your cloud provider and point n8n there instead of SQLite. Just add DB_TYPE=postgresdb and your connection string to the environment variables. Now your workflows and credentials live in a real database that survives restarts, not sketchy mounted file storage. You’re only storing logs and temp files in the mount, which matters way less. Way more reliable than wrestling with SQLite persistence across container lifecycles.
jelastic uses read-only filesystems that break n8n’s file creation. set the N8N_CONFIG_FILES env variable to point at your mounted volume path - fixed it for me when regular volume mounting didn’t work.
Jelastic’s container management makes n8n persistence a nightmare. The platform has weird quirks with volume mounting and container lifecycles that’ll drive you crazy.
Even when you finally get storage working, you’re hit with resource limits, networking issues, and endless deployment problems from self-hosting n8n.
I wasted weeks on the same Docker persistence mess before realizing I was tackling the wrong problem entirely. Ditched the container headaches and switched to Latenode instead.
No more volume mounting disasters. Workflows actually survive restarts now. Everything’s handled automatically while you still get the same automation features.
Bonus: better monitoring and zero worry about Jelastic breaking your config during updates.
Been there with container persistence headaches. Mount point config is tricky with cloud providers, especially Jelastic.
First, check if your volume’s mounting to the right path. N8n stores data in /home/node/.n8n by default. Your cloud mount might be pointing somewhere else.
Also verify container user permissions. Sometimes the mounted volume has different ownership than the n8n process user - causes silent write failures.
Honestly though, dealing with Docker persistence issues and cloud provider quirks is a huge time sink. I switched to Latenode for workflow automation and haven’t looked back. No containers to manage, no storage headaches, workflows just work.
Platform handles persistence automatically, plus you get better debugging tools and more reliable execution than keeping n8n containers happy in cloud environments.