I was recently approached by a company that wanted to sponsor adding Multi Tenant support to Node-RED. This would be to enable multiple users to run independent flows on a single Node-RED instance.
This is really not a good idea for a number of reasons. But mainly it is because the NodeJS runtime is inherently single threaded and there is no way to get real separation between different users. For example, if one user uses a poorly written node (or function in a function node) it is possible to block the event loop starving out all the other users or in extreme cases an uncaught asynchronous exception will cause the whole application to exit.
The best approach is to run a separate instance of Node-RED per user, which gives you the required separation between users. The usual way to do this is to use a container based system and a HTTP reverse proxy to control access to the instances.
Over the next months worth of posts I’ll outline the components required to build a system like I described and at the end should hopefully have a fully working Proof of Concept that people can use as the base to build their own deployments.
As the future posts are published I will add links here.
Because containers file systems are not persistent we are going to need somewhere to reliably store the flows each user creates.
Node-RED supplies an API that lets you control how/where flows (and a bunch of things that would normally end up on disk)
We are going to need a way to only allow right users access to the Node-RED editor, again there is a plugin API that allows this to be wired into nearly any existing authentication source of your choice.
I wrote a simple implementation of this API which uses LDAP as the source of users not long after Node-RED was released . But in this series of post I’ll write a new one that uses the same backend database as the flow storage plugin.
Once we’ve built storage and authentication plugins we will need to build a custom version of the Node-RED Docker container that includes these extras.
HTTP Reverse Proxy
Now we have a collection of containers each running a users instance of Node-RED we are going to need a way to expose these to the outside world. Since Node-RED is a web application then a HTTP Reverse Proxy is probably the right way forward.
Once all of the other pieces are in place we need is a way to control the creation/deletion of Node-RED instances. It will also be useful to see the instances’ logs.
Finally I’ll cover some extra bits that help make a deployment specific to a particular environment, such as
Custom node repository
This allows you to host your own private nodes and still install them using the Manage Palette menu.
Tweaking page titles and colour schemes can make Node-RED fit in better with your existing look and feel.
13 thoughts on “Multi Tenant Node-RED”
Thanks for the huge work.
I think I did a damage: I tried to update the docker custom-node-red but I can no longer access the instances I created. I believe they are still there even though I no longer see them from the manager When I try to create an instance with the name I already assigned the manager tells me that the instance is already there (even if I don’t see it in the manager app) . Old instances can be recovered?
Yes, you can recover the existing instances, but you will have change the tags on the custom-node-red images. You will need to re-tag the new version as something else and reset the tag on the version that current instances is using to `latest` (You should be able to find the current hash with the `docker ps` command). They should then show up again in the manager app.
I have updated the manager app to use labels to identify the running instances, but it will mean tearing everything down and updating the manager app and recreating the existing instances (as there is no way to add labels to running containers)
Thank you. If i wanted to update node-red to the latest version what are the steps i can follow?
There is currently no way to upgrade the already deployed instances, but the latest version of the manager app will let you build a new version of the Node-RED container and any subsequently deployed instances will use the new version
I love your multi-tenant port of nodered. I’m using this to setup a little workshop with some university partners. I have succesfully able to run this in my VM but the manager only let us to deploy one instance. Is there somewhere a limit we can change? I have not found any.
Thank you very much in advance.
No, there are no limits in place and without a lot more information about how you’ve set things up and what if any errors you are seeing I can’t offer any insight.
Blog comments are not the place to debug this, if you want help you will need to open an issue on GitHub and include full details of how you setup the components and what you did to reproduce the problem.
Just wanted to send a big thank you, Ben.