n8n version control workflows: Git vs exported JSON vs manual backups
n8n version control workflows compared: native Git source control, exported JSON files and manual backups, judged on history, review, rollback and edition requirements.
Checked against the cited sources on .
Three approaches to n8n version control workflows
Teams that need n8n version control workflows usually choose between native Git source control, exported JSON files and manual backups. This comparison judges each on four criteria: history, review, rollback and edition requirements.
The evidence comes from n8n's documentation and its blog, so the n8n version control workflows described here reflect what n8n documents, and we flag gaps along the way.
Sources: Use source control and environments | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Git source control: the native n8n version control
Per n8n's docs, native Git source control is available on Business and Enterprise plans only. Instance owners or admins enable and configure it, and project admins can push but not pull.
History is created by pushing, and in n8n commit and push happen together. The docs also say the integration is not full version control and offers no pull-request-style review, so review happens in your Git provider. A push sends the saved version of a workflow, not the published one, plus tags and credential stubs with ID, name and type, so secrets are not committed. Data table row data is not pushed. n8n's own blog, which is vendor guidance, describes diffs that show added, modified and deleted nodes before a push or pull, and says protected instances prevent direct edits to source-controlled resources.
Rollback means pulling an earlier repository state, and a pull overwrites unpushed local changes. n8n's docs add that it cannot detect workflow conflicts, that the repository is the source of truth and that pushing overwrites Git, so one-directional flow is advised. Pulling can briefly unpublish and republish a published workflow. We think the one-directional flow is worth adopting as a hard rule, because the tool will not warn you when two people diverge.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, Push and pull changes | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
n8n version control with exported JSON and manual backups
n8n's docs say workflow JSON can be exported or imported through the editor menu, copy-paste, the CLI or the API. The self-hosted Server CLI can export one file per workflow, described as useful for versioning, and can export a specific historical version. The docs also recommend the n8n CLI over the Server CLI for new work and plan to deprecate Server CLI export and import, with no date set.
The docs raise several cautions for exporting and restoring. The checklist below is our summary of them.
The public API is available on Cloud Starter, Pro and Enterprise and on all self-hosted editions, but not on the free trial, so scripted JSON export through the API is possible without a Business plan, although those docs do not describe how to design a backup workflow. For Community Edition, the vendor's own August 2026 blog suggests a scheduled workflow that saves changed JSON to a private Git repository. It calls this a backup process, not a replacement for native environments, and says to test restores. We think this is the sensible middle ground for Community Edition teams, provided nobody mistakes it for environments.
Manual backups amount to downloading a workflow as JSON from the editor menu by hand and keeping the file somewhere you choose.
Sources: Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Built-in workflow history and named versions
Built-in workflow history stores versions in the n8n instance database, not in Git. The docs describe full history on Enterprise, on Cloud or self-hosted, while all users get versions from the last 24 hours and Cloud Pro gets five days. You can restore a version, clone it to a new workflow or download it as JSON.
Named versions, which n8n never prunes automatically, are available on Cloud Pro and Enterprise and on self-hosted Business and Enterprise.
Sources: View change history | Build | n8n Docs
Comparing history, review, rollback and edition
The table applies the same four criteria to the three approaches, splitting exported JSON into its scheduled-to-Git form and manual exports, and adding built-in workflow history for completeness. Use it to choose among n8n version control workflows for your edition.
| Approach | History | Review | Rollback | Edition |
|---|---|---|---|---|
| Native Git source control | Created on each push | In the Git provider, not in n8n | Pull an earlier repository state; overwrites unpushed changes | Business, Enterprise |
| Scheduled JSON export to Git | Git history of changed files, per n8n's blog suggestion | Unknown | Re-import; matching IDs may be overwritten on Server CLI import | Public API on Cloud Starter, Pro, Enterprise and all self-hosted; CLI beyond self-hosted unknown |
| Manual exports | Only what you keep and name yourself | Unknown | Re-import by hand; overwrite behaviour of editor import Unknown | Unknown |
| Built-in workflow history | Versions in the instance database | Unknown | Restore, clone or download as JSON | Full on Enterprise; 24 hours for all users; five days on Cloud Pro |
Cells marked Unknown are points not stated in n8n's documentation, not proof that a capability is absent.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
What remains unknown
Several points stay unconfirmed in the material we reviewed. Whether Community Edition keeps workflow history beyond 24 hours is not settled, and neither are the exact steps for pulling a specific older Git commit.
The Server CLI source we had was truncated, and n8n's docs label its packages as Preview. Manual backups rest on inference from the export documentation. Finally, none of this comes from firsthand testing.
Sources: Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs
Editorial recommendations
These are our suggestions, not validated results, and they follow from the comparison above.
- On Business or Enterprise, use native Git with a one-directional dev, staging, production flow and review in your Git provider.
- On Community Edition, schedule one-file-per-workflow JSON exports to a private Git repository and treat them as backup with history.
- Keep manual exports for ad hoc snapshots: name them, store them privately and do not rely on them as team history.
- Test a restore on a non-production instance and check ID-overwrite behavior on import.
Our bet is that a restore test matters more than which approach you pick, because a backup nobody has restored is only a hope.
