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