Backing up and versioning n8n workflows with Git (without the paid plan)

An n8n workflow that took two days to fine-tune can vanish with one careless click: a "Save" that overwrites a working version with an in-progress experiment, an instance update that goes wrong, a teammate who edits the wrong node thinking they're working on a copy. Without history, there's no way back — just a rough memory of what worked yesterday. Software development solved this problem decades ago: Git. The good news is you don't need to pay for n8n's Business plan to use it.

What n8n offers natively (and why it isn't always accessible)

n8n ships a Source Control and Environments feature that connects the editor directly to a Git repository: a "Push" button sends your workflows, tags, and variables to GitHub, GitLab, or Bitbucket; a "Pull" button brings them back into another environment. It's the smoothest experience — but it's limited to Business and Enterprise plans, including self-hosted instances, where the Business plan starts at several hundred euros a month. For a small business or a solo operator running n8n on the free Community Edition (the case for most users of our workflow packs), that door is closed.

That doesn't mean you're stuck: the Community Edition has long shipped export and import CLI commands that cover the core need — versioning, backing up, migrating between environments — with no paid license at all.

The free path: export:workflow and import:workflow

On a self-hosted instance (Docker, npm, or a manual install), this command exports every workflow into a folder, one JSON file per workflow:

n8n export:workflow --all --separate --output=./workflows/

The --separate flag is the one that matters for versioning: without it, all workflows land in a single JSON file, which makes Git diffs unreadable and merge conflicts nearly impossible to resolve cleanly. With one file per workflow, every git diff shows exactly which node changed.

To export just one workflow (handy after a one-off edit):

n8n export:workflow --id=12 --output=./workflows/email-triage.json

Import follows the same logic in reverse — useful for restoring a backup or deploying the same workflows to a new instance (a self-hosted migration, a staging environment):

n8n import:workflow --separate --input=./workflows/

Credentials follow the same principle, but separately: n8n export:credentials --all --output=./credentials.json produces an encrypted export by default. A --decrypted flag exists for migrating to an instance with a different encryption key — in that specific case, never commit that file to Git, even a private repo: keep it out of the repo (.gitignore) or encrypt it separately with a secrets manager.

Automating the backup with a script and cron

Manual exports rarely survive the daily grind for long. A minimal script, triggered by cron every night, turns this habit into a permanent safety net:

#!/bin/bash
set -e
cd /opt/n8n-backup
n8n export:workflow --all --separate --output=./workflows/
git add workflows/
if ! git diff --cached --quiet; then
  git commit -m "backup: n8n workflows $(date +%F)"
  git push origin main
fi

The git diff --cached --quiet check avoids creating an empty commit on days with no changes — a small detail that keeps the Git history readable instead of drowning in hundreds of identical commits. A standard crontab entry (0 3 * * * /opt/n8n-backup/backup.sh) is enough to run this safety net every night at 3am, with no manual intervention.

The Docker case: exporting from a container

Most self-hosted instances running the FlowKit packs run inside Docker. The export command then runs via docker exec, making sure the output folder points to a volume mounted and shared with the host (otherwise the files disappear along with the container):

docker exec n8n n8n export:workflow --all --separate --output=/home/node/backup/workflows/

The rest of the backup script (commit, push) runs on the host side, against the mounted folder — n8n inside the container needs no network access to Git at all.

Structuring the repo so it stays readable

A backup repo that grows without any organization quickly becomes as hard to navigate as a "Downloads" folder. A few simple conventions avoid that trap:

• One folder per project or pack (workflows/inbox/, workflows/rag/, workflows/audit/) rather than a flat folder with dozens of files.
• Stable file names, derived from the workflow's name rather than its internal numeric ID, so renames in the n8n editor stay traceable in Git history.
• A .gitignore that excludes decrypted credential exports and any .env file containing API keys.
• One branch per environment (main for production, staging for testing) if you run multiple n8n instances, with the same sync script adapted to each instance's URL.

This organization ties directly into the principles covered in our n8n self-hosted vs Cloud comparison: once you pick self-hosting to keep control over the infrastructure, the responsibility for backing up and reproducing workflows falls entirely on the operator — Git is the most natural foundation for that.

Restoring after an incident

The real test of a backup isn't creating it, it's restoring it. After an incident (a broken update, an accidental deletion, a migration to a new server), rolling back follows the same path in reverse:

1. git checkout <commit-before-incident> (or git log workflows/ to find the right version of a specific file);
2. n8n import:workflow --separate --input=./workflows/ on the target instance;
3. Manually reconnecting credentials if the import runs on a new instance — imported workflows reference credential IDs that must exist on the destination side, something worth checking systematically during any migration.

That last point deserves a cold test at least once, in a staging environment, before you actually need it in production. A restore that fails silently on missing credentials — rather than with a clear error — is one of the most common pitfalls of poorly prepared n8n migrations, in the same spirit as what we cover in our guide on error handling and the Error Workflow.

Where this connects to your FlowKit packs

The workflows shipped in the AI Inbox Pack (€79), the RAG Assistant Pack (€119), and the Compliance & Audit Pack (€149) are themselves n8n JSON exports — exactly the format export:workflow produces. The natural move right after installing them is to commit those files as-is into your own backup repo before any customization: you get a known, working restore point, and every subsequent prompt or logic tweak becomes a distinct, traceable commit instead of a change lost in the editor's fuzzy history. The Complete FlowKit Bundle (€269 instead of €347) covers all three workflow families with that same versionable-files approach from day one.

Common pitfalls

• Exporting without --separate: a single JSON file for every workflow makes diffs and change reviews unreadable.
• Committing decrypted credentials: even on a private repo, these are plaintext secrets — treat them like a password, never like code.
• Forgetting the Docker volume: exporting "inside" a container without a mounted volume produces files that vanish on the next restart.
• Never testing the restore: a backup that's never been re-imported is just a backup hypothesis, not a backup.
• Credential IDs out of sync between environments: a successful import can still leave AI or Supabase nodes orphaned from their credentials on the target instance.

Versioning n8n workflows requires no paid license and no complicated third-party tool: two CLI commands, a ten-line script, and one crontab entry are enough to turn a fragile folder of workflows into a reliable, restorable, auditable Git history — the same rigor behind our ready-to-import packs.