n8n version control works two ways. On Business and Enterprise plans, built-in source control pushes and pulls workflows to a Git branch, with credential and variable values kept out of Git. On any self-hosted plan, the n8n CLI exports one JSON file per workflow that you commit to GitHub. Keep changes flowing one way and watch for ID collisions on import.
n8n version control works in two ways: the built-in source control feature on Business and Enterprise plans, which pushes and pulls workflows to a Git branch from the n8n menu, and the n8n command line, which exports workflows as JSON files you commit to GitHub yourself on any self-hosted instance. Either way, the rules that prevent pain are the same: keep secrets out of Git, keep changes flowing in one direction, and keep workflow IDs stable between environments.
Checked October 2026 against n8n's docs on source control and environments, pushing and pulling changes, branching patterns, the command line, and backup and restore.
Version control matters most once you have more than a handful of workflows. For templates, integrations and hosting options, see our n8n hub with 100 workflow templates.
n8n version control: the two methods compared
| Built-in source control | CLI export to Git | |
|---|---|---|
| Plans | Business and Enterprise | Any self-hosted instance |
| How it works | Push and pull from the n8n menu | CLI export to files, then git commit |
| What is versioned | Workflows, data tables, tags, variable and credential stubs | Workflows (and credentials, if you export them) |
| Secrets | Values never synced to Git | Your responsibility; keep credential exports out of Git |
| Environments | Built-in, with branch patterns | You script it |
| Who can do it | Push: owner, admin, project admin. Pull: owner or admin | Whoever runs the CLI on the server |
If you are on a Business or Enterprise plan, the built-in feature is the cleaner choice: it is designed for environments and keeps secret values out of Git automatically. If you self-host on another plan, the CLI route gives you history, diffs and backups with a few lines of scripting.
n8n Git integration: built-in source control
Built-in source control links an n8n instance to a Git repository and branch. From the main menu you push work to Git or pull work from it. When you push, n8n asks which workflows and data tables to include, lets you filter by new, modified or deleted, and automatically pushes tags along with variable and credential stubs. You add a commit message and n8n sends the commit.
- 01Dev instance
Build and test
- 02Push
To the dev branch
- 03Pull request
Review in Git
- 04Merge
Into the production branch
- 05Pull on production
Then publish
Two details catch people out. First, n8n pushes the current saved version of a workflow, not the published version, so you publish separately on the receiving instance; when pulling, an Auto publish option controls this. Second, only some roles can act: the docs say instance owners, instance admins and project admins can push, while pulling requires an instance owner or admin.
Branch patterns for environments
n8n's docs describe flexible relationships between instances and branches. The two common patterns for environments are:
- Dev instance linked to a dev branch
- Prod instance linked to a prod branch
- Pull requests move work between branches
- Review step before production
- Best for teams
- Dev and prod both linked to one branch
- Dev pushes, prod pulls
- Same workflows, tags and variables everywhere
- Fewer moving parts
- Best for small setups
The multiple-branch pattern adds a review step through pull requests, which is where Git earns its keep: someone can read the workflow diff before it reaches production.
What goes into Git, and what never should
Built-in source control stores copies of workflows plus tags and stubs for variables and credentials. A credential stub contains the ID, name and type, and other fields only if they are expressions. n8n does not sync credential or variable values with Git; you set those up on each instance, and n8n tells you when a pull adds stubs that need values.
With the CLI method, you are responsible for this separation. Export workflows to your Git folder, and keep any credential exports somewhere else entirely, encrypted and out of the repository. Treat a credentials export like a password file.
n8n export workflows to GitHub with the CLI
On a self-hosted instance, the n8n CLI handles exports and imports. The backup flag is the one to use for Git: n8n says it sets the all, pretty and separate options, writing each workflow as its own readable JSON file, which makes diffs meaningful.
| Command | What it does |
|---|---|
| n8n export:workflow --backup --output=backups/workflows/ | One pretty JSON file per workflow, for Git |
| n8n export:workflow --id=<ID> --output=file.json | Export a single workflow |
| n8n export:workflow --all --published --output=workflows.json | Export published versions to one file |
| n8n import:workflow --separate --input=backups/workflows/ | Import every JSON file in a folder |
| n8n import:workflow --input=file.json | Import one file |
- 1Create a private repository
One repo per n8n project or instance.
- 2Export with --backup to a workflows folder
One JSON file per workflow.
- 3Commit and push
A short message saying what changed.
- 4Schedule it
A cron job or scheduled task on the server, daily or after deploys.
- 5Import into other instances deliberately
Use import:workflow --separate, then activate in the UI.
If you run n8n in Docker, run the CLI inside the container, for example with docker exec, and mount the output folder so the files land on the host where Git can see them. Our n8n Docker Compose setup guide and n8n self-hosting guide cover the container side.
The ID problem, and how to avoid it
Every n8n workflow and credential has an ID, and exports keep them. n8n's backup docs say that if the target instance already has items with the same IDs, they are overwritten, and imported workflows are deactivated by default. That is useful for restoring a backup, and dangerous when you import into an instance with unrelated work.
- Use one source instance per repository
- Never hand-edit IDs in exported JSON
- Check the target for existing IDs before importing
- Expect imported workflows to be inactive
- Recreate credentials on each instance with matching names
- Test imports on a staging instance first
Workflows that call each other, such as through the Execute Workflow node, reference IDs too. Keep IDs stable across environments so those references still resolve after a move.
Restoring a workflow from Git
History is only useful if you can go back. With built-in source control, the usual route is to revert the change in Git, through a revert commit or pull request on the branch, and then pull on the instance. n8n may warn that pulling will override local changes; its docs describe a Pull and override option for that case. Because n8n pushes saved versions rather than published ones, publish the restored version once it is back.
With the CLI route, check out the older JSON file from Git history and import it with import:workflow. Remember that the import overwrites a workflow with the same ID and leaves it inactive, so review it in the editor and activate it again when you are happy. For a full instance recovery, n8n's backup and restore docs note that a CLI backup covers workflows and credentials only, so database-level backups are still needed for everything else.
Which approach should you choose?
- Solo builder on a self-hosted community setup: scheduled CLI exports to a private GitHub repository give you history and backups with little effort.
- Small team on a Business plan: built-in source control with the multiple-instances, one-branch pattern keeps things simple.
- Team with review needs: built-in source control with one branch per environment, and pull requests as the gate into production.
Whichever you pick, write down the flow: who pushes, who pulls, and which instance is the source of truth. Most version-control pain in n8n comes from two people editing the same workflow in two places.
Reviewing workflow changes in Git
Workflow JSON is verbose, but with one file per workflow and pretty formatting, a diff shows which nodes and parameters changed. Reviewers usually look for three things: changed credentials references, changed URLs or endpoints, and changed expressions. Pair Git review with good error handling so a bad change fails loudly; see our guide to n8n error handling. If you build your own nodes, the same repository can hold them; our guide to n8n custom nodes covers that side.
If you are turning automations into a service or product, our AI SaaS program covers building, shipping and maintaining AI tools.
n8n version control: FAQ
Does n8n have built-in version control?
Yes, on some plans. n8n's source control and environments feature connects an instance to a Git repository so you can push and pull workflows, tags, and variable and credential stubs. Its docs say it is available on Business and Enterprise plans. On other plans, you can export workflows with the n8n CLI and commit the JSON files to Git yourself. Checked October 2026.
How do I export n8n workflows to GitHub?
On a self-hosted instance, run n8n export:workflow with the --backup flag and an output directory. That writes one readable JSON file per workflow, which you can commit and push to a GitHub repository. Automate it with a scheduled job, and import with n8n import:workflow --separate --input pointing at the folder.
Are credentials stored in Git with n8n source control?
No. n8n pushes credential stubs, meaning the ID, name and type, plus other fields only if they are expressions. Its docs say n8n does not sync credential and variable values with Git, so you set them up manually on each instance. That keeps secrets out of your repository.
Can I push and pull to the same n8n instance?
You can, but n8n does not recommend it. Its docs advise creating a process where work goes in one direction, either to Git or from Git, to reduce the risk of merge conflicts and overwritten work. A common setup is a development instance that pushes and a production instance that pulls.
What happens to workflow IDs when importing n8n workflows?
n8n's backup docs say exports include the original workflow and credential IDs, and if the target instance already has items with the same IDs, they are overwritten. Imported workflows are deactivated by default. Keep IDs stable across environments and check for collisions before importing into an instance with existing work.
Does n8n detect merge conflicts in workflows?
Not for workflows. n8n describes its source control as opinionated: it resolves conflicts for credentials and variables automatically, but it cannot detect conflicts on workflows. That is another reason to keep changes flowing in one direction and avoid editing the same workflow on two instances.
Ship workflows you can trust.
The AI SaaS program, included in All Access, covers automation, AI agents and building sellable AI tools, with the other three programs, live coaching and the private community in one subscription.
Free n8n help
Join the free Discord to share workflows, ask setup questions and see what others are building.