Hi,
we need ro run some workflows in an isolated network. I’d like to know if n8n provides a distributed architecture, that allows to execute workflows via a distributed worker/proxy.
For example we need to connect to a service API that is available only from the inside, but it is not available from the outside.
The idea is to have a worker inside the isolated network that executes the workflow configured on the main n8n engine.
Is there some kind of architecture that could allow us to do suche a thing?
Thank you
In theory you can run workers from anywhere as long as they can access Redis and Postgres the tricky bit here though is you can’t set workflows to run on certain workers. You may be able to use env options that are checked when the workflow runs so it knows if it needs to run it or not but that won’t put the job back in the pool to be picked up again.
Hi Jon, thanks for the quick answer,
the fact is that we have our customers that have their assets in isolated network, in our datacenter or in on-premises infrastructure.
We often don’t have access to the border firewall appliances, so I was wondering if there is a way to manage the dialog making it happen from the inside to the outside, instead to allow n8n to contact the resources from the outside.
A use case is to open or close the traffic for an Ip address in a Fortigate firewall, using the fortigate API. those API are not available from the public internet so we were thinking about the possibility to have a probe inside the customer network, to do the job (if you know zabbix, something similar to the Zabbix proxy).
Thanks in advance
Maybe I didn’t get it, but it seems that is exactly the thing that I would like to avoid.
I would like to configure (and run) the flow on an n8n instance, located in my DC, and run that workflow in an isolated environment through a proxy/something.
Installing a dedicated instance shourl work, but in my understanding this means that, to confgure and run the flows, I have to connect to the UI of that specific instance.
The same to check the workflow results.
Ok, now I get it…maybe I have to clarify…
I’d like that it is the worker connecting to the main n8n installation, not other way round.
In this way I have not to bother to configure incoming firewall rules in the “isolated” network from the outside, to reach the worker, but it should be the worker to connect to the main n8n server (and, in my understanding, I can’t tell to a workflow to run only on a specific worker).
I’ve worked in the past with other technologies, such as Morpheus, Resolve, Zabbix, that supports this kind of configuration.
thank you for your answer
In a worker setup the workers talk to Redis and Postgres rather than the main instance directly so that part isn’t really an issue if you have the outbound routes in place.
Having a standalone instance is probably the best option though and it solves the issue, If you needed to access the web interface for that n8n instance you could use a cloudflare tunnel so you only have outbound ports opened or use a VPN if configured.
Ah so. As of now there is no such design in n8n. Maybe it will work if your specify the custom env on the dedicated worker and in the wirkflow there will be IF node to check against that env var. but I don’t know how to push the execution data back to the redis queue. Plus that method is not very reliable
Hi all, thanks you all for your kindness…
I think that the vpn solution should work, letting me to connect to the assets from the inside of the network.
Another question, related to the licencing…what if I have 1 main instance on n8n and another n instances (with n = number of customers).
Should I get a licence for all the instances that I’m going to install or I’ll be billed only for the active triggers?
Thank you again
About the setup, as @Jon said, the workers are the ones actively connecting to Redis and Postgres to “pull” jobs from the queue, so as long as you can place the workers in a network that can reach Redis and Postgres, you should be fine.
In terms of licensing, I don’t really know, you should talk to the sales team in this case to find the best solution for your use case.
Ok, I got it, but how can I select the worker?
For example, if I have a main n8n instance and 1 workers, one deployed in the network of customer 1, one in the network of customer 2, how can I tell to the main n8n instance to run a workflow only on the worker 1?
thanks in advance
Ok, and this is in the case where I have only one worker… but what happens if I have 1 engine and n workers and I want to execute a workflow only on one of them?
If I understand correctly, by setting IS_INTERNAL = true, I instruct all the workers to execute the workflow locally…
What if I tried to give a name to each worker, in an environment variable, like WORKER_NAME = fancy_customer_name and set the “if” node to check the value?
In this case, the workflow should only be executed on the node that has WORKER_NAME equal to the one specified in the if node…
Am I wrong?
As far as I understand, however, the workers don’t each execute all the workflows, but the execution of the workflow is balanced among them… what happens if, in my example, a workflow for WORKER_NAME = “Walt Disney” is executed on the node that has WORKER_NAME = “Pixar”?
Does the workflow simply not meet the condition and stop, or is it eventually executed on the correct worker?
It is not a good idea to try and run a workflow on only one worker as mentioned, If you were to try and use env options then check the option in the workflow when the workflow runs it will fail then on the next run it may work or it may fail depending on which worker picks it up. If you had 2 workers and no other worklfows there would be a 50% chance that the workflow would run on the schedule and this gets lower as you add more workers and workflows.
The offical advice on this is to deploy 2 instances of n8n, One for the internal and one for everything else.