How to Secure Node-RED: A Practical Checklist

To secure Node-RED you need to lock down three things: who can open the editor, how traffic to it is encrypted, and how your flows talk to outside systems such as an MQTT broker. This checklist walks through each setting in settings.js, with commands you can copy, so you end up with an instance that is safe to leave running on a network.

Why Node-RED Needs Hardening

Out of the box, a fresh Node-RED install has no login on the editor and serves plain HTTP on port 1880. That default is convenient on a laptop and dangerous anywhere else. Anyone who can reach the editor can deploy a function node or an exec node, which means they can run arbitrary commands on the host with Node-RED's permissions. Exposed, unauthenticated Node-RED editors are regularly found by internet scanners, so treat the editor as an administrative console, not a web page.

Node-RED also holds secrets: broker passwords, API tokens, database credentials. And because it often bridges operational technology and IT networks, a compromised instance can be a stepping stone into places attackers should never reach.

Here is the full checklist; the sections below explain each item.

1. Require a Login for the Editor

Generate a bcrypt hash of a strong password with the Node-RED admin tool:

npx node-red admin hash-pw
# Password: ********
# $2b$08$wuAqPiKJlVN27eF5qJp.RuQYuy6ZYONW7a/UWYxDTtwKFCdB8F19y

Then add adminAuth to settings.js (~/.node-red/settings.js, or /data/settings.js in Docker):

adminAuth: {
    type: "credentials",
    users: [
        {
            username: "admin",
            password: "$2b$08$REPLACE_WITH_YOUR_HASH",
            permissions: "*"
        },
        {
            username: "viewer",
            password: "$2b$08$REPLACE_WITH_ANOTHER_HASH",
            permissions: "read"
        }
    ]
},

Restart Node-RED and the editor shows a login screen. The read permission lets someone view flows without deploying, which suits operators and auditors. Give each person their own account instead of sharing one admin password, so you can remove access when someone leaves. For larger teams, adminAuth also supports OAuth and OpenID Connect strategies through Passport, so you can use your existing identity provider.

2. Serve the Editor over HTTPS

A login over plain HTTP sends the session token across the network in clear text. Either enable HTTPS directly in Node-RED or terminate TLS at a reverse proxy.

Directly in settings.js:

// near the top of settings.js
const fs = require("fs");

module.exports = {
    https: {
        key: fs.readFileSync("/home/nodered/certs/privkey.pem"),
        cert: fs.readFileSync("/home/nodered/certs/fullchain.pem")
    },
    requireHttps: true,
    // ...
};

Behind a reverse proxy such as Nginx, Caddy or Traefik, keep Node-RED on HTTP bound to localhost and let the proxy handle certificates and renewal. Make sure the proxy forwards WebSocket upgrades, because the editor uses a WebSocket on /comms for live status and debug messages.

3. Set an Explicit Credential Secret

Node-RED encrypts node credentials, such as your MQTT broker password, in flows_cred.json. If you do not set a key, it generates one and saves it in a runtime file in the user directory. Set your own, ideally from an environment variable:

credentialSecret: process.env.NODE_RED_CREDENTIAL_SECRET,

Store that secret in your password manager or secrets store. Without it, an encrypted credentials file is useless, which is the point: someone who copies your flow files cannot read the broker password. If you change the secret later, Node-RED re-encrypts the credentials on the next deploy.

4. Protect HTTP Endpoints and Dashboards

adminAuth protects only the editor and admin API. Flows built with http in nodes, and static files, are a separate surface. Add basic authentication for them:

httpNodeAuth: { user: "api", pass: "$2b$08$REPLACE_WITH_HASH" },
httpStaticAuth: { user: "static", pass: "$2b$08$REPLACE_WITH_HASH" },

For anything more involved than a shared password, put a proxy with proper authentication in front, or check a token inside the flow itself. If you use Dashboard 2.0, review its own access options and consider serving it through the same authenticated proxy. A read-only dashboard can still reveal plant data you would rather keep private.

5. Limit Network Exposure

The best attack surface is none. Bind Node-RED to localhost and reach it through a VPN, an SSH tunnel or an authenticated proxy:

uiHost: "127.0.0.1",
uiPort: process.env.PORT || 1880,

In Docker, publish the port on the loopback address only, for example 127.0.0.1:1880:1880, as shown in our Node-RED Docker guide. Never forward port 1880 on a router to the internet. If an instance runs on an edge gateway, firewall it so only the management network can reach the editor.

For production systems that should never change at runtime, you can go further and set disableEditor: true. Flows keep running but the editor and admin API are gone; deploy changes by updating files and restarting.

6. Run with Least Privilege

Do not run Node-RED as root. Use a dedicated system user that owns only the Node-RED directory. The official Docker image already runs as a non-root user. Remove or restrict nodes that execute system commands, such as exec, if your flows do not need them, using the nodesExcludes setting.

7. Control Installed Nodes and Modules

Every contributed node is code running with Node-RED's permissions. Install only maintained nodes you actually need, and review them before adding them to production. You can restrict what can be installed from the palette:

externalModules: {
    palette: {
        allowInstall: true,
        allowList: ["@flowfuse/node-red-dashboard", "node-red-contrib-modbus"]
    },
    modules: {
        allowInstall: false
    }
},

Setting modules.allowInstall to false stops function nodes from pulling in arbitrary npm packages at runtime.

8. Use TLS and Unique Credentials for MQTT

A secure Node-RED instance should not then talk to its broker in clear text. In the MQTT broker configuration node:

1. Use port 8883 and tick Use TLS, with certificate verification left enabled.
2. Use a dedicated username, password and client ID for Node-RED, separate from devices. On ConnectMQ, client IDs are bound to the credentials they were issued with, so a leaked device credential cannot impersonate your Node-RED instance.
3. Never publish real data on a public test broker. The public MQTT test broker is ideal for learning, but every topic in its public area is readable by anyone.

The full setup, including custom CA files, is in our Node-RED MQTT TLS guide, and our MQTT security best practices cover the broker side.

9. Keep Node-RED and Nodes Updated

Security fixes arrive in Node-RED releases, Node.js releases and contributed node updates. Check Manage palette for node updates, follow the Node-RED release notes, and upgrade Node.js to a supported LTS line. Back up your user directory first, and test upgrades on a copy before production.

10. Keep Secrets out of Flows and Git

Credentials belong in configuration node credential fields, which are encrypted, not in function code or inject nodes. Read API keys in function nodes with env.get() from environment variables. If you version flows with git, the Node-RED projects feature encrypts the credentials file with a project key that never enters the repository.

The official Node-RED security documentation lists every option referenced here. For a broader introduction to building flows, see the Node-RED MQTT tutorial.

Connect Secured Node-RED to ConnectMQ

A hardened Node-RED deserves a broker with the same standards. ConnectMQ is a fully managed MQTT service with TLS on 8883 using a Let's Encrypt certificate, client IDs bound to issued credentials, multi-tenant isolation, flood protection and automatic IP blocking after repeated failed logins. Create a broker on the free Serverless plan at app.connectmq.com, no credit card required, and give Node-RED its own generated credentials. If you are comparing hosting models, read our guide to the cloud MQTT broker.

Frequently Asked Questions

Is Node-RED secure by default?

No. A default install has no editor login and serves plain HTTP. You must enable adminAuth, add HTTPS and restrict network access before exposing it beyond your own machine.

How do I set a password for the Node-RED editor?

Generate a bcrypt hash with node-red admin hash-pw, add it to the adminAuth section of settings.js and restart Node-RED.

Does adminAuth protect my dashboards and HTTP endpoints?

No. It covers the editor and admin API. Use httpNodeAuth, httpStaticAuth, the dashboard's own options or an authenticating reverse proxy for flow endpoints.

What happens if I lose the credential secret?

Node-RED cannot decrypt flows_cred.json, so stored credentials are lost. Your flows still load, but you must re-enter passwords such as your MQTT broker credentials.