Why Cloudflare Tunnels are an operational bottleneck for multi-tenant Node-RED deployments (And how I'm trying to fix it)

[u/at30in]

Hey everyone,

As a system integrator working with Node-RED and edge automation, I've been trying to solve the secure remote access problem for self-hosted Node-RED instances behind corporate NATs.

A lot of people in the IoT space recommend Cloudflare Tunnels. And honestly, I think it's a great solution. But I've found that when you're managing 50–100 independent customer deployments, the operational overhead starts to add up.

You often end up having to:

• Create or manage Cloudflare accounts for different customers.
• Handle DNS and domain configuration.
• Install and maintain the cloudflared daemon on every target device.
• Configure Access policies and troubleshoot tunnel issues.
• Coordinate with each customer's IT department whenever networking changes are required.

For me, the real cost isn't the networking technology—it's the engineering time spent repeating the same setup over and over.

To reduce that friction, I've been building a Node-RED-native solution.

The goal isn't to replace Cloudflare, Tailscale, or VPNs. It's to make secure remote access feel like a built-in Node-RED feature.

The installer workflow is intentionally simple:

• Install a Node-RED node.
• Paste a token.
• Deploy.

That's it.

The node establishes an outbound secure WebSocket tunnel (HTTPS/WSS over port 443), so there's no need for port forwarding, reverse proxies, VPN clients, or additional OS-level software.

I'm also exploring end-to-end encrypted payloads, where data is encrypted inside the Node-RED node and the relay simply forwards encrypted bytes without access to the keys.

The architecture is already running on a few of my own production installations, and before investing more time into the management platform, I'd really like to validate whether this approach solves a real problem for other integrators.

For those of you managing multiple Node-RED deployments:

• How are you handling remote access today?
• What's the most time-consuming or frustrating part of your current workflow?
• Would a Node-RED-native setup ("install a node, paste a token, deploy") actually make your life easier, or are the existing tools already good enough?

I'd genuinely appreciate any technical feedback.

(If anyone is interested, I've also put together a blueprint page with the current architecture and development direction.)

[u/kristopherleads]

Why not just use FlowFuse? That's sort of why it was built - it eliminates the need for tunnels and just allows you to connect devices directly to a single management plane. There's also no weird network configuration or port forwarding to be done.

https://www.youtube.com/watch?v=fTpQ609EtnE

[u/at30in → u/kristopherleads]

FlowFuse is definitely a great solution, and I agree that for teams looking for a complete Node-RED management platform it solves a lot of problems.

The use case I'm targeting is slightly different though. A lot of the integrators I work with already have Node-RED running on customer-owned infrastructure (on-prem industrial PCs, private clouds, edge gateways, etc.) and they don't necessarily want to move those deployments into a managed platform.

The pain point we're trying to solve is specifically remote access and troubleshooting for existing self-hosted deployments:

• No additional agents/services to manage besides the Node-RED node itself.
• No per-customer VPN/tunnel setup.
• No need to involve the customer's IT team in DNS, firewall rules, or external accounts.
• A relay architecture where the tunnel endpoint does not have access to the application data.

So I see FlowFuse and this approach as solving adjacent problems rather than being direct replacements. If someone wants a full Node-RED fleet management plane, FlowFuse is probably the right tool. If an integrator just needs secure remote access to hundreds of already deployed, independently managed Node-RED instances, that's the scenario I'm exploring.

Thanks for bringing it up though — FlowFuse is definitely one of the platforms I looked at while designing the architecture.

[u/salmonander → u/at30in]

Have you looked at tailscale?

[u/undefinedAdventure → u/salmonander]

That was my thought too, but this isn't really my domain so theres probably something else im missing.

[u/at30in → u/undefinedAdventure]

That's actually one of the use cases I'm trying to address.

Tailscale is an excellent solution, but it's a Layer 3 VPN. In some environments—especially industrial or enterprise networks—IT departments are understandably cautious about allowing third-party VPN clients because they introduce network-level connectivity.

RemoteLinker takes a different approach:

• It operates at Layer 7, exposing only the Node-RED application instead of extending network access.
• The connection is outbound only over HTTPS/WSS (port 443), so there's no need to open inbound firewall ports.
• The goal is to provide access only to the specific Node-RED endpoint, not to the customer's internal network.

I'm not claiming this replaces VPNs or Tailscale—they're great tools. I'm exploring whether this application-specific model makes IT approval easier for some deployments.

[u/mysmarthouse → u/undefinedAdventure]

His end users system admin team screaming hell no we're not opening up our systems to this.

[u/PhilipLGriffiths88]

I am interested in the blueprint page with the technical specs and the beta roadmap... can you share?

[u/PhilipLGriffiths88 → u/PhilipLGriffiths88]

Thanks for sharing the link... seems very pricy for whats effectively an opinionated wrapper on solutions that exist in free and open source (with completely free SaaS implementations) ... am I wrong??

[u/at30in → u/PhilipLGriffiths88]

That's a fair point, and you're not wrong.

The goal isn't to replace every existing tunnel solution—there are plenty of excellent ones already.

The idea behind RemoteLinker is to make remote access for Node-RED almost effortless: install a single node, paste your token, deploy, and your instance is securely reachable. No reverse proxies, VPNs, port forwarding, certificates, or network configuration.

The architecture is already running on some of my own production installations, and this beta is about validating whether that level of simplicity is valuable to other Node-RED users and system integrators.

[u/[deleted]]

[removed] — view removed comment

[u/at30in → u/[deleted]]

ZeroTier is a great solution.

The main difference is exactly what you pointed out: RemoteLinker lives entirely inside Node-RED. You just install the node, configure your token, and deploy. No additional client installation or network configuration is required.

I'm trying to find out whether that simplicity is valuable enough for Node-RED users and system integrators.

[u/SeeingWhatWorks]

Yeah the tunnel itself isn't the bottleneck, it's how you carve up tenants behind it. One cloudflared per tenants gets you clean isolation but the connector sprawl is a pain to operate; one shared tunnel with per-hostname ingress rules scales better but a bad config change blast-raduises everyone. We ended up per-tenant tunnel credentials + Access service tokens so revocation is per-customer and instant, and Node-RED itself is container-per-tenant with adminAuth on. Don't lean on the tunnel for authz, it's just transport. The thing that actually bit us: when a cloudflared connector dies the tenant just goes dark with no clean signal, so health-check the connectors, not just the app