Self-hosted n8n: backing up and restoring your PostgreSQL database without losing your credentials

A git backup of your workflow JSON protects your business logic. It protects neither your execution history nor — critically — the encrypted credentials (OpenAI API keys, OAuth tokens, Supabase passwords) living in your self-hosted n8n instance's PostgreSQL database. The day that disk fails without a database backup, you don't just lose data: you lose access to every connected account, and every credential has to be re-entered by hand. A landmark study conducted at Google on a population of over 100,000 hard drives in production measured annual failure rates that climb sharply past the first year of use, with wide variability by hardware age (Pinheiro, Weber & Barroso, 2007 — Google Scholar) — a useful reminder that the question isn't if a disk will fail, but when, and that backups aren't optional for a production instance.

What needs backing up (and what git doesn't cover)

A self-hosted n8n instance rests on three distinct pieces:

• Workflow definitions — the JSON for each automation. That's what our guide on versioning n8n workflows with git covers: a regular n8n export:workflow, committed to a repository.
• Execution history — useful for debugging and, if you follow our guide on GDPR audit trails with Supabase, potentially required for compliance reasons.
• Encrypted credentials — stored in the database, but only decryptable with the N8N_ENCRYPTION_KEY variable unique to your instance.

All three live in the PostgreSQL database (or SQLite in development, never recommended for production). Git protects the first; only a database backup protects the other two.

The encryption key: the most critical piece, and the most often neglected

N8N_ENCRYPTION_KEY is generated once, the first time the instance starts, and encrypts every credential you save. Without it, a restored PostgreSQL dump does give you back your workflows and history — but every API key, every OAuth token, turns into unreadable garbage. There's no way to recover it afterward if it wasn't backed up separately.

Good practice: store this key in a team password manager (not the same repository as your workflow git backups, not the same bucket as your SQL dumps). It's a secret just like the credentials it protects — the same principle detailed in our guide on securing API credentials in n8n applies here to the key itself.

Automating the PostgreSQL dump with an n8n workflow

Rather than a plain system cron, using n8n to back up n8n has a concrete advantage: the same workflow can dump the database, upload it to remote object storage, purge backups that are too old, and alert you on failure — all visible in the Executions tab.

Typical setup, triggered by a Schedule Trigger (see our guide on cron expressions and timezones to pick a low-traffic nighttime slot):

1. Schedule Trigger — daily at 3am local time.
2. Execute Command — runs pg_dump in custom format (compressed, selectively restorable):

   pg_dump -U n8n_user -d n8n -F c -f /backups/n8n_$(date +%F).dump
   

3. Read/Write Files from Disk — reads the generated file as binary data.
4. S3 (or Google Drive) — uploads the binary to a remote bucket, off the machine hosting n8n. A backup that stays on the same server as the database it protects protects against nothing in the event of a disk failure or an accidentally deleted VM.
5. Execute Command (cleanup) — deletes bucket dumps older than 14-30 days, depending on your retention policy.
6. An Error Trigger wired to this workflow — a Slack or email alert if any of these nodes fail, following the same principle described in our guide on error handling with Error Workflow. A backup that fails silently for weeks is worse than no backup at all: it gives a false sense of security.

Test the restore, not just the backup

A dump that's never been restored is only a backup hypothesis. Restoring works the same way, on a test instance:

pg_restore -U n8n_user -d n8n_test --clean /backups/n8n_2026-07-20.dump

reusing the same N8N_ENCRYPTION_KEY as the original instance. Schedule this test at least once a quarter: it's the only way to know whether your dumps are actually usable before you need one in an emergency — the day of a real incident is not the moment to discover a broken format or a missing variable.

Special case: external data (Supabase, pgvector)

If you're running the RAG Assistant Pack, the embeddings and vectorized documents live in your own Supabase project — a database separate from n8n's, with its own backup mechanisms to enable on the Supabase side. Don't conflate the two: backing up n8n's database doesn't back up your vector database, and vice versa. Every component of your stack needs its own continuity strategy.

Common pitfalls

• Backing up to the same disk as the database: a hardware failure takes out the backup and the original together. Remote storage isn't optional.
• Forgetting the encryption key: the freshest dump in the world is useless if the credentials inside it are unrecoverable.
• Never testing the restore: an unverified backup is a backup whose real reliability you don't actually know.
• Conflating a git export of workflows with a database backup: the two serve different needs and complement each other — neither replaces the other.

Going further

This kind of operational rigor lines up directly with the Compliance & Audit Pack (€149): its audit-trail and automated reporting workflows rest on the same principle — a reliable cron, an alert on failure, data you can prove you didn't lose. If your n8n instance is already running email-triage automations or a production RAG assistant, the Complete FlowKit Bundle (€269) brings all three packs together on that same continuity requirement.