My project for controlling a pump is taking shape more and more. Currently, I am using my Raspberry Pi and NODE-RED to read data from the pump via Modbus and send it to my MQTT broker, which is located on my Linux server. At the same time, I can also control the pump by subscribing to individual topics.
Now my question is, since I want to control the pump from anywhere (outside the network), my current solution is to have a NODE-RED program running on my Linux server, where the MQTT broker is located, with a dashboard that subscribes to the individual MQTT topics. This allows me to read and control the individual MQTT topics via the dashboard. Everything works fine so far.
However, I am considering making this feature available to customers as a service. For example, one customer may manage three pumps, while another manages three others. NODE-RED unfortunately only offers the option to create one dashboard. I would like customer A to be able to log in and only see and control their pumps. The same for customer B and so on. I think this might be difficult with NODE-RED. What alternatives would you suggest? I have read a bit about Grafana. It should be possible to subscribe to MQTT topics and read and manipulate them with Grafana. I would prefer to stay with NODE-RED, but I see the dashboard-user dilemma. I would appreciate your thoughts.
There are multiple ways to do this with Node-RED. Possibly the simplest would be to use multiple instances of Node-RED, 1 for each customer. Assuming that the flows for a customer would be relatively simple and probably all the same flow with some different config? Then you would likely want to front the instances with a single reverse proxy using NGINX or similar. You can do the authentication and authorisation there, on one place, rather than messing with multiple Node-RED user configurations.
A reverse proxy would, for example, allow you to forcibly only allow customers to access a particular set of URL's. It would also hide the port numbers from the customers which is a lot more user friendly.
You could even extend the logging of the proxy to allow usage-based restrictions if that was desirable.
Well, it can't be denied that Node-RED lets you get started really quickly. But if you were scaling to hundreds of users, it might not easily scale very well. Then it would be worth thinking possibly about getting someone to translate your flows into a dedicated Node.JS app.
The main downside of that would be having to re-engineer the Dashboard.
It certainly is possible - though that isn't really its strength. But it works just fine. And of course, you could keep your flows in Node-RED.
A lot depends on your user interface though. How complex is it? Would it be easy to move away from Dashboard?
There is no easy way out of that other than either using multiple Node-RED instances or moving off Dashboard.
Dashboard is a single-page app (SPA) so all the data is there and trying to limit access isn't really anything other than security theatre.
You could use uibuilder though which gives more detail about user connections and so lets you build custom authorisation or authentication. I'd still recommend using a reverse-proxy to do the authentication though. However, since you can have any number of instances of uibuilder nodes in a single instance of Node-RED, it would also let you stick with a single node-red instance which would probably reduce server resource and configuration overheads. You would have to re-engineer the Dashboard of course though.
thank you very much for the detailed answer. realy appreciate it.
Yes the flows would (only a little modifications) be kinda the same. Only the subcribtions of the MQTT would be different and so other small modifications.
Well. i kinda knew that you can run more instances at once. kinda...
Do you mean i can run multiple in instances like this.
Start in the shell:
node-red costumer A
node-red costumer B
So i have now multiple instances running and so multiple dashboard? Whats the URL for them? Now its just IP:1880/ui
reverse proxy using NGINX or similar
I will def. look into it. thank you
A lot depends on your user interface though. How complex is it? Would it be easy to move away from Dashboard?
well its not that comlex. 12 drobdowns, 1 form and number and textfield for visualize the data. and a bit of alarm-logic for an email. thats it.
I am still unsure if staying at node red (with your tips) is the best choice. From my gutfeeling it is the simplest and "cleanest way" but maybe not the best performing one. Its hard for me to estimate how "strong" a server has to be and how much instances can run there without trouble. right now i own a VM linux, 2 CPU, 2 GP RAM, 100 gb Discspace.
Sort of, the docs have the details of the correct parameters. However, you would be better off using systemd to manage them as it will keep them running and oversee the logs, etc.
Yes. Each one is the same IP but has to be a different port.
If you use my suggestion of a reverse proxy though, you can hide all of that. Each instance will still need a different port but to the end users, all they will see is something like https://domain.name/customername1/ or whatever you want.
That should be easy enough to translate over to uibuilder if you wanted to stick with a single instance of Node-RED.
Well, at some point you will need to make a decision based on what your customers are prepared to pay. If it is reasonable, it should let you increase the size of the server should you need to.
That should be fine to run a single instance of Node-RED with several customer web pages via uibuilder (which is likely to be rather less of an overhead than Dashboard anyway), Mosquitto (for MQTT), NGINX for the reverse proxy with an extension to support the logins and the mandatory local OS firewall. You probably also want fail2ban as well. With a single instance of Node-RED, it should be fine to run some reasonably complex flows. Not sure I'd want to run many instances of Node-RED on that though - but I've not done it, perhaps someone else can chip in if they have. You might also consider running Telegraf on there to capture system metrics and forward them to MQTT. You will also want something to update your digital certificates for HTTPS.
Is node-red the "best performing" service? Absolutely not since it has to carry all the overheads of being a general-purpose compute tool. But is it worth that overhead to save the resource costs and overheads of using a custom node.js or other type of app? Only you can answer that but I would normally guess that unless you have tame developers already on the payroll, the costs of boosting the VPS would be a lot less than the cost of a developer. Node-RED would also get you to market quicker.
Don't forget that you can always move the logic to a dedicated app later on. Maybe once you have some customers so that you have some income.
Oh, and one last word of warning. If you are offering a paying service to customers - especially if that service is controlling real-world equipment. DO NOT FORGET THE SECURITY! Getting that wrong is a sure-fire way to end up on the wrong end of a law suit.
Thank you again for your contribution. As I understand it, you would suggest that the option with the uibuilder is the best? I have been working with the uibuilder for 2 days now. Am I correct in understanding that with the uibuilder, I would have to rebuild my entire dashboard in a template (HTML, CSS, JavaScript)? The uibuilder seems very powerful, but I have to admit that my HTML and CSS skills are quite limited. Or am I misunderstanding the concept of the uibuilder? The disadvantage of not using the uibuilder and running multiple instances of Node-RED in parallel would, of course, be that my server would eventually become overloaded. I have been wondering how to calculate how many instances can be run simultaneously with the above-mentioned server. Thank you again for your contribution.
Yes, unfortunately, that is correct. However, from your description, it didn't sound as though the Dashboard was that complex. Of course, I may have misunderstood. In addition, if there are parts of the dashboard that are common to everyone, you could have a single NR instance with the single Dashboard but incorporate a user/client specific uibuilder page (or, more likely a single common page that is updated with user-differentiated data) - or multiple pages for that matter. So making the best use of both.
Indeed. And I don't have a good answer for you I'm afraid. This is a potential disadvantage of Node-RED in that it can be hard to judge the resources needed since it depends on a lot of factors. As mentioned, I think you could probably run a couple as long as the server is well tuned and your flows are not too excessive but only testing will tell you.
You do also have the overheads of keeping multiple instances in sync of course which you should also bear in mind. It isn't that hard but it is certainly work to be undertaken when making changes and more work when updating Node-RED and/or dependent nodes.
Potentially but some work is needed to assure that everything is in step and correctly configured. Wouldn't be much for a few instances with relatively few changes. But could easily get out of hand as things scaled up. Automation would fix the issue of course but that also needs creating, maintaining and monitoring.
Obviously, I'm having to think fairly wide here since I don't know much about the environment or number of likely customers. But these things have a nasty habit of starting with 2 people and escalating to 20 or 200 or even 2000+. So generally worth thinking about things up-front so that you at least understand the overheads of a venture which I assume is designed to make at least a small profit.
I get your thoughts. Thats why i think abou it. I try to make the best choice and the to keep the cost-benefit factor. How much costumer will be and want to use it, i cant tell either. Right now i try to make it for a few as a service (and i like doing it). But like u said, i cant forecast hoe many at the end will be contribute. I will try to make a small program, where i can see how the different stepa fit into each other
use NodeRED in a Docker container per customer and parametrize customer specifics using ENV variables
I recommend to use Traefik as reverse proxy: Easy to deploy using "labels" in docker-compose.yml. Does https with Let's encrypt very well and has a dashboard for the services.
You can put everything in one docker-compose.yml or use one docker-compose.yml for each customer.
Sorry but i will step in here and not trying to be rude - (and as you have not stated what the pumps are and what they are conttrolling) - with the types of questions you have been asking it would appear you are not an IT professional - i would highly recommend against exposing your system in any way to the Internet - you need to get an architect and IT security person involved to craft a solution that will be secure and can not cause a catastrophic issue if it falls into the wrong peoples hands.
I would never directly expose NR to the Internet (reverse proxy or not) as it has not been architected from the ground up for security and who knows what other modules you have installed from 3rd parties ? and any issues they may have
If the first line there is entirely within a local network then there are no particular security concerns in that. The security concerns arrive when you (or customers) access the dashboard across the internet. Then you have to think about preventing bad actors from getting in and hacking the system or stealing data. Also there is the privacy of each customer's data to consider.
The arguments aren't really against Node-RED itself but about the risks involved with connecting anything to the Internet. Those risks can be magnified when real-world devices are being controlled.
Anything connected to the Internet needs to be properly secured, there are lots of posts and a major FAQ entry right here on the forum. Including posts from people who were hacked because of failing to secure Node-RED properly.
Compromised servers affect everyone not just yourself since they are often used in attacks against other people. Obviously, if you have paying customers, it can also have a major impact on your business.
So again, isn't FlowForge supposed to "take care" of such things related to security aspects? You will still use Node-RED but under control beneficial to you and all customers
FlowForge is a commercial product and the OP might not be in a position to use it.
Also, you can still mess up the security on FlowForge, I would imagine, by careless configuration and through poor choice of flows/nodes.
The choice of a product does not take away the need to be aware of the risks and to mitigate them even though FlowForge almost certainly would make some aspects a lot easier to deal with (e.g. taking care of logins and TLS certificates).
