Announcing Autosave!

Announcements
1

Autosave is finally here.

[UPDATE Jan 13, 2026]
Autosave beta is live - read all about it here:

—–

TL;DR - Autosave is coming next week.

Autosave has been one of the most requested features in n8n history. It’s been on our roadmap for a long, long time. As we sat down to build it, we realized that Autosave is part of a much bigger challenge that we needed to address:

Providing a complete Workflow Development Lifecycle in n8n.

To do that, we needed to ensure that building a workflow follows the same safe principles as writing code: safe edits, versioned deployments, and collision-free collaboration. If we had simply added Autosave in the version 1.x architecture, every change would have been pushed to production instantly. Not a great idea.

Step one was adding the ability to publish a workflow with the v2.0 launch, decoupling the published (live) version from the latest saved version. By separating the “Saved” state from the “Published” state, we created a safe environment for editing and iterating on workflows without affecting the published version.

This new paradigm provides Versioned Publishing and easy rollbacks, capabilities often considered table-stakes for deploying mission-critical workflows.

With that in place, we can now finally add Autosave to n8n.

→ It’s coming out in Beta next week with version 2.4.0. ←

Here’s how it works:

1. The “Save” button is going away
Starting with version 2.4.0, the UI does not have a Save button anymore (R.I.P. Save button), and pressing control-s doesn’t do anything.

2. Autosave is always on
While editing a workflow, n8n checks for changes every 2 seconds. If a change is detected, it will automatically save it. Because we previously decoupled saving from publishing, this is now completely safe. Your auto-saved versions will not go live until you explicitly hit “Publish.”

3. Concurrency Protection (better collaboration)
If you open a workflow that a teammate is currently editing, n8n will alert you and place the workflow in Read-Only Mode. Your canvas will now update as they make changes.

This ensures you never accidentally overwrite a colleague’s active logic. Once they are inactive, the lock releases, and you can pick up exactly where they left off.

4. The “Publish” Button & Instant Rollbacks (launched with version 2.0.0)
If you haven’t upgraded to v2.x yet, this is the most important workflow change to note. Since Autosave does not impact the live version, you must now explicitly click the Publish button to make your changes live.

You can also select a previously published version from your history and click “Publish.” This effectively gives you one-click rollbacks, allowing you to revert production to a safe state instantly while debugging the latest version in the editor.

We wanted to share this context with our community members early so you aren’t surprised when the Save button disappears on the next Beta release. We’re excited to finally bring you a workflow lifecycle that is safe, collaborative, and auto-saved.

A Note on Beta
Changing the fundamental save logic is a complex shift, so as with all Beta features, please avoid using this on mission-critical production instances until the Stable version is released.

Questions?
Please leave them in this thread.

14 Likes
2

Wow! Versioned Publishing! Christmas came super early! :christmas_tree::rocket:

4

Auto save is Amazing !!!

But the real killer feature here is the collaboration.. FINALLY !

Thank you for your work :folded_hands:

2 Likes
5

Great news!

After the v2 upgrade, the difference between Save and Publish was a bit confusing, this Autosave feature makes a lot of sense now,

A question: since Autosave will check every 2 seconds for new changes (which includes something as small as moving a node), does that mean the Version History will be filled with a huge number of versions? Or is there additional logic or settings to manage this?

Looking forward to trying the new release..

1 Like
6

This is great! Thanks for this news :star_struck:

7

You will see more versions in your history, but we’re also introducing a new clean up service that removes old workflow versions based on a few criteria.

The current iteration operates once per hour on versions saved between 1 and 3 hours ago and acts as follows:

  • Never delete a version if either:
    • the next version is by a different author
    • is named (meaning it was published at some point)
    • more than 20 minutes passed between the two versions
  • Delete an old version if the new version is a superset of the old version, i.e.:
    • it contains only new nodes/connections
    • all non-string parameters are equal
    • each string parameter in the new version .contains its previous iterations

These are chosen very conservatively atm, prioritizing not losing data over saving storage space, and we will likely tune these and introduce more aggressive logic targeting older versions in the future.

Some of these values will also be configurable for self hosted users via env vars introduced in the workflow-history-compaction.config.ts file, and there is a new log scope workflow-history-compaction which logs how many versions were deleted for each workflow.

I’ll also make sure this is added to the docs.

If you have any feedback here please let me know!

4 Likes
8

Excellent improvements, a little strange at first but really useful.

I would highlight more clearly when a workflow is not published or when it has been modified but the changes have not been published, perhaps with a timed message for those who keep the window open and a pop-up before it closes or exits the workflow.

9

This appears to be a bit of an issue for the n8n template site, you may want to turn it off there:

image
image377×275 16.3 KB

10

Is it possible to turn auto-save off? I often have team members ask for assistance on their workflows. I’ll go in and look at previous executions and play around with their workflow and make changes WITHOUT saving to see if I can get it to do what they need. Generally, if my solution doesn’t work, I just leave the page without saving, restoring it back to that user’s original version. Now I can’t experiment or add to a workflow without overwriting my changes. I would have to dig through a bunch of different versions trying to find my original. We would like to upgrade to fix the recent vulnerability, but I’d really like to be able to turn auto-save off.

6 Likes
11

Hey all,

I tend to be more frustrated than benefitting from this autosave. Kudos to the team for shipping regularly, but I think that’s one poorly executed feature.

Attempt at providing useful feedback, speaking for the self hosted version:

  • Autosave seems to fit modern behavior, for example Google docs, antigravity, miro, where users are no longer looking for the floppy disk icon. Great, n8n joins the band.
  • Super useful when your self hosted n8n stops responding because you’re also playing with networking at the same time and get a 403 when clicking the save button after having made substantial progress :grimacing:

Where I thing the execution is poor and why:

  • In my examples above, users see almost all changes on the screen. Plain and formatted text are fairly easy to spot the last edit.
  • Both also come with a thorough history of changes. Google docs comes with a one click restore at a point in time. I find it well designed as a user can navigate though a timeline of edits. Similarly for autosave code editors, git is super reliable, in saving committed changes, stashing, and most importantly showing the diff.

N8N’s ways of iterating on a worflow are unique and fairly remote to my examples above, yet what the users are trying to achieve is the same:

  • Experiment, tinker,… until a satisfactory solution which can be saved
  • Document their progress
  • Deploy when a solution is ready for production (‘publish’)

And that’s where I find the feature lacks refinement:

  • A N8N workflow can be edited with a lot of subtle changes. For example, enabling ‘always output data‘ on just one node can lead to a widely different behavior. Yet it’s hard to spot, and with dozens of nodes on a WF, when iterating, it’s hard to remember what was the status of each node (kudos to showing the tiny icons inside nodes btw) before tinkering. Of course, iterating on a {{}} value is even more invisible to the user when on the full WF view.
  • As others commented, when developing a WF we often do a lot of subsequent tiny changes : edit a code node, run WF, then edit the pinned json on the webhook node, run WF, edit another node, run WF, realize we’re debugging the wrong thing, we want to reset to the last stable version. Which is not necessarily the published versiom. So now what? How many ctrl-Z should we do?
  • As an autosave user today, even if I make good progress that I deem stable, but decide to not publish, I’d like to know how different is the saved version versus the published version when I open the WF page in 3 days. No way I’ll remember my changes and no way they’ll be obvious.
  • The self hosted version only retains 1 day of history of published workflows. That makes the autosave vs publish a very little value-add IMO. Can’t work with n8n like I’d work on a Cloudflare undeployed worker or on a git branch.

Right now, I’d disable autosave if possible and rely on my ctrl-S or click-save reflex, which I do whenever I know I made one stable step forward, otherwise I page-refresh. I think the autosave is a good idea but needs to be improved with a UX that understands the user ways of working. I think here a ‘create checkpoint (aka the old save) ‘ and a ‘show diff‘ equivalent are needed. The later being a very interesting UI challenge :slight_smile:

I hope that helps, and genuinely wonders how the community sees this feature, maybe I’m just nostalgic of floppy disk icons.

5 Likes
12

”Auto-save” is great if we also have “Undo” feature.
It may be a bit manual but I think it is better then “None Auto-save” that you can’t back to some previous steps”.

Currently, You can undo by the feature “restore” in the history. You just need to restore back to the time that you open the workflow.

Of course, a flag to temporary turn off Auto save or an “undo” button will be better.

13

Hey @jb8n, thanks so much for the detailled feedback. The team is currently working on a follow up feature to save “named versions” on top of the auto-saved versions. This will allow you to see (and name) all the important changes you’ve made in the past and also enable you to quickly roll back to those. Additionally, we’re also working on a diff feature to show quickly what changes you’ve made.

Currently, we’re thinking about only making this feature available on pro and above plans, as it feels like it’s closest related to “running workflows in production”. Would love to hear your thoughts.

1 Like
14

Not a great way to use the autosave feature

How about the edge case where we’re editing a live workflow and only want to release a version after doing changes at multiple places, which might take an hour of work?

Having a way to disable it feels necessary.

It’s great when building a workflow from scratch, how many times did I loose all my work
But editing existing workflows requires more precautions.

3 Likes
15

This comment is also very useful.

You’re mixing up drafts and deployments, you’re solving an issue while adding another.
The main issue was lost work, now we’re having another with is silent unwanted deployments.

You need to split the two, we must have autosave, but not autodeploy.

image
image1572×762 78.3 KB

1 Like
16

@Vadorequest

I think there is some misunderstanding going on.

Autosave is NOT auto deploy.

In order to push a workflow to being the live version, you must Publish it.

Please check out the blog here with more details and let me know if that clears up the confusion:

1 Like
17

Awesome, thanks for clearing up the confusion.

18

Hi @Niklas_Hatje, thanks for reading and good to hear the team is iterating on it. I love n8n and don’t doubt you’re working on the right things.

Happy to share my thoughts, while hoping you have time for doing user interviews/research/shadowing :slight_smile:

I will most likely remain on the free self-hosted edition, and understand n8n would want to monetize nice-to-have features that are costly to develop or with operational costs. In that case, it’d be nice to keep the community edition fully functional but manual (e.g. an env flag to disable autosave and have a manual save button), rather than implementing by default a semi-functional feature (e.g. forced autosave and rollbacks artificially limited to 24 hours despite having all changes in our own sqlite3 file) that is only valuable when becoming a paying user. Unless that’s the growth plan eh eh … I wish you can afford to keep maintaining a community edition while growing the business.

19

Like others have mentioned, this is a poor implementation of an autosave feature, and at a minimum there should be an option to toggle autosave on and off.

2 Likes
20

has anyone found a way to disable auto-save?

3 Likes