Is there some support to deploy workflows as a package? With CI/CD? Together with its secrets, that may possibly (preferrably) be defined in the environment?
Sadly not sure I understand what you mean but you can reference environment variables with
$evn.VARIABLE_NAME in both expressions and Function-Nodes.
So currently, the model as I understand it is;
- run your designer / n8n UI, build your workflow
- add secrets, they are added to the database as cipher text using config’s key
- test it, done with it
- save to json file
- commit json file to git / source control
- upon deployment, manually go in an replace existing workflows by overwriting from the git-versioned workflow-export (the json file)
- further, manually insert the secrets into the secrets database, so they are re-encrypted using the production key
A more database-centric app, Hasura does it like this https://hasura.io/blog/using-hasura-graphql-engine-with-a-ci-cd-system-9f7e87b3a0df/ — running migrations in your continuous delivery pipeline. Migrations are automatically versioned on disk. With
hasura console, they get written to the local file system as you edit your data model; a very powerful way of creating a diff. With n8n you have to manually perform an export/import and even then there’s no “migration” or “upgrade” API for the workflows that can be called during the CD step.
Finally, in our deployment, we used k8s Sealed Secrets from bitnami. It’s a very convenient model as it allows as offline encryption (and decryption if you have access to the sealer’s private key), and lets developer one-way-encrypt secrets and place them in git. These are normally attached as env vars or put as files on disk at runtime (which the other thread I created was about; how to load these secrets).
So to summarise, I’m looking for a way to automate the deployment of changes to workflows.
+1 on CICD. Let me explain
To use any kind of software in the enterprise, you need a repeatable way of doing tasks. Doing everything via the UI is problematic because there is no version control and the release process can be a big mess.
If all of these integrations can be expressed in some dsl/json and deployed via some api/sdk call, then we can store them in git and use our cicd system (jenkins, gitlab, github, circleci, etc) to create a release process around them.
Hope this makes sense.