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.