It would be nice to have the option to turn off autosave.
Sometimes, one plays around with different configurations and workflow changes. Before autosave, that was no problem. If you did not save a workflow, nothing was modified.
Nowadays, it is sometimes the case that it is hard to find the version in the workflow history, where a workflow was in a good state - sometimes 100+ versions in the workflow history.
Also for collaboration or learning by checking workflows of others this caused problems in our team, as workflows were accidentally modified and those changes published afterwards.
For some users, the autosave feature was helpful. Others also requested a turn-off. Maybe this could become a configuration/setting for a n8n project or a n8n instance/account.
Very much agree. I see the value, but an option to turn on/off would be great. Sometimes I want to test something and I don’t actually want to commit.
Like with github, you say when to save it so you can have stable versions and go back when you need. Autosaving every change you make would create quite the mess when changes are still being debugged/tested.
Hey @BradleyHubbard thanks a lot for the feedback, very much appreciated. I’m curious: If you have a stable version, wouldn’t you want to publish that one?
Reasons to provide the option to disable auto-save at the WORKFLOW level:
Making some experimental changes to a Workflow on a Friday, coming to work on a Monday and being unable to return to the previous original state (as the history exceeded 24 hours).
When making layout changes, the browser often hangs or has issues because it is saving every micro movement. For some tasks, like re-organizing a layout, I want to temporarily disable auto-save.
[Self Hosted, Safari] When combining multiple workflows together on a canvas, auto-save can cause the browser tab to completely fail when trying to open properties of items that lookup other items (like sub workflows).
Please just add the ability to turn it off at the workflow level so that this remains a feature for everyone and not a burden/bug for some.
Hey @umnz, thanks so much for coming back to me. Let me go over your points one by one to understand them better:
If I understand correctly that also wouldn’t be possible without auto-save? When you saved something on Friday, and you come back on a Monday, you’d still not have the version before, wouldn’t you? Or would just just keep the tab open unsaved?
This is interesting. Normally, it should not auto-save every little change, and it especially should be a resource heavy operation that hangs your browser. Is this happening on really big workflows for you?
Can you help me to understand that more? Theoretically you should always see the most current version of things like sub-workflows.
I’m running a self-hosted instance with many active workflows and heavy automation. Autosave creates serious practical problems:
Version history bloat — history fills up with hundreds of meaningless intermediate saves, making it nearly impossible to find a stable version to roll back to.
Browser performance — on large workflows, constant saving every 2 seconds causes noticeable lag and hangs, especially when reorganizing the canvas layout.
Cognitive overhead — I can no longer quickly experiment with changes knowing I can just close the tab. Every “exploratory edit” is now permanently recorded.
The Publish/Draft separation is a great improvement, but it doesn’t solve the autosave problem — it just moves the risk from “accidental deploy” to “cluttered history + browser lag.”
A simple per-instance environment variable (N8N_WORKFLOWS_AUTOSAVE_DISABLED) or a per-workflow toggle would satisfy both camps. There’s already a community PR (#25144) proposing exactly this.
I’d like to also request the option to disable this.
I’ve implemented some Hooks on Save/Publish, and now I’m buried in evaluations and notifications. Even things like moving a node a pixel. I really do want to be able to select Full Manual Save option, accepting that the user is responsible for lost work.
If we want to meet in the middle, perhaps the auto-saves can be a fork version that can be presented when I return to a workflow if I hadn’t saved. So: Make edits, each (debounced hopefully) is saved to fork, reload page/computer reboots/whatever, and there is a banner that says “You have unsaved changes from a prior session” but show me the last manual saved state and allow me to preview the changes auto-saved.
I didn’t want to wait, so I just generated my own temp solution. This should work pretty simply… but may not cover all cases. Just figured we’d share our solution as a starting point.
Totally agree The autosave makes reverting to previous states much more difficult. When I’m testing minor configuration changes to see what works, the feature saves every iteration automatically. This makes things worse when I need to get back to the original working state. We need a manual save toggle or better version control during active editing.
+1 for this. An option to turn off via UI not just ENV var would be welcomed due to the same reasons. Some times i just want to see what happens if I try xyz. I don’t need a record of it, I just want to close out and trash all the changes.
(If any n8n devs are reading this.) Could it be that the different workflow states resulting from the autosave feature are required to combine the current workflow state and previoud executions (“copy to editor”]? I have not checked the code.
Also if this is true, some states could be marked as “auto” or “human” saved. Afterwards, only the “human” saved states could be displayed in the editor.
Hey everyone, thanks for all the feedback here and the patience here.
We’re looking into the autosave experience and trying to make sure we understand the problems properly before deciding on a solution.
From what we’ve gathered, the two biggest pain points are:
No safe way to experiment - Opening a workflow to try something or just browse it creates new versions, even when you didn’t intend to change anything.
Version history becomes unusable - Too many intermediate autosaves make it hard to find the last working version when you need to roll back.
Did we miss anything? If autosave is causing other problems for you, let us know.
@umnz@kojourin - you both mentioned performance issues (lag, hangs) from autosave. Can you share a bit more? Is this happening on all workflows or mainly larger ones? Anything specific that triggers it (workflow settings, number of nodes, browser)? It would be really useful to know.
very good summary. With some insights from the to your question, it’s pretty complete. My initial request was also based on using/editing workflows in a team, where people want to check things and accidentially edit. I think on n8n-cloud, the very last version is saved and previous versions are not available anymore. So after some time, it is hard to identify the latest stable version to be used for further editing.
Hi Nikhil @nikhilkuria, happy to share more context.
The lag happens specifically on larger workflows (30+ nodes). The autosave triggers a noticeable freeze — roughly 1–2 seconds — right after any change. It’s consistent across sessions, not browser-specific (tested on Chrome and Safari, MacBook Pro M-series).
Beyond performance, my main issue aligns with what others said: autosave destroys the version history signal. When I’m debugging or experimenting, every intermediate state gets saved, so by the time I want to roll back to the last known-good version, the history is full of noise.
What would actually help:
An explicit “draft” mode where changes don’t persist until you manually save.
Or at minimum, filter version history to show only manually-saved versions by default, with autosaves collapsed or hidden unless explicitly expanded.
The core need is confidence: knowing that the version running in production is the one I intentionally saved, not some mid-edit autosave.
I think the main issue is not autosave itself, autosave is useful protection. The real problem is when autosaves create noise and make version history harder to trust.
What would help most (in my opinion):
Autosave as a safety net : prevent losing work during editing
Manual checkpoints / milestones : user-triggered saves with optional names like stable, before refactor, prod working
Cleaner history view : collapsed - hidden by default, manual saves highlighted
Easy rollback : one click restore to the last intentional save
As a temporary workaround, one habit that helps a lot is downloading workflows with versioned names before big changes
for example:
crm_sync_v3_stable.json
invoice_flow_before_ai_edit.json
It is not ideal compared to native versioning, but it gives an extra backup and safer experimentation.
So for me, the best direction is not disable autosave , but separate recovery saves from meaningful version milestones
