self hosting

n8n Docker Volume Persistence: Avoid Losing Workflows and Credentials

Persistent Docker storage is mandatory for self-hosted n8n because workflows, credentials, settings, and the default SQLite database live under the n8n user data directory.

Primary query: n8n docker volume persistence Intent: troubleshooting Applies to: self-hosted, Docker Opportunity: 97 Source-backed draft

Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.

Quick Answer

Persistent Docker storage is mandatory for self-hosted n8n because workflows, credentials, settings, and the default SQLite database live under the n8n user data directory.

Problem Pattern

The user recreated or updated a container and workflows, credentials, SQLite data, or community node packages disappeared.

Key Facts

Important path: /home/node/.n8n inside the official container.
Default SQLite file: ~/.n8n/database.sqlite for self-hosted SQLite setups.
Community nodes path: ~/.n8n/nodes for installed community packages.
Main risk: Recreating a container without the right volume can lose data.

Recommended Steps

Create a named Docker volume or host bind mount for n8n data.
Mount it to /home/node/.n8n in the n8n container.
If using community nodes, ensure ~/.n8n/nodes is also persistent.
Restart the container and create a test workflow.
Recreate the container and verify the workflow remains.

Verification

The same workflows appear after container recreation.
Credentials remain available after restart.
Community nodes still load after rebuilding the container.

Warnings

Container filesystem storage is not a backup strategy.
Back up both the n8n data directory and any external database.

Best For

Docker users who want workflows and credentials to survive container replacement.
Teams using the default SQLite database in a containerized setup.
Instances that install community nodes and need package files to persist.

Not For

Disposable one-command demos where losing data is acceptable.
Managed n8n Cloud deployments.
Users who have already moved all durable data into managed external services and documented that setup.

Common Mistakes

Mounting the wrong host directory or container path.
Backing up the Compose file but not the actual Docker volume.
Persisting workflows but forgetting community node packages.
Deleting a named volume during cleanup and losing SQLite data.

Examples

Named volume mount The important part is the target path inside the container.

volumes:
  n8n_data:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    volumes:
      - n8n_data:/home/node/.n8n

Persistence test Run this before trusting a new deployment.

1. Create a test workflow.
2. Restart the container.
3. Confirm the workflow still exists.
4. Recreate the container without deleting the volume.
5. Confirm credentials and community nodes still load.

FAQ

What data is at risk without a volume?

On a default self-hosted Docker setup, workflows, credentials metadata, settings, SQLite data, and community node files may depend on persistent user data.

Is a Docker volume a backup?

No. A volume helps persistence, but a backup must be copied elsewhere and tested with a restore.

Do I still need this if I use Postgres?

Yes. Postgres moves database persistence out of the container, but user data, encryption key handling, and community node files still need planning.

Sources

n8n Docker Installation Accessed 2026-05-07 n8n Community Nodes Troubleshooting Accessed 2026-05-07 n8n Supported Databases Accessed 2026-05-07