Put Your n8n Workflows in Git Before You Lose One

A server hiccup once wiped one of my client automations. No export, no backup, no history. I rebuilt it from memory over an afternoon, got about 90% of it right, and spent the next week finding the missing 10% in production.

That was the day I started treating automations like what they actually are: production code that happens to have a pretty canvas on top.

Automation is infrastructure, and nobody treats it that way

Here is the strange thing about the n8n world. The people building these workflows are often the same people who would never dream of editing a live server by hand. They use Git for everything. Branches, pull requests, code review, the whole ritual.

Then they open a workflow editor, drag fifteen nodes into a business-critical pipeline, hit save, and that is it. One copy. On one box. With no history.

It feels different because it looks different. A canvas with boxes and arrows does not feel like code. But a workflow that moves invoices, syncs a CRM, or publishes content is doing the same job a script would do, and it fails in the same ways. The difference is that when a script breaks, you can read the diff. When a workflow breaks, you are staring at a canvas trying to remember what it looked like on Tuesday.

What n8n gives you now, and the catch

This has improved. n8n has native source control that pushes workflows and tags to your Git provider, along with credential and variable stubs. It is a real feature and it works.

Two catches.

First, it is Enterprise only. If you are on Community or a lower tier, you do not have it. That covers most solo operators and small teams, which is most of the people running n8n.

Second, even with it, this is not full version control. There is no pull request flow inside n8n, and no diff or review interface. You get your workflows into Git, which is the important part, but the review loop still lives on the Git side.

So for most people the honest answer is still the same one from two years ago: export the JSON yourself, on a schedule, into a repo you own.

The setup, which takes about twenty minutes

There is an official n8n template that does exactly this. It calls the n8n API, pulls every workflow as JSON, and commits them to a GitHub repo on a schedule.

What you need:

• A private repo. Private, because workflow JSON leaks more about your business than you think - endpoints, internal names, logic.
• A GitHub token with repo scope, stored in n8n credentials.
• The template imported and pointed at your repo.
• A Cron node. Daily is plenty for most people.

I group the files by tag and use timestamped commit messages. Both are small choices that pay off the first time you go looking for something.

What gets saved and what must not

Saved: the workflow definition. Nodes, connections, triggers, settings, tags, the active flag. One JSON file per workflow.

Not saved: credentials and execution history.

That second part is not a limitation, it is the point. Your credentials belong in n8n's credential store, encrypted, and nowhere near a Git repo. If you ever find yourself thinking it would be convenient to commit a token so a workflow restores cleanly, that is the moment to stop and go make a coffee instead.

Execution history is similar. It is large, it is noisy, and it usually contains customer data. Leave it where it is.

What you actually get out of this

The backup is the boring part. The history is the point.

You can diff a node change. When something starts failing on a Thursday, you can look at what changed on Wednesday instead of guessing. That alone has saved me more hours than any other automation habit.

You can roll back. Not "rebuild from memory", but genuinely restore the version that worked.

You can branch and review. If more than one person touches your automations, a pull request on a workflow JSON is not the prettiest diff in the world, but it is infinitely better than someone silently editing production at 11pm.

And you get an inventory. After a year of running automations for clients, the repo becomes the only honest answer to "what do we actually have running?"

Where this breaks

It is not magic, so here are the rough edges.

Workflow JSON diffs are ugly. Node positions change when you nudge things on the canvas, so you get noise in the diff that has nothing to do with logic. You learn to skim past it, but it is real friction.

A restore is not one click. You are importing JSON back into an instance and reconnecting credentials by hand. Test this once, deliberately, before you need it. A backup you have never restored is a hope, not a backup.

And the schedule means you can lose up to a day of edits. If you are doing heavy work on a workflow, trigger the backup manually when you finish.

The actual lesson

None of this is clever. It is the most boring possible engineering practice, applied to a category of work that has quietly become critical while everyone was calling it "just automation."

If a workflow disappearing tomorrow would ruin your week, it belongs in Git today. The setup costs less time than one rebuild.

---

I build and maintain automation systems for teams who have started depending on them. If your automations have grown past the point where anyone can hold them in their head, that is what I do.