# Introducing node-red-cluster - a complete clustering solution for Node-RED (feedback and alternatives welcome)

**URL:** https://discourse.nodered.org/t/introducing-node-red-cluster-a-complete-clustering-solution-for-node-red-feedback-and-alternatives-welcome/99655
**Category:** Share Your Projects
**Tags:** docker
**Created:** [12 November 2025 14:11 UTC](https://discourse.nodered.org/t/introducing-node-red-cluster-a-complete-clustering-solution-for-node-red-feedback-and-alternatives-welcome/99655 "2025-11-12T14:11:38Z")
**Posts on this page:** 1
**Showing post:** 18

<div class="post-metadata">

### Author: ![tahasamy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tahasamy/32/51150_2.png) [@tahasamy](https://discourse.nodered.org/u/tahasamy)
#### Post date: [14 November 2025 12:34 UTC](https://discourse.nodered.org/t/introducing-node-red-cluster-a-complete-clustering-solution-for-node-red-feedback-and-alternatives-welcome/99655/18 "2025-11-14T12:34:52Z")

</div>

Hello, thank you for the feedback. I would like to detail the architectural decisions we made, as they directly address the scaling and security concerns raised.

First, I want to clarify the strategic separation of roles. Developers are responsible for their standard workflow: creating flows, adding devices, and modifying them within their respective Node-RED instances. This core workflow remains unchanged. End Users, however, are the sole focus of our centralized permission system. All their access and modification rights are handled exclusively by the backend, ensuring a clear division between flow development rights and device interaction rights.

To establish secure communication, every Node-RED instance must register with the Django `devices` table. We employ **Asymmetric Cryptography** for robust authentication. The device’s **`public key`** (be it `RSA` or `elliptic curve`) is stored in the Django backend. The corresponding **`private key`** remains secret on the worker node and is used to sign a **`JWT`** (JSON Web Token). This `JWT` payload contains crucial information like the device `ID`, its `expiration time`, and the `creation timestamp`. When the worker node initiates the **`websocket connection`** , it includes this `JWT` in the **`Authorization header`** as `Bearer JWT`. This approach allows the Django backend to instantly verify the token's authenticity using the stored `public key`, ensuring **Non-Repudiation** and secure delegation of responsibility.

Regarding data security, we utilize **`TLS`** over the **`websocket`** connection, leveraging the same widely tested and trusted security mechanisms as `HTTPS`. The selection of `websocket` over `MQTT` was deliberate: 1) `TLS` provides superior security compared to older `SSL` implementations. 2) `Websocket` is **`native`** to the Django ecosystem (via `Django Channels`), which simplifies our infrastructure. 3) Many open-source `MQTT brokers` present significant challenges when trying to achieve a truly **`distributed architecture`** at scale, a complexity we avoid with `websocket` management.

Synchronization across multiple concurrent user sessions (e.g., 10 open tabs) is managed via **`Redis`** acting as a **`real-time pub/sub layer`**. Any signal originating from a Node-RED `element` is instantly broadcasted by `Redis` to all clients with read access, maintaining immediate consistency. When a user sends a command (e.g., toggles a `switch`), the signal enters Node-RED, the `flow logic` executes, and the resulting `output state` is broadcasted through `Redis` to update every user's view. Critical for recovery and initial loading, we allow granular control over **`state caching`** : for every `element` (`sensor`/`actuator`), the system defines how many historical **`states`** (or last messages) should be retained in the `Redis cache`. Upon losing connection or opening a fresh browser session, the user's frontend fetches this defined number of cached states (e.g., 20 points for a chart, 1 state for a switch). This guarantees that every user sees the **exact same dashboard state** , irrespective of their connection history.

Finally, addressing the challenge of **`multi-tenancy`** and `access control` in Node-RED: while simple token-based authentication can secure Node-RED externally (as discussed here: [[How secure node red by tokens - #3 by tahasamy](https://discourse.nodered.org/t/how-secure-node-red-by-tokens/87365/3)]), it does not address granular user permissions. Our solution bypasses the complexity of modifying Node-RED's internal permission system entirely. We deploy **multiple dedicated `Node-RED instances`** and centralize all `access control` in our backend (`Django` or the upcoming `Quack Quack microservice`). This architecture makes the backend the definitive **`gatekeeper`** , enabling us to decide precisely who can access which instance, facilitating clear **`developer isolation`** (assigning separate Node-RED instances to different teams). The immediate focus is evolving the "Quack Quack" module into a **`microservice`** to effectively manage all communication orchestrations (whether through dedicated `Redis`, `Kafka`, or `Websocket management`), which is vital for true distributed scaling.

---

_[View the full topic](https://discourse.nodered.org/t/introducing-node-red-cluster-a-complete-clustering-solution-for-node-red-feedback-and-alternatives-welcome/99655)._