tbh i didnt like the autosave feature, how can i turn it off and use the old and manual saving mode on my workflows?
2 Likes
I created a request to have an option to disable Autosave:
3 Likes
Hey Green. Any information on what’s poor for you? We’re currently working on a “revert” feature as well. Would love to get more information
@jb8n we’re def. not doing this to earn more money but more to align with our existing plans. Currently, roling back to any version you ever saved is something that would be needed for production use cases and also wasn’t possible before auto-save. I’m not saying that we rule this out, but I’d love to understand understand fully how these things you mentioned were possible before auto-save? (besides not saving while you debug a bit)
I would like to reinforce the request to introduce an option to disable autosave.
The logic of creating a new version that is only published manually makes sense. The issue is that this version is being created automatically, regardless of the user’s intention.
In my case, around 90% of the time, the changes are exploratory or temporary and end up being discarded. With autosave enabled, these changes always generate a new version, which then forces me to revert it. This creates unnecessary extra work — whereas previously, I could simply choose not to save.
Even minimal changes, such as adjusting the position of an element, automatically create a new version. The versioning functionality is useful when intentional, but it loses value when it is imposed.
It would be important to allow users to choose between:
-
Creating versions automatically (with autosave enabled)
-
Creating versions only manually (with autosave disabled)
This would return control to the user, reduce rework, and improve editing efficiency. At the moment, for my use case, the process is heavier than it was in the previous version.
I have seen that there is already a pull request related to enabling this deactivation. Could you please provide an update on its status or move it forward?
1 Like
OK.
I mentioned a lot of “things”, feel free to ask again if the stories below are missing your question 
My user behavior:
Revert to previous saved version (before autosave)
I don’t think it was possible. If it was, I didn’t use it. The history (as far as I can recall) has always been retaining only the last 1 day of productionized WFs.
I would iterate on a WF, execute it multiple times as a test etc, and:
- happy? → save it
- unhappy? → refresh page if I went too far, undo the latest changes if I remember them, or close the page and forfeit everything.
Revert to previous saved version (after autosave)
I’ve not used it so far. The autosave hash and timestamp doesn’t inspire trust, as I don’t know what’s in there, and why does it exist. I initially gave a name to versions when I would publish them, but since they only last for 24 hours, I now don’t bother naming publications and documenting my changes.
It has enabled a slightly increased peace of mind, that if I get away from keyword while working on a WF, i know my current work is safe. But this slight increase in peace of mind is offset by the discomfort of opening a WF and seeing the yellow dot with “New changes to publish” when I actually don’t remember what I did last and why I didn’t publish it last time I worked on it.
With autosave today, I basically try to have as little work in progress, i.e. I try to publish a change as soon as I am satisfied with it. So my behavior is actually identical to before autosave.
After autosave, I also tried the “Open this version in a new tab”, but I didn’t immediately understand what I was looking at, which WF would now take precedence in autosave, so I kept my old habit (read below) of comparing one tab with the editor to multiple previous execution tabs.
Backups and restores (before autosave and now as well)
Several actions to protect myself from screwing up too badly:
-
For some workflows (the ones without a scheduler), I save successful executions on top of error ones. I do have a .env setting to prune it after 15 days, but that still gets me 15 days of history, with the configs of all nodes. Not easy to restore, but allowing me to look back, answering the question “hey, wasn’t that node behaving differently last week?” (I’d like to have a “selective save execution” feature, that would decide whether an execution is worth saving depending on the start node, depending on a variable value at end of the WF, etc, but that’s whole different topic)
-
I do backup the sqlite file on a schedule. Never tried restoring it, count it as a backup that may fail at restore.
-
WF cloning: When I have a workflow that works well, and want to make a major iteration on it, I clone it, name it with some kind of semver, use the same webhook root URL with
-betaappended for example. Then migrate the traffic by renaming the webhook URL if it’s a webhook -started WF.
Diffs and debugging (before autosave and now as well)
-
I also push the WFs to a github repo via a n8n WF. Set it up a long time ago and has been a poster workflow of n8n’s reliability so far. Since it’s JSON, git works well showing the diffs. TBH I’ve rarely used it. It also gives me the comforting illusion that I have 2 backup solutions, untested at restore, and that it’s maybe worth 1 backup solution tested for restore …
-
OTOH, I often open multiple tabs of n8n at the same time, one on editor mode and multiple ones on execution modes, and look at differences. That works well on 2 monitors. Probably not good to have 2 editor tabs of the same WF open at the same time, I think I screwed up some things at some point. Writing this makes me think … what if we were able to scroll through all past executions of a node, directly from that node itself (in editor mode or from 1 execution view), and seeing all the previous {inputs, outputs} pairs from saved executions in one click/keypress, in the same tab?
I’m also experiencing the "missing execution green lines " bug (reported a few times here but discarded) that makes it harder to debug visually, but that’s another topic.
Hope that helps. All the best!
1 Like
Very GOOD news ! I was tired of typing CMD+S. As a developper N8N was the only tool that didn’t contain auto save feature.
For those also not liking this autosave, 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.
For those looking to disable autosave — I opened a PR that adds an env var (N8N_WORKFLOWS_AUTOSAVE_DISABLED=true) for this. Manual Save button comes back when disabled.
Hoping it gets picked up for review soon 
Is there a way to disable autosave?
How can we test changes without saving?
Any update on this?
Not yet — still waiting for their review.
Hi Ophir, this is a great update in my opinion.
Autosave itself is very helpful because many builders forget to click save or lose progress when the browser crashes. Having autosave every few seconds makes the workflow building experience much safer.
I also think separating Saved and Published versions is the most important improvement. It allows developers to experiment and edit workflows without affecting the live production version. That’s a very good practice, similar to how software development works.
Versioned publishing and easy rollback are also very valuable for teams running critical automations. If something breaks, you can quickly revert to a stable version.
Overall this feels like a big step toward making n8n more reliable for professional and team-based workflow development.
1 Like
great, sounds good on me!
I’m a noob and have chosen the only solution for myself: staying on version 2.3.4, which hasn’t yet enabled the autosave feature. I hope they come to their senses and I’ll be able to update someday.
After initial enthusiasm, I began to see the limitations of this implementation:
Opinion from those of us who have a self-hosted version:
Auto-saving is OK, but:
- Too many automatic versions, currently of little use and usability, requiring a review of the algorithm.
- I need to be able to explicitly “tag” and name a version (as Google Docs allows) and eliminate the 1-day history limit for these versions (otherwise).
- Implement an environment variable to disable auto-saving if desired (it depends on your workflow; for example, I often test an existing flow for debugging purposes, but I don’t want to save the changes. Currently, this is more complex and riskier).
Is there a plan to add an environment variable to disable autosave?