Moving N8N Instance to new VPS

Questions
1

Hi,

Using N8N 2.1.4 CE and backup with n8n export and n8n import (CLI) to new VPS from scratch (needed For DR process). Have over 250 workflows, 5 credentials, 4 webhooks. Now with version control I am able to import it to new VPS but need to replace exported wf with “Atived: false” and “activeVersionID = null”. The field activeVersionId comes equal to versionID but UUID does not exist on workflow_history. Why? During de import process we have no records in table workflow_history until safe it with dummy changes then able to active and then publish it. But with over 250 workflows this process should be automated. I do not want to backup/restore n8n postgress database, need a process from scracth just having backups and do not want to use any api/workflow process - too slow. I fell with some postgres script will solve it, for every record in workflow_entity then create/update record in workflow_history and update versionId and activeVersionId and so far. But is out of my scope for now. Any suggestions?
Best wishes for all.

Information on your n8n setup

  • n8n version: 2.1.4
  • Database (default: SQLite): Postgres 17
  • n8n EXECUTIONS_PROCESS setting (default: own, main): main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Ubuntu 24.03.
3

yeah the CLI import/export is solid but it doesn’t handle the workflow history table automatically. if you’re trying to avoid the API/workflow route, honestly a postgres script is probably your best bet - you’d need to insert records into `workflow_history` matching each workflow in `workflow_entity`, then update the `versionId` and `activeVersionId` to reference those new history entries. something like this pattern:

```sql

-- for each workflow, insert history record and update references

INSERT INTO workflow_history (workflowId, versionId, …)

SELECT id, gen_random_uuid(), … FROM workflow_entity WHERE …;

UPDATE workflow_entity SET activeVersionId = versionId WHERE …;

```

alternatively if you’re comfortable with a one-time thing, you could write a quick node script that connects to postgres directly and does this programmatically - faster than clicking through 250 workflows but more controlled than raw SQL. the workflow history table structure is pretty straightforward if you inspect it, just needs the right foreign keys set up.

lmk if you want help with the actual script structure