Node-RED to GitOps — When to Graduate from Flows to Functions

Start with Node-RED — Seriously

If you're exploring whether a Unified Namespace makes sense for your factory, start with Node-RED. We mean it.

Node-RED is the fastest way to wire MQTT topics together and see results. You can go from "I have a PLC publishing data" to "I have a dashboard showing machine status" in an afternoon. No code, no containers, no deployment pipeline — just drag, drop, and connect.

What Node-RED Does Brilliantly

• ✓ Instant feedback — wire an MQTT-in node to a debug node and you're watching live data in seconds
• ✓ Visual data flow — you can literally see how data moves from source to destination
• ✓ Low barrier to entry — manufacturing engineers and automation specialists can build flows without being software developers
• ✓ Rich ecosystem — thousands of community nodes for OPC UA, Modbus, S7, databases, dashboards
• ✓ Rapid prototyping — test an idea in minutes, not days
• ✓ Built-in dashboard — Node-RED Dashboard gives you gauges, charts, and buttons with zero frontend code

A Typical Node-RED UNS Experiment

Here's what a first UNS experiment looks like in Node-RED — and it's genuinely effective:

# A simple Node-RED flow for UNS experimentation

[MQTT In] → v1.0/enterprise/site1/area1/cnc-01/status
    ↓
[Function] → Parse JSON, extract state field
    ↓
[Switch] → Route by state: ACTIVE / IDLE / ALARM / SETUP
    ↓
[Dashboard] → Gauge showing current state
    ↓
[PostgreSQL] → INSERT INTO machine_log (topic, state, timestamp)

# Total setup time: ~30 minutes
# Nodes used: 6
# Lines of code: 0 (just node configuration)

This is a perfectly valid way to prove the concept. You've demonstrated that machine data flows through MQTT, gets processed, gets stored, and gets visualised. The business case is proven.

The question is: what happens next?

Same Logic, Different Delivery

The core logic of a UNS pipeline is the same regardless of whether you implement it in Node-RED or fn-uns. The difference is how that logic is packaged, deployed, and maintained.

Example: Detecting a Machine State Change

Example: Logging Data to a Database

Example: Computing a KPI

The logic is identical. The delivery mechanism is fundamentally different — and that difference matters enormously as you scale.

When Flows Stop Scaling

Node-RED flows work beautifully at small scale. The problems emerge gradually — and by the time you notice them, you're deeply invested.

The Progression

The Seven Problems

Why GitOps Wins for Production

GitOps means git is the single source of truth for your system. Every function, every configuration, every deployment is a git commit. This isn't a philosophical preference — it's a practical requirement for production manufacturing systems.

Head-to-Head Comparison

The Deployment Workflow

# The fn-uns deployment workflow

# 1. Make a change
vim uns-state/function.go

# 2. Test locally
cd uns-state && docker compose up -d
curl http://localhost:8080/uns-state | jq

# 3. Commit with context
git add .
git commit -m "add MTBF calculation to state tracker

Reads ACTIVE→ALARM transitions from uns_state table
and computes mean time between failures per machine.
Requested by maintenance team for predictive scheduling."

# 4. Push to deploy
git push deploy main

# 5. If something goes wrong
git revert HEAD
git push deploy main
# → Previous version is running again in seconds

The Migration Path

You don't throw away your Node-RED work. The logic you prototyped in Node-RED becomes the specification for your production functions. Every flow maps to a function.

From Flow to Function

The Mapping

Every Node-RED concept has a direct equivalent in fn-uns:

fn-uns Equivalents

Here's how fn-uns handles every common Node-RED UNS pattern — and what you gain by making the switch.

MQTT Subscribe & Cache

State Change Detection

Stoppage Classification

KPI Computation

Dashboards

The Scaling Story

The real difference between flow-based and function-based approaches becomes clear when you scale. Here's what happens at each stage:

1 Machine → 10 Machines

10 Machines → 100 Machines

1 Site → 5 Sites

Which Approach Should You Use?

This isn't a binary choice. The right tool depends on where you are in your UNS journey.

Use Node-RED When:

• ✓ You're exploring whether a UNS makes sense for your operation
• ✓ You need to prove the concept to stakeholders quickly
• ✓ You're working with a few machines at a single site
• ✓ The team is automation-focused rather than software-focused
• ✓ You need rapid iteration — trying different approaches daily
• ✓ It's a personal project or a small-team experiment

Use fn-uns + GitOps When:

• ✓ The UNS is becoming production infrastructure that the business depends on
• ✓ You need version control, code review, and audit trails
• ✓ Multiple people need to work on the system simultaneously
• ✓ You're deploying across multiple sites and need consistency
• ✓ Failure isolation matters — one bug shouldn't take down the whole pipeline
• ✓ You need safe rollbacks — the ability to undo a change instantly
• ✓ Your IT team requires change management processes
• ✓ You want to scale without scaling complexity

The Recommended Path

The Bottom Line

Node-RED is an excellent experimentation tool. Use it to prove your UNS concept, validate the data flow, and demonstrate business value. It's the fastest path from "idea" to "working demo."

But when your UNS becomes production infrastructure — when the business depends on it, when multiple people maintain it, when it needs to run reliably across multiple sites — you need the things that flow-based programming can't give you: version control, code review, failure isolation, automated testing, and safe rollbacks.

That's what fn-uns and GitOps provide. Not a different way to do the same thing — a better foundation for the same logic you already proved works.