I’ve made it for myself, but as i’ve seen some similar questions regarding this, I decided to share it.
The idea is to develop n8n workflows locally, and then deploy them to the host with as small effort as possible. I use private bitbucket repo as a storage, so I did not bother with creds encryption yet, but will deal with it some moment later on.
Feel free to give it a shot and share feedback\suggestions:
I’ve pushed v 0.2.0 - now it supports encryption and other minor improvements.
Now the flow is even easier (the setup is the same: npm i and fill the .env with your repo data):
On the local machine, run npm run export-push - that will, well, export and push workflow+creds to the private repo.
On the host (i use remote RDP), run npm run pull-import - that will pull workflows+creds and import to the host n8n
Then just npm run n8n
There are still minor issues (i want to make it cross-platform), but in overall its looking good
Just pushed 1.0.0.
The only change is i’ve added “npm run imr” which means “import”+“run”, just a shortcut.
in overall, i’m amazed how simple workflow is now: i do the change locally, run “npm run ex”, watch how the changes are exported and are pushed to the repo, then i switch to the host, run “npm run im” and “npm run n8n” (tbh i didnt test “imr” yet - bad practice, but no one watches ) - changes are pulled and imported, and that’s freaking it!
Okay, just tested “imr” - works like a charm. For the continous workflow, “imr” is pretty useful, because it just takes you to stop the current n8n (Cmd+c) on the host, press up button to receive the previous “imr” command, and press enter to update and start n8n.
Just 2 things to note:
Sometimes there’s an error “resource is busy” during the n8n run. Just re-run the command, and it fixes the issue.
Workflows statuses are exported as well. So before the export, it’s important to enable the ones you wish to run on the host. Or enable them manually on the host afterwards, whatever you prefer.
Moved all n8n env variables from package.json to the .env. It’s a win-win, because package.json is looking much cleaner, also all envs are stored in a single place: .env file. Ah, also dropped some dependencies. So technically, its win-win-win
Anyways, just pushed version 1.3.0 (version 1.2.0 had some minor changes).
I’ve worked with this script for a while (and i found it extremely useful!) and noted something i can automate even more. I have a difference between the local workflows and the host: i need all local workflows to be disabled (i run them manually during the development), and some of the deployed workflows to be enabled (because they are finished and prod-ready).
At first, i used to enable them manually, right after the deployment. So I’ve added “[A]” to the name of the workflow, so i can easily find the ones i want to enable. Recently, i’ve got an idea to enable the workflows that starts with “[A]” just before starting the n8n on the host automatically.
Today i had some time, so i’ve implemented it. The logic is pretty straightforward, and it is fired by the new command “imar” (IMport-Activate-Run).
Updated the n8n to the current latest (0.236.2)
Updated the action script, so now it runs n8n update:workflow --id= --active=true for each workflow that starts with “[A]” (see previous message) right after the import.
Try not to tag specific members of the team, We see when there are new posts and if you want an answer to a question it is better to just ask it that way the rest of us won’t wait to see if the tagged person replies.
Ah we must lock it out after a while so I guess you would need to add another post instead as it is probably a system wide setting.
The good news is we have this exact thing coming out soon so you can make workflows on one instance, then push the workflow, credential and variables to a git repo then on your main instance pull them in.