n8n Backs Up n8n: A Love Story About Not Losing Your Work

By ClauDeLay

It’s a Tuesday morning. You’re three coffees deep, tweaking your most complex n8n workflow — the one that took two weekends, a mass of Stack Overflow tabs, and one mass of profanity to build. You’re dragging nodes around, cleaning things up, making it pretty. Then you accidentally delete a connection. No — worse. You accidentally delete a node. The one with the 47-line Code block you never copied anywhere.

Ctrl+Z? Doesn’t work the way you think it does. Version history? Not in community edition. Git integration? That’s an Enterprise feature. Your workflow is gone, and the only copy that ever existed was the one you just destroyed.

This isn’t hypothetical. I’ve been there. And I’m willing to bet if you’ve used n8n for more than a month, you’ve had that stomach-drop moment too.

This article is the cure.

Sequel alert: This is a direct follow-up to n8n: A Homelab Superpower, But Handle With Care. In that article, I ended with a promise: “I will share the exact n8n workflow I use to back up all of my other workflows automatically.” This is me keeping that promise. If you haven’t read it, go do that first — it covers the security and development methodology you’ll need before building anything serious in n8n.

Just want the workflow? Skip straight to the download section at the bottom. Import it, configure your credentials, and you’re done in 10 minutes. But stick around — the why is more interesting than the how.

# On your Docker host (not inside the container):
sudo vi /opt/n8n/file_writer_service.py
# Paste the file-writer script (see "The File-Writer Hack" section below)

sudo vi /etc/systemd/system/n8n-file-writer.service
# Paste the systemd unit file

sudo systemctl daemon-reload
sudo systemctl enable --now n8n-file-writer

sudo mkdir -p /opt/n8n/backups/workflows
sudo chown -R $(whoami):$(whoami) /opt/n8n/backups

$ cat results.log

What You Get: The End Result

Before I explain how it works, let me show you what “enterprise-grade DR on a homelab budget” actually looks like.

Every morning at 2 AM, while you’re sleeping, this workflow silently:

1. Queries the n8n API for every workflow in your instance
2. Fetches the complete definition of each one (not just the summary — every node, every connection, every setting)
3. Saves each workflow as an individual, human-readable JSON file in a timestamped directory
4. Generates a backup manifest cataloging everything it saved
5. Uploads the whole thing to Google Cloud Storage for off-site disaster recovery
6. Cleans up local backups older than 30 days so your disk doesn’t fill up

Here’s what the backup directory looks like on a typical morning:

/opt/n8n/backups/workflows/
├── 2026-02-10_020003/
│   ├── _backup_manifest.json
│   ├── Duplicati_Backup_Monitor_I80zE5ptBHVt44zZ.json
│   ├── N8n_Complete_Backup_with_GCS__Daily_DR__mWzpgzamOF0XpdvP.json
│   ├── PBS_Backup_Notification_Monitor_yA9iPkyJhsHfvubx.json
│   ├── Pinball_Service_Monitor_yg7dzcbnBBosFQej.json
│   ├── RSS_Feed_with_Gen_AI_Summary_abc123.json
│   └── ... (every workflow, every day)
├── 2026-02-11_020002/
│   ├── _backup_manifest.json
│   └── ... (same set, one day later)
└── 2026-02-12_020001/
    └── ...

Notice the filenames: Workflow_Name_WorkflowID.json. Human-readable and machine-parseable. You can tell what’s what without opening a single file.

But the real magic? This:

diff 2026-02-10_020003/RSS_Feed_with_Gen_AI_Summary_abc123.json \
     2026-02-11_020002/RSS_Feed_with_Gen_AI_Summary_abc123.json

47c47
<     "expression": "Summarize these articles with a focus on security implications"
---
>     "expression": "Summarize these articles with a focus on security implications and practical takeaways"

That’s it. That’s the exact change I made on Monday afternoon. Line 47. One sentence added to a Gemini prompt. When something breaks next week and I can’t remember what I changed, I don’t have to guess. I diff yesterday against last week and the answer is right there.

That’s version control for a GUI tool. That’s what separates “I hope my workflows are fine” from “I know exactly what changed and when.”

$ tree pipeline/

The Architecture: 10 Nodes, Zero Drama

Here’s the full pipeline at a glance:

Schedule (2 AM cron)
    │
    ▼
Fetch All Workflows (n8n API)
    │
    ▼
Set Backup Metadata (timestamp, count, array)
    │
    ▼
Create Backup Directory (SSH → mkdir)
    │
    ▼
Split Workflows for Processing (Code node)
    │
    ▼
Get Full Details for Each (n8n API, per-workflow)
    │
    ▼
Prepare File Write (sanitize names, base64 encode)
    │
    ▼
Loop & Write (batch write via file-writer service)
    │
    ▼
Generate Manifest + Upload to GCS
    │
    ▼
Cleanup Old Backups (30+ days local, 7+ days tmp)

Ten nodes. No exotic plugins. No third-party services (besides GCS, which is optional). Just the n8n API talking to itself, some JavaScript, and a file-writing trick I’ll explain in a moment.

Let me walk through each stage.

$ init –stages 1-4

The Foundation: Trigger, Fetch, Metadata, Directory

The first four nodes set the stage. Nothing fancy here — just solid plumbing.

$ ./process_each_workflow.sh

The Core: Split, Fetch, and Prepare

This is three nodes working together, and it’s the heart of the whole workflow.

Split Workflows for Processing

A Code node that takes the array from Stage 3 and fans it out into individual items. Each item carries its workflow metadata plus the backup timestamp.

Get Workflow Details

For each split item, an HTTP Request node hits http://localhost:5678/api/v1/workflows/{workflowId}. This is where we get the full definition: every node, every connection, every parameter, every credential reference.

Prepare File Write

Another Code node that does the heavy lifting:

• Sanitizes the workflow name for use as a filename (replaces special characters with underscores)
• Appends the workflow ID for uniqueness
• Builds the full filepath: /opt/n8n/backups/workflows/{timestamp}/{filename}.json
• Pretty-prints the JSON (JSON.stringify(data, null, 2)) so it’s human-readable and diff-friendly
• Base64-encodes the whole thing for transport

That last step — base64 encoding — exists because of the file-writer service, which deserves its own section.

$ python3 file_writer_service.py

The File-Writer Hack (or: When n8n Won’t Let You Write Files)

Here’s a fun problem I ran into.

n8n community edition blocks the fs (filesystem) module in Code nodes. It’s a security decision — they don’t want arbitrary workflows writing files to the server. Fair enough. But I need to write files to the server.

My first attempt: SSH from the n8n container back to the Docker host and pipe the file content through. Result? ECONNRESET errors after a few files. SSH doesn’t love being hammered with rapid sequential connections from inside a container.

My solution: a 30-line Python HTTP service running on the Docker host.

# Listens on 127.0.0.1:8765 (localhost only)
# Accepts POST with {"filepath": "...", "base64Data": "..."}
# Decodes the base64, writes the file
# Only allows paths under /opt/n8n/backups/workflows/

It’s a systemd service (n8n-file-writer.service) that starts on boot and does exactly one thing: accept base64-encoded files over HTTP and write them to disk. Localhost only, path-restricted, no authentication needed because it’s not exposed to the network.

Is it elegant? Not particularly. Does it work flawlessly every single day at 2 AM without complaint? Yes. That’s homelab engineering.

The Loop Over Items node batches the writes, sending each workflow JSON to http://127.0.0.1:8765 one at a time. Clean, reliable, boring. Boring is good in backup systems.

$ cat _backup_manifest.json

The Backup Manifest

After all workflows are written, the pipeline generates a _backup_manifest.json in the same timestamped directory:

{
  "backupDate": "2026-02-12 02:00:15",
  "totalWorkflows": 15,
  "backupLocation": "/opt/n8n/backups/workflows/2026-02-12_020001/",
  "status": "SUCCESS",
  "gcsFullBackupPath": "gs://your-bucket/full-backups/2026-02-12_020001/...",
  "gcsWorkflowsPath": "gs://your-bucket/workflows/2026-02-12_020001/",
  "workflows": [
    { "id": "abc123", "name": "My Important Workflow", "active": true },
    { "id": "def456", "name": "Another Workflow", "active": false }
  ]
}

This is your table of contents. At a glance you can see: how many workflows were backed up, whether the backup succeeded, where to find it locally and in the cloud, and which workflows are active vs. inactive.

It sounds like a small thing, but when you have 15+ workflows and you’re trying to find the right backup at 11 PM on a Friday, a manifest saves you from opening every file.

$ gsutil rsync

Off-Site to Google Cloud Storage

Local backups protect against mistakes. Cloud backups protect against your server catching fire.

The workflow uploads the complete backup to a Google Cloud Storage bucket. This gives you the full 3-2-1 backup picture:

What Does This Cost?

That’s not a typo. A penny. Maybe. Google doesn’t even bother to charge you for storage this small. Enterprise-grade disaster recovery for the price of literally nothing.

Don’t have GCS? The workflow works perfectly fine without the cloud upload. You still get local timestamped backups, the manifest, the cleanup — all of it. The GCS piece is the cherry on top, not a requirement.

$ find . -mtime +30 -delete

Cleanup (Because Hoarding Isn’t a Backup Strategy)

Two cleanup steps run at the end:

1. Local backups older than 30 days — find /opt/n8n/backups/workflows -type d -mtime +30 -exec rm -rf {} +
2. Temp files older than 7 days — find /tmp -name 'n8n-*-backup-*.tar.gz' -mtime +7 -delete

Both use continueOnFail: true so a cleanup failure doesn’t tank the whole backup. Cleanup is important but not critical.

30 days of local history means you can go back an entire month. Combined with GCS, you can go back… well, as far as your cloud retention policy allows.

$ ls *backup*backup*

The Beautiful Recursion

Here’s my favorite detail about this whole system: the backup workflow backs up itself.

N8n_Complete_Backup_with_GCS__Daily_DR__mWzpgzamOF0XpdvP.json appears in every timestamped backup directory. If you break the backup workflow while editing it, yesterday’s backup has a working copy. Import it, and you’re back in business.

It’s turtles all the way down, and it’s exactly the kind of safety net that lets you develop fearlessly.

$ diff –color tuesday/ today/

How to Restore (Because a Backup You Can’t Restore Is Just Wasted Disk Space)

Let’s say it’s Friday. Something’s broken. You need to roll back your “Pinball Service Monitor” workflow to what it looked like on Tuesday.

ls /opt/n8n/backups/workflows/
# 2026-02-10_020003/
# 2026-02-11_020002/
# 2026-02-12_020001/

diff /opt/n8n/backups/workflows/2026-02-10_020003/Pinball_Service_Monitor_yg7dzcbnBBosFQej.json \
     /opt/n8n/backups/workflows/2026-02-12_020001/Pinball_Service_Monitor_yg7dzcbnBBosFQej.json

Either way, you’re back to a known-good state in under 5 minutes. No guessing, no recreating from memory, no panic.

$ ./check_requirements.sh

Prerequisites: What You Need Before Importing

Before you import the downloadable workflow, you’ll need a few things in place:

The File-Writer Service

This is the one piece that doesn’t come with n8n. You’ll need to set up a small systemd service on your Docker host:

# /opt/n8n/file_writer_service.py
from http.server import HTTPServer, BaseHTTPRequestHandler
import json, base64, os

ALLOWED_PREFIX = "/opt/n8n/backups/workflows/"

class FileWriter(BaseHTTPRequestHandler):
    def do_POST(self):
        data = json.loads(self.rfile.read(int(self.headers['Content-Length'])))
        filepath = data['filepath']
        if not filepath.startswith(ALLOWED_PREFIX):
            self.send_response(403)
            self.end_headers()
            return
        os.makedirs(os.path.dirname(filepath), exist_ok=True)
        with open(filepath, 'wb') as f:
            f.write(base64.b64decode(data['base64Data']))
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'{"status": "ok"}')

HTTPServer(('127.0.0.1', 8765), FileWriter).serve_forever()

# /etc/systemd/system/n8n-file-writer.service
[Unit]
Description=n8n File Writer Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/n8n/file_writer_service.py
Restart=always
User=root

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now n8n-file-writer

Localhost only. Path-restricted. Does one thing well.

$ cat /var/log/lessons.log

Lessons Learned

$ wget

Download the Workflow

Ready to set it up? The sanitized workflow JSON is below. All credential IDs, instance IDs, and bucket names have been replaced with placeholders.

After importing:

1. Update the n8n API credential references (2 nodes use it)
2. Update the SSH credential references (3 nodes use it)
3. Update the GCS bucket name in the Prepare Manifest Code node (or remove the GCS reference if you don’t need cloud backup)
4. Set up the file-writer service on your Docker host (see Prerequisites above)
5. Activate the workflow

$ exit

Wrapping Up

Here’s the thing about backups: nobody cares about them until they need one. And by then it’s too late.

This workflow took me an afternoon to build and has been running silently every night for months. It costs nothing. It requires zero maintenance. And it has already saved me twice — once when I accidentally broke a complex workflow, and once when I needed to see exactly what I’d changed three weeks ago.

If you’re running n8n in your homelab, you already know it’s powerful. This is how you make it reliable. Enterprise-grade disaster recovery, timestamped version history, and off-site cloud backup — all running on the same tool that almost lost your work in the first place.

The irony isn’t lost on me. But that’s n8n for you: powerful enough to automate its own safety net.

Now go back up your workflows. Then go build something you’re not afraid to break.