Multi-tenant Node-RED

Core Development
1

Is there any appetite for enhancing the Node-RED runtime to be multi-tenant? Some notion of capturing a tenant identifier through the authentication subsystem, and passing this tenant identifier through to the storage API to allow storage by tenant and only fetching/seeing the flows for a particular tenant?

Would a contribution in this vein be welcomed, or is this a non-goal of the framework? Are there other aspects to consider?

Thanks for reading

2

To some degree it already is.

For example you can run up many (not sure how many - probably system limited) instances on 1 server each with their own flows etc.

Its a simple case of...

  • node-red -u /node-red-1880 -p 1880
  • node-red -u /node-red-1881 -p 1881
  • node-red -u /node-red-1882 -p 1881
  • ...
  • node-red -u /node-red-1899 -p 1899
node-red -?

Node-RED v1.0.4
Usage: node-red [-v] [-?] [--settings settings.js] [--userDir DIR]
                [--port PORT] [--title TITLE] [--safe] [flows.json]

Options:
  -p, --port     PORT  port to listen on
  -s, --settings FILE  use specified settings file
      --title    TITLE process window title
  -u, --userDir  DIR   use specified user directory
  -v, --verbose        enable verbose output
      --safe           enable safe mode
  -?, --help           show this help

Documentation can be found at http://nodered.org

unless there is some other aspect i am missing?

1 Like
3

Hi @bvitale

there are lots of complications to making the runtime truly multi-tenant.

Making the storage API tenant aware and only returning a given user's flows is probably the easiest part to solve.

The hard parts come when you look at how to properly isolate the running of individual user flows. You have to deal with 'noisy neighbours', you have to make all of the context handling tenant-aware. If a user installs an extra node, does that suddenly appear for all of the other users?

These are all solvable problems, but it would take a lot of work to do properly. On balance, it hasn't been considered worth the disruption and effort when there are other viable options such as providing a runtime per-user and managing the orchestration of those runtimes outside of the core of Node-RED.

6 Likes
4

Especially as nodejs itself is single threaded. If anyone uses a sync function to block the thread it would block all users. Probably not a good idea. An instance/thread per user would be safer.

2 Likes
5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.