# Safely accessing Node-RED over the Internet

**URL:** <https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024>\
**Category:** FAQs\
**Tags:** security\
**Created:** [1 May 2021 16:43 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024 "2021-05-01T16:43:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [1 May 2021 16:43 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/1 "2021-05-01T16:43:46Z")

</div>

_Update 2025-02-19_

The best advice for most people doing home automation is still:

**Don't expose Node-RED to the outside world!**

Where you really have to have some outside access, keep it as _hands-off_ and restricted as possible. For example, using a Telegram bot.

Also keep it as _minimal_ as possible, e.g. Don't expose the Editor - EVER!

If you want to provide remote control of your heating or the precious plants in your greenhouse, provide _explicit_ controls with strong limits. Don't expose everything. Assume that, at some point, your security could fail and plan accordingly.

Always assume that some bad person or system WILL mash random or vindictive entries into whatever you expose.

* * *

NOTES:

- This is a large and complex subject. So this FAQ is likely to be a work-in-progress for some time.
- This FAQ **MUST NOT** be taken as gospel or as professional advice. The information is shared in good faith but with no guarantees. Get the input of professionals and get your system regularly security tested, at least penetration tested.

_Please feel free to add suggestions for content and links to existing resources._

## Overview of options

There are two main options for making Node-RED endpoints available over the Internet.

1. A Virtual Private Network (VPN)

2. TCP/IP direct access

I will break down the three broad approaches in separate posts to this thread. Please do chip in with other comments though.

### Reference Material

- [Node.js Security Best Practice](https://nodejs.org/en/guides/security/)
- [Node.js net class, blocklist](https://nodejs.org/docs/latest-v14.x/api/net.html#net_class_net_blocklist)
- [How to ‘whitelist’ IP address’s that can access Node RED](https://discourse.nodered.org/t/how-to-whitelist-ip-addresss-that-can-access-node-red/83990)

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [30 July 2021 07:00 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/3 "2021-07-30T07:00:43Z")

</div>

This topic was automatically opened after 13 hours.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [23 December 2021 11:37 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/4 "2021-12-23T11:37:55Z")

</div>

So, been a very hectic year for me so not really had a chance to come back to this subject. But after a fruitful conversation with Bart, I wanted to at least jot down some notes about securing Node-RED.

* * *

To make Node-RED endpoints available over the Internet, there are 3 components we need to think about.

1. The Node-RED nodes/flows that define web endpoints themselves (in other words, the Node-RED service).
2. The web server that makes these endpoints available to users.
3. The certificates and keys that enable the TLS encryption of traffic.

Each of these components need their own security. And each of these components are better treated somewhat independently from a security perspective since that gives us better security in depth.

## 1) The Node-RED Service

The default installation for Node-RED is not very secure. It is installed in the global `root` or super-admin context. This gives anyone with access to flows the potential ability to do _anything_ to the device it is running on.

Instead, you should create a new user id specifically for Node-RED. Then install Node-RED in a way that only gives access to that user. This is the same way that other services work. Check out an installation for a web or database server as an example.

Once installed, only give that user access to the services and devices it really needs. You can use the standard OS features to do this.

## 2) The Web Server

Node-RED has its own, built-in web server (actually it has two). This is provided with the help of ExpressJS.

While you can certainly configure this to be reasonably secure, Node-RED focuses (rightly) on nodes and flows, not security. It is much better to use a separate web server and use that to handle security. This also gives you more security depth because the web server can (and will) now run under a different user id - your Node-RED flows will not be able to make changes to it.

Thankfully, this is pretty easy to set up and there are many tutorials. Choose your favourite web server (my preference is generally NGINX) and configure it as a "reverse proxy". As such, it sits between users and the Node-RED service and acts as an intermediary for all web (and websocket) traffic.

You can use the capabilities of the web server to handle the TLS network encyrption. This provides some security depth and removes some overheads and configuration complexity from Node-RED.

You also need to block access to Node-RED's TCP/IP port (typically 1880) from anywhere except `localhost`. Then all traffic to/from Node-RED _has_ to come through the proxy. It is possible to configure Node-RED to only listen to localhost requests. Do both if you are of the "belt and braces" mindset. 🙂

## 3) Certificate & Key management

Sometimes you will see this referred to as "Public Key Infrastructure" (PKI). The key thing to remember about certificate/key management is that:

- The **certificate** is **PUBLIC**
- The **key** is **PRIVATE**

You must never let the key be obtained by anyone else otherwise it is worthless. One of the reasons that Let's Encrypt keeps the validity of their certificates and keys so short is that it limits the damage should your key file be compromised. Many browsers are also starting to reject certificates with long lifespans.

Because the key is so critical, I personally prefer to manage the certificates and keys as a separate process though the Caddy web server has key management built in if you really want to go that way. The other reason for managing them separately is that it gives you much more freedom and flexibility for using things like multi-domain and wildcard certificates should you wish to. Again, though, the main reason is security depth and separation of concerns.

Let's Encrypt have the `acme.sh` scripts which are easily configured and create CRON scheduled jobs to automatically update your certificates and keys. Again, create a separate user id to run these. Then you can choose where the resulting files are copied to and what security to apply.

* * *

By keeping these 3 components separated, you are greatly increasing your security since compromise of 1 service doesn't necessarily mean compromise of the others. Generally, the nature of Node-RED as a code authoring service means that it is likely to have the weakest security - that isn't a failure of Node-RED, simply recognising how it is used. Having the web service and the certificate/key management as separate processes with their own security will give you the best chance at keeping your service safe and secure.

Of course, this is not the only way and there are many other things you can and should do to secure Node-RED over the Internet but these are the basics and for the majority of uses, this should be sufficient.

As always, this information is provided as-is with no guarantee that it is correct. **Always get your services checked by a security professional**.

* * *

One final point to make in these notes. About the use of Docker.

Using Docker to deliver the services above (all or some) is perfectly fine - if you know how to use and manage Docker. Docker containers will generally help with separation of security but that isn't a foregone conclusion. The principles I've outlined should be applied to Docker containers as well with each service separated and seprarately secured.

Certainly, though, the use of containers will generally help keep things separate and compromise in one container will be harder to spread to another.

If you don't know Docker though, you may find that it adds more overheads on both resources and management, than you really want. It certainly adds quite a lot of additional complexity.

* * *

While what I've outlined may seem complex, the complexity is in the initial setup. You only have to do that once. Then the maintenance should actually be easier.

Your web server should have been installed using your OS's package manager and so will update with everything else (including databases and node.js) so ensuring that they stay current and secure. `acme.sh` updates itself as it is run. Node-RED updates using `npm` under the user you installed it with.

Configuration, after the initial install, is also simpler since you are unlikely to ever need to change the acme.sh script and rarely change your web server configuration. Node-RED however, changes pretty rapidly, including the settings.js file. So keeping that as simple as possible makes life a lot easier.

Hope this helps - comments, as always, welcome.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [18 October 2022 13:17 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/5 "2022-10-18T13:17:02Z")

</div>

Following [another set of compromised Node-RED servers that were open to the Internet](https://discourse.nodered.org/t/dashboard-suddenly-asks-for-password-hacked-node-red-servers/69083), I realised that there might be some useful advice missing from the above.

There is an additonal level of security that you can apply and indeed, really should, if you need to expose a Node-RED service endpoint (e.g. a web page or API) to the Internet.

That is that you should consider having a separate instance of Node-RED on a non-standard IP port, preferably on a separate server (a Raspberry Pi might be sufficient).

A separate instance would be configured to do as little as possible itself other than handle incoming data from an instance (or MQTT or other disaggregating service) that is not exposed to the Internet and present the required endpoint(s). You could also allow data to cross over to the more secure instance - BUT, make sure that BOTH instances validate any input since ALL input across the Internet (and indeed any user input anyway) MUST be carefully validated before use.

For any static configuration on the Internet-facing instance, ideally you should periodically check against a known good config (you must run the check from something that isn't accessible from the Internet of course).

Using a separate service for this is ideal because it allows you to create physical separation not possible when running on a single server. It also allows you to minimise the attack surface by removing all unnecessary services and locking the device down carefully. Data should never be mastered on the Internet-facing server and configurations should be pushed from a non-Internet facing source so that even if the internet-facing server is compromised, it can fairly safely be reset.

This is an example of a "DMZ" approach (De-Militarised Zone) that is required in all enterprise, commercial and regulated deployments. In the case of a full DMZ, the externally-facing server(s) would have a separate LAN and router/firewall between them and the more secure internal networks. This can be simulated in a low-cost setup by using a VLAN (if your router/switch supports it) or at least using a local server firewall (e.g. IPTABLES, UFW, etc) on the internal server.

---

<div class="post-metadata">

**Author:** ![sdrshnptl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/sdrshnptl/32/40446_2.png) [@sdrshnptl](https://discourse.nodered.org/u/sdrshnptl)\
**Post date:** [18 November 2022 07:56 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/6 "2022-11-18T07:56:06Z")

</div>

Install node red on any platform as usual, then install [remoteit](https://www.remote.it/) client and add TCP service to client.  
Connect node red via remoteit dashboard.

---

<div class="post-metadata">

**Author:** ![bakman2](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bakman2/32/6207_2.png) [@bakman2](https://discourse.nodered.org/u/bakman2)\
**Post date:** [6 March 2023 06:04 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/7 "2023-03-06T06:04:34Z")

</div>

Recently I came across another solution, which is free, secure and solid: Cloudflare zero trust tunnels (you do need a creditcard to register and a domain name). The end result is that you can keep all ports closed on your router and run a cloudflare daemon (or docker container - how it runs here) that establishes a tunnel.

Whatever you present over the tunnel is upgraded to https/tls traffic with valid certs for each endpoint.  
You can ssh/smb/etc over the tunnel and cloudflare can even provide a webbased terminal (did not test this yet).

Security can be setup with passwordless auth (ie: via email) or oauth2 (many providers are integrated), yubi key etc. and you can configure that you require multiple (at least one). The setup is quite sophisticated.

I followed this [tutorial](https://www.youtube.com/watch?v=ZvIdFs3M5ic) (youtube).

Works fantastic.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [6 March 2023 10:39 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/8 "2023-03-06T10:39:23Z")

</div>

Yes, been using that for a while now. It is more complex to set up than some of the other tools but it is flexible and secure. And you get 50 user accounts even on the free tier which is amazing.

Interestingly, Microsoft have also done a deal with Cloudflare to build a "VPN Lite" feature into Microsoft Edge browser. I also use Cloudflare free tiers for handling all my DNS and as a proxy to any web services since that provides additional protection and monitoring.

---

<div class="post-metadata">

**Author:** ![PizzaProgram](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/pizzaprogram/32/19431_2.png) [@PizzaProgram](https://discourse.nodered.org/u/PizzaProgram)\
**Post date:** [12 March 2023 14:13 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/9 "2023-03-12T14:13:29Z")

</div>

> [@sdrshnptl](#):
>
> Install node red on any platform as usual, then install [remoteit](https://www.remote.it/) client and add TCP service to client.  
> Connect node red via remoteit dashboard.

Please edit your answer and add this sentence:  
**- only Free when: max 1 user & Personal usage !**

Took me +5 minutes unnecessarily to realise: min 10$/month/user

---

<div class="post-metadata">

**Author:** ![PizzaProgram](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/pizzaprogram/32/19431_2.png) [@PizzaProgram](https://discourse.nodered.org/u/PizzaProgram)\
**Post date:** [12 March 2023 14:21 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/10 "2023-03-12T14:21:13Z")

</div>

You may add enhancement to the list:

> **[Getting Started - Caddy Documentation](https://caddyserver.com/docs/getting-started)**
>
> Caddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go

A strong Proxy, which

- can handle certificate renewal by itself
- protects the whole PC, allowing ONLY the necessary ports
- forwards ports (hiding the real service)
- very easy to install and configure (2 lines in a JSON)
- completely free and OpenSource
- very stable & Fast!
- runs on ALL platforms.

Maybe a BasicAuth over https can be enabled too... ?

---

<div class="post-metadata">

**Author:** ![PizzaProgram](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/pizzaprogram/32/19431_2.png) [@PizzaProgram](https://discourse.nodered.org/u/PizzaProgram)\
**Post date:** [12 March 2023 14:25 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/11 "2023-03-12T14:25:10Z")

</div>

As for self-managed VPN, I've found this:  
[https://www.softether.org/](https://www.softether.org/)

- Free, FOSS
- on all platforms can be installed and everything can connect  
etc.

What I like is the very easy GUI management of it and the huge, easy to understand networking manual to it.

---

<div class="post-metadata">

**Author:** ![issambfs1](https://avatars.discourse-cdn.com/v4/letter/i/ea666f/32.png) [@issambfs1](https://discourse.nodered.org/u/issambfs1)\
**Post date:** [14 March 2023 15:28 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/12 "2023-03-14T15:28:54Z")

</div>

The problem of vpn is you need i fix ip address that mean you need to pay for the fix ip !

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [14 March 2023 15:48 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/13 "2023-03-14T15:48:19Z")

</div>

> [@issambfs1](#):
>
> you need to pay for the fix ip

Can you not use a free domain name provider such as duckdns?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [14 March 2023 16:10 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/14 "2023-03-14T16:10:51Z")

</div>

> [@issambfs1](#):
>
> The problem of vpn is you need i fix ip address that mean you need to pay for the fix ip

Not so. Some types of VPN need a fixed public IP but certainly not all. But in any case, it is generally best to avoid a VPN unless you really know what you are doing. Much better to use a service such as CloudFlare Zero Trust.

---

<div class="post-metadata">

**Author:** ![PizzaProgram](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/pizzaprogram/32/19431_2.png) [@PizzaProgram](https://discourse.nodered.org/u/PizzaProgram)\
**Post date:** [14 March 2023 17:19 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/15 "2023-03-14T17:19:50Z")

</div>

> [@issambfs1](#):
>
> The problem of VPN is, you need a fix IP address. That means, you need to pay for the fix IP !

SoftEther is different.

- it can penetrate through all kinds of NAT / Firewall, etc.
- it has a free "IP forwarder network", if you do not have a public IP, not even a dynamic one.
- it has a very easy graphical interface where you can active a complete lists of _graphically well explained_ features with just 1 Checkbox click.

If you have a public IP (even a daily or hourly changing one) than no FIX IP is needed.

> [@Colin](#):
>
> domain name provider such as duckdns?

Thanks for the tip ! Since I'm paying ca. 100EUR/y for my DynDns account, I was always asking myself:

- Is there no free, stable alternative for that?

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [14 March 2023 17:44 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/16 "2023-03-14T17:44:57Z")

</div>

I used to use duckdns and pivpn but that doesn't work since I switched to mobile broadband.

Now I use Zerotier which is much easier to setup and needs no maintenance when my IP changes.  
All connections are outgoing so there are no open ports.

---

<div class="post-metadata">

**Author:** ![bakman2](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bakman2/32/6207_2.png) [@bakman2](https://discourse.nodered.org/u/bakman2)\
**Post date:** [14 March 2023 19:28 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/17 "2023-03-14T19:28:50Z")

</div>

Can you actually change the dns resolver on dyn/duckdns (i mean, the purpose _is_ the dns).

I have tried zerotier/vpn's etc. Problem with all of those is that you cannot access your devices from/via other sources, only the ones you have setup. npm proxy manager with authelia work(ed) nicely, but cloudflare zero trust, is more convenient and easier to setup. One caveat is that cloudflare could theoretically sniff your traffic, but hides your public ip, zerotier is e2e encrypted but does not hide your public ip.

---

<div class="post-metadata">

**Author:** ![craigcurtin](https://avatars.discourse-cdn.com/v4/letter/c/94ad74/32.png) [@craigcurtin](https://discourse.nodered.org/u/craigcurtin)\
**Post date:** [15 March 2023 00:48 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/18 "2023-03-15T00:48:28Z")

</div>

Hey @bakman2 - not sure exactly what you are asking ?

What do you mean by change the DNS resolver for DuckDNS ?

When you say you can not access your devices do you mean you must have the client etc installed to access the VPN ?

Craig

---

<div class="post-metadata">

**Author:** ![sdrshnptl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/sdrshnptl/32/40446_2.png) [@sdrshnptl](https://discourse.nodered.org/u/sdrshnptl)\
**Post date:** [3 April 2023 08:38 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/19 "2023-04-03T08:38:50Z")

</div>

Hi @PizzaProgram  
Thanks for your remark.  
indeed it's paid app with few good feature.  
Like easy install, launch and remotly configure services with app.  
Cloudflare is totaly web based with manual process.  
Unlike cloudflare zero trust tunnels; we need to follow few extra scripts. (Cloudflare is wayyy cheaper than remoteit - i agree)  
Both are excellent application, user may find what is best for him.  
Regards,  
Sudarshan

---

<div class="post-metadata">

**Author:** ![maxweissboeck](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/maxweissboeck/32/59803_2.png) [@maxweissboeck](https://discourse.nodered.org/u/maxweissboeck)\
**Post date:** [18 May 2023 09:34 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/20 "2023-05-18T09:34:37Z")

</div>

I think I should jump in on this. In the EU the FritzBox internet Modems are very popular and it is very easy to set up VPN on FritzBox. It is very secure and a good solution if you want to give private access to your network from outside. Benefit and drawback, everyone with the VPN network keys installed on his/here device has access to your whole network, if you do not implement extra security in your network.

For me that is fine, me, my wife and my daughter have a very secure access to our home from everywhere in the world, we can control our smart home system (Loxone), start video recording and access everything else. For me the most secure and most painless solution - if you know what you do, as always 😀

And on iOS it is simple to install VPN on demand, so whenever I access my home network, VPN is startet automatically within seconds.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [18 May 2023 10:54 UTC](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024/21 "2023-05-18T10:54:07Z")

</div>

Thanks for the input Max. VPN's are a solution that people often reach for and they certainly work though they can be hard to set up on some hardware.

The major disadvantage of a VPN is, as you mention, the fact that each remote device has access to your home network. That means that the network becomes only as secure as the weakest device security. This is especially problematic in certain countries where abuse of networks and even of devices (e.g. left in hotel rooms or passing through borders) is endemic. This is not a theoretical risk, I've seen examples in the real-world (hint: even before the war with Ukraine, I would never have left any device unattended in a Moscow hotel room. Certainly never leave devices on standby in hotel rooms, always turn them off completely).

Anyway, yes, VPN's can be a good choice if your router is easy to set up. But just be aware of the security risks.

I still like the idea of having a not always on solution that I can turn on remotely via a different channel such as Telegram and then turn off again when not needed. This can, of course, work with a number of the solutions outlined though it may be somewhat harder to be able to make a dynamic change to a router's VPN service than it would be to stop/start a server service such as Cloudflare Zero Trust, NGROK, etc. Those services can also be restricted to specific servers and so could fairly easily be ring-fenced from the rest of your home network. Whether it is worth the trouble is, of course, only something that each individual can decide.

[Next page](https://discourse.nodered.org/t/safely-accessing-node-red-over-the-internet/45024.md?page=2)