Module 05 · Self-Hosting n8n
Backups, Updates, and Keeping It Running
Open lesson + course map
On this lesson
Course outline
Module 1 · Why n8n, Why Now
Module 2 · Workflow Architecture
Module 3 · Working With APIs
Module 4 · Webhooks and Triggers
Module 5 · Self-Hosting n8n
Module 6 · AI Nodes in n8n
Module 7 · Real Business Automations
Module 8 · Selling Automation as a Service
A backup is proven only by restoration. An update is safe only after staging, compatibility checks, database backup, and rollback rehearsal. Availability depends on operated alerts and runbooks, not container restart policies alone.
// concept
Inventory Recovery Assets
Protect:
- PostgreSQL database;
- n8n encryption key;
- deployment configuration and pinned versions;
- workflow/source exports where useful;
- required binary data according to storage mode;
- license/configuration records;
- DNS/TLS/reverse-proxy instructions;
- credential owner/rotation inventory without secret values.
Store backups encrypted, access-controlled, and separate from the primary VPS/account. Define recovery point objective (acceptable data loss) and recovery time objective (acceptable outage) from business needs.
// concept
Test Restore
In isolated staging:
- create a fresh host/database;
- restore database and matching key/config;
- start the pinned n8n version;
- verify users, workflows, credentials through synthetic calls;
- verify webhooks only on staging URLs;
- record time, gaps, and evidence;
- destroy the test environment securely.
Never connect restored staging to production triggers accidentally.
// concept
Update Deliberately
Read n8n release notes and breaking changes. Pin the candidate in staging, restore a recent scrubbed/authorized backup or representative fixtures, and test critical workflows, credentials, community nodes, webhooks, task runners, and execution modes. Back up production immediately before the maintenance window and define rollback.
Monitor start failures, execution errors, queue age, database/disk, memory/CPU, certificate expiry, backup age, and missing expected runs. Assign owners.
// worked_example
Worked Example
A client schedules monthly updates after a weekly backup restore drill. Version X introduces a node behavior change that breaks an expression in staging. The team fixes/tests before production. During a later update, health checks fail; rollback restores the previous image against compatible database state according to the tested runbook.
The incident report records timeline and evidence without credentials or customer payloads.
// failure_cases
Failure Cases to Diagnose
6 cases to diagnose
Only VPS snapshot
account loss can remove both service and backup.
Encryption key missing
encrypted credentials cannot be recovered.
Restore never tested
backup success notification is insufficient.
Automatic major update
stage compatibility.
Rollback ignores database migration
follow version-specific guidance.
Alerts reach one freelancer
add client-owned escalation.
// pakistan_angle
Pakistan Angle
Schedule maintenance in PKT around real business hours and notify affected teams. Plan for local operator internet/power loss: runbooks and access must be available to another authorized person.
Do not download production backups containing customer/CNIC/bank data to a personal laptop. Use controlled encrypted infrastructure and documented deletion.
// hands_on
Hands-On Exercise
5 steps
Define RPO/RTO and asset inventory.
configure separate encrypted backups.
perform clean restoration.
stage one version update and rollback.
test alerts and alternate operator.
// completion_rubric
Completion Rubric
6 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “Rollback ignores database migration.” What does the lesson tell you to do about it?