How to migrate n8n to a new server?

The short version: migrating n8n to a new server means moving your data folder (this contains all your workflows, credentials, and executions) and making sure the environment variables and database settings on the new server are the same as on the old one. If you copy the data folder and keep the same config, the new server will start exactly where the old one left off.

 

What you actually need to move

 

In a real production setup, n8n stores everything important in two places:

• The database – stores workflows, credentials (encrypted), executions, users. This is either SQLite (default, file-based) or Postgres/MySQL.
• The n8n data folder – stores encryption key, SQLite file (if used), binary data, and some run-time files.

If you move both of these properly, the new server becomes an identical copy of the old one.

 

Step-by-step: safest and cleanest way to migrate

 

This process assumes you're running n8n in Docker, which is how most production setups are deployed. If you're not using Docker, the logic is the same — you still copy the data and use the same environment variables — just the commands will differ.

• Stop n8n on the old server. This freezes the data so no execution changes mid‑transfer.

docker stop n8n

• Copy the n8n data folder. This is whatever folder you mounted into /home/node/.n8n inside the container.

// Example if your data is stored at /var/n8n on old server:
scp -r user@old-server:/var/n8n /var/n8n

• If using SQLite: The SQLite file lives inside that same data folder. Copying the folder automatically brings the database with it.
• If using Postgres/MySQL: Dump the DB and restore it on the new server.

// Postgres example
pg_dump -U n8n n8n > n8n_dump.sql
scp n8n_dump.sql user@new-server:/tmp/

// On the new server
psql -U n8n n8n < /tmp/n8n_dump.sql

• Recreate the same environment variables on the new server. This is critical. Especially N8N_ENCRYPTION_KEY. Without the same key your credentials will appear corrupted.

Example docker-compose with the same variables:

version: '3.8'
services:
  n8n:
    image: n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}  // MUST be identical
      - DB_TYPE=postgres
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - /var/n8n:/home/node/.n8n

• Start n8n on the new server.

docker compose up -d

• Test webhooks. If the domain or IP changed, update inbound webhook URLs because external systems won’t know about your new address.

 

Important details that matter in real production

 

• Encryption key must match. Credentials rely on it. If wrong, workflows will load but auth will break.
• Webhook URLs depend on domain. n8n doesn't magically redirect. If domain changes, you must update every external service calling your webhook (Stripe, Slack, etc.).
• If using execution history, large SQLite files can be slow to copy. Some teams clear executions before migrating.
• If using n8n Cloud, migration has to be done through export/import, because Cloud doesn’t expose the data folder.
• If using external Postgres, migration is easier — everything stays in the DB and you just point the new server to the same database.

 

Simple mental model

 

Think of n8n as two pieces: the brain (database) and the personal diary (data folder). Move both together. Start n8n with the same secrets. It wakes up exactly where it left off.

 

Quick checklist (to avoid disasters)

 

• Did you copy the n8n data folder?
• Did you migrate or reconnect the database?
• Did you keep the same N8N_ENCRYPTION_KEY?
• Did you restart webhooks if the domain changed?

If all 4 are yes, your migration will work.