Version control workflows [GOT CREATED]

Feature Requests (done)
1

A feature that would be useful is to deploy workflows using git, this would help with version controlling the n8n node changes.

2

After a bit more though, it would be really good to script the workflow and automatically convert the script to Json that could be loaded into n8n, this way users can create work flows either via the UI or using JS scripts.

3

Not exactly sure I understand what you mean but a user created a workflow here which automatically backups and versions n8n workflows:

1 Like
4

What I mean is be able to use javascript to set the options for different n8n nodes and have the option imported into n8n.
Example code :

webhook.url = "www.example.com"
webhook.method = POST

httpRequest = webhook.response == 200 ? submit

the example code would create 2 connected n8n nodes when you imported the code into n8n.

1 Like
5

Hey @jan!
I also think that this is a great feature to have.
The general term would be “Infrastructure as code”.

Let’s assume we buy into n8n more deeply and build our backend with it. We want to be able to

  • track the changes in git,
  • redeploy all workflows in case of disaster
  • safeguard against unauthorized changes
  • etc

A typical example is that you can build e.g. your cloud infrastructure in aws with the editor but you can also use cloudformation or terraform where you would describe the infrastructure with code.

I think what would be needed is an API endpoint in n8n which can be reached programmatically and (probably) does the same es a normal “paste”. (The command to copy example workflows into n8n)

Does this make sense?

3 Likes
6

This is interesting and powerful

1 Like
7

Hi all! Max here, product designer @ n8n.

Just wanted to let you know that workflow versioning is on our radar as is the potential for an n8n endpoint to CRUD workflows. I say “on our radar” as we’re currently looking at various potential features and doing research on what makes sense, as some of these features might be more intuitive if developed in tandem (for example workflow versioning + dev/prod environments).

On that note, please do keep upvoting and sharing ideas/ ideal requirements for a workflow version control feature. Your insights really do help inform the design + spec of these features :slight_smile:

4 Likes
8

So this would be so useful for a few reasons! A lot of organisations and teams have similar workflows for similar purposes, to the extent that pre-configured workflows could be usefully saved and shared and archived for later re-use — this is already solved by sharing JSON files.

However, changing an organisation’s infrastructure means changing their pipeline but what if another organisation comes along with an ‘old’ infrastructure setup and wants to use the old pipeline? Looking into the version history would help here. A lot of orgs don’t know about version control systems like git. My org works with lots of volunteer community and activist organisations to who the above apply.

For example this thread would be even better if there was a link to download and set up this config on your system but even better if there was a specific “commit hash” / version ID to link to, in case later on this workflow changed but no longer matched the documentation in that thread.

Here’s another usecase, which sprung to mind whilst talking about the inline notes feature in another thread: it is easy to break something with workflows. You want to test a change, or you make a typo, or whatever happens. Maybe you didn’t set it up and don’t really know how it works. Something bad will inevitably happen at some point in this workflow’s lifecycle. It’s really important to be able to rollback if something goes wrong, and a version history helps you to see when (and possibly how) things went wrong.

5 Likes
9

I wonder if a useful aspect of this feature is enabling admins to understand, at a glance, the state of their workflows. Like git commits have a message to help explain this. With integratoon workflows, often the change is in response to the infrastructure changing. You have a webform and a data store (database/spreadsheet/CRM with custom fields). The fields in the form and/or the columns in the datastore change and/or the tool/platform is replaced and you want the workflow to change appropriately so things stay smooth. It would be useful to note that this has happened in the version history, and for the current version to very clearly state that is the case.

Zapier goes one step to expose the state of your workflows by showing which nodes are in the system as little icons, so you know that it is Typeform wired up to Airtable for example:

Captura de Tela 2021-01-13 às 12.43.15
Captura de Tela 2021-01-13 às 12.43.151524×756 55.5 KB

In n8n’s case, it would be nice if it was a bit more obvious how long ago something was updated — maybe “Last updated a few hours ago” instead of a timestamp — and if I could quickly read a remark by the editor who “switched Airtable to Typeform and piped the extra field data for Gender to the Google Sheet”. Seeing that, I could rest easy knowing my high volume of form submissions are being handled appropriately.

Captura de Tela 2021-01-13 às 12.44.11
Captura de Tela 2021-01-13 às 12.44.112690×548 46.5 KB

(Bonus points if this was all synced direct to Github via their API, like how codesandbox.io backs the entire project to a repo :wink: There is something fundamentally useful about being able to branch, PR, create and reference issues, and log changes to workflows. Being able to tweak something via the code if you so prefer, in VSCode, pushing to master and having it deployed is very natural for developers but whether that’s your target userbase is another question.)

3 Likes
10

Is there any update on this? As a software engineer not having any CI/CD and any versioning at all is quite intimidating and feels very limiting tbh.

Also, is there any public roadmap?

1 Like
11

Would love to know as well if there is a public roadmap on this. We do have dozens of workflows and when we change half of them in DEV and deploy new code to production, it is very laborious to manually copy/paste workflows and make sure nothing was forgotten so they match the incoming updates of our platform. Then, if there is a need to roll back, well… let’s not even talk about it. :smiley:

It is also unfortuanetly currently impossible to put some code in production and have the updated workflow up at the same time, so there has to be downtime on every update with breaking changes.

1 Like
12

We are currently using it for a small project and see how it works out with our projects. We would love to have a versioning somehow … it feels kind of freaky without it :ghost:

13

I’m digging this topic for 2023 :slight_smile:
@maxT how’s the radar doing about this ?
We are considering n8n with my team but the inability to work in a dev/prod scenario and having dev/feature branches is clearly a blocker for us :pensive:

@Adrien’s comment about copying/pasting manually changes from one instance to another is reawakening old nightmares (PTSD even) of having done this earlier as a newbie to no avail…

Please let us know if you are working on this or if it’s still a dream feature that you can’t prioritize for now :slight_smile:

And of course this message is to be taken as a compliment for the very good job that you have done at n8n so far, I just feel like I’m having to give up 100m before the finish line :sweat_smile:

2 Likes
14

@SylvainRoquebert first off, thank you for your kind words on n8n. Don’t give up at the 100m mark… we DO have version control coming :point_down:

  • It’s part of an upcoming “Environments” feature.
  • That feature is currently being designed, and so is very much on our immediate roadmap. It’s one of the bigger projects at the moment for one of our squads.
  • Since it’s being designed, I can’t share an exact specification. However, it’s ultimate goal is to give you the typical dev experience you expect: dev, staging, production + separating data / credentials in each environment. It even has an environment variables concept, which can be referenced in your workflow (for example, a URL_ROOT variable that is different in dev vs. staging).

Tagging @romain-n8n here, his squad is heading up this feature (in case there is something to add that I forgot).

1 Like
15

Hi @maxT, that’s lovely news !
Are you in capacity at this point to give a rough estimate for a beta phase on this feature? We would gladly help you testing it !

16

Just to be very upfront about this. The environment feature will not be part of our free community version but rather only available paid.

1 Like
17

Hi Sylvain!

Thanks a lot for your interest and willingness to help on this important feature.

We are just starting user tests next week so the timing is perfect and we would love to get your feedbacks and ideas.

You can book a slot here and if you have time to answer this 5-min survey as well beforehand.

Best,

Romain

2 Likes
18

Hi @Max_T, just wanted to know if we can expect a release with workflow versioning and env management features in the coming weeks / months. We are thinking about doing the workflow versioning feature on our side these days, but depending on the release date, we could eventually wait for it.

19

Hi @dev_guy, we plan to release the first version of the environments feature on the Enterprise plan in the next couple of weeks.

20

This will allow you to version your workflows by manually pushing to Git. A feature to automatically version workflows each time you make changes, plus restore them when required is slated for Q3.

1 Like