This error usually means n8n is trying to create its data directory, but the mounted volume lacks the right permissions for the `node` user inside the container. Since your mount path is `/home/node/data`, n8n tries to create: `/home/node/data/.n8n` It cannot write there, causing the deployment to crash with `EACCES: permission denied`. Here are a few things to check: 1\. Ensure the mounted volume is writable by the container user. 2\. In many setups, n8n expects the data folder to be owned by the `node` user. 3\. You can also try mounting directly to the default n8n data path instead of a parent folder, depending on your platform. Regarding your second question: if your main goal is to avoid losing workflows and execution data on redeployment, then yes, you need persistence. _A_ \*volume mount\*\* is sufficient if you are using the default SQLite database and want simple persistence. \* **PostgreSQL** is better for a more reliable production setup, especially long term. So: _If you want the simplest solution on the Hobby plan, use a_ \*persistent volume\*\* and ensure permissions are correct. \* If your platform easily supports PostgreSQL, that is usually the better option for durability and scaling, but it's not strictly required just to keep workflows after redeployment. In short: you do not need PostgreSQL just to prevent data loss, but you do need either a working persistent volume or an external database. Right now, your issue seems to be a **volume permission problem**, not an n8n bug.

Hello **fuad47,** your issue is that the n8n image runs as a non-root user but railway mounts volumes as root so the node user can't write to it. just add this env variable to your n8n service:` RAILWAY_RUN_UID=0` then redeploy and it should work Hope this help you :)