Update fails to setup screen, even after downgrading. Suspected DB corruption

Questions
1

Hi community,

I’m facing a critical issue while trying to update my n8n instance and would appreciate any insights.

My Environment:

  • n8n Version: 1.102.4

  • Deployment Method: Docker Compose

  • Operating System: Ubuntu 22.04 on a DigitalOcean Droplet

  • Database: Default SQLite

My goal is to update to the latest n8n version. My instance is running perfectly fine on version 1.102.4.

Here is my docker-compose.yml file:

services:
n8n_propietario:
image: n8nio/n8n
restart: always
environment:
- GENERIC_TIMEZONE=America/Mexico_City
volumes:
- n8n_propietario_data:/home/node/.n8n
networks:
- n8n-network

… (other services like NPM are also in the file)

networks:
n8n-network:
driver: bridge
volumes:
n8n_propietario_data:

The Problem & Steps Taken:

  1. My instance was working perfectly on 1.102.4.

  2. I ran docker compose pull and then docker compose up -d to update to the latest version.

  3. After this, accessing my n8n URL showed the “Set up owner account” screen. All my workflows and credentials were gone.

  4. Here is the crucial diagnostic step: To troubleshoot, I edited my docker-compose.yml to force the old, working version again (image: n8nio/n8n:1.102.4) and restarted the container.

  5. The Result: The setup screen persisted. Even the original n8n version could no longer read its data after the failed update attempt.

This leads me to believe that the update process triggered a migration on the database.sqlite file that failed and left the file in a permanently corrupted state. My only way to get back to a working system is by restoring a full server snapshot from my hosting provider.

My Question:

Given that my database works fine in daily use but seems to fail catastrophically during the update’s migration process, is there any known method to “prepare”, “check”, or “fix” a SQLite database before attempting the update to prevent this?

Has anyone else experienced this, and is there a recovery path I’m missing, other than manually exporting/importing all my workflows to a fresh installation?

Thanks in advance.

2

Hey @Gerbor, is this still an issue for you or you managed to work around it? If it persists, have you tried exporting your workflows and credentials before updating, then importing them back in? Check the steps:

Export/Import workflows and credentials

Exporting from Your Container

To export workflows and credentials from your running Docker container, use these commands:​

Export all workflows:

docker exec -u node n8n_propietario n8n export:workflow --all --output=/home/node/.n8n/backups

Export all credentials:

docker exec -u node n8n_propietario n8n export:credentials --all --output=/home/node/.n8n/backups

The key is to use /home/node/.n8n/ as your output path since that’s where your Docker volume is mounted and the node user has write permissions.​

Accessing Exported Files

Since you’re using a Docker volume (n8n_propietario_data), you can access the exported files by copying them from the container to your host:

docker cp n8n_propietario:/home/node/.n8n/backups ./n8n-backups

Importing to a Fresh Instance

If you need to restore to a fresh n8n installation after a failed migration:​

Import workflows:

docker exec -u node n8n_propietario n8n import:workflow --input=/home/node/.n8n/backups/workflows.json

Import credentials:

docker exec -u node n8n_propietario n8n import:credentials --input=/home/node/.n8n/backups/credentials.json

Critical: Encryption Key Preservation

Your credentials are encrypted with an N8N_ENCRYPTION_KEY that’s auto-generated on first launch. You must preserve this key or your credentials will be unreadable after restoration.​

To retrieve your current encryption key:

docker exec n8n_propietario cat /home/node/.n8n/config

Add this key to your docker-compose.yml environment section to ensure it persists across container recreations:​

environment: - GENERIC_TIMEZONE=America/Mexico_City - N8N_ENCRYPTION_KEY=your_key_here

Preventing Future Migration Failures

Your specific issue suggests SQLite database corruption during migration. To prevent this in the future:​

  1. Always export workflows and credentials before updating​

  2. Back up the entire Docker volume before updates:

    docker run --rm -v n8n_propietario_data:/data -v $(pwd):/backup ubuntu tar czf /backup/n8n-backup.tar.gz /data

  3. Test updates on a copy of your data first by duplicating your volume​

  4. Consider migrating to PostgreSQL instead of SQLite for better reliability with larger datasets​

3

Thanks krisn0x. Yes, I always do that to back up before updating. But it shouldn’t be like that; it should be a clean install. I couldn’t solve that problem, so I did a clean install, and now I can update without any issues.