Support ${msg.foobar} for dynamic input in node editor

Hey Guys! o)

It seems we can use env vars to set node-properties, like described here:
Nice, but ENV vars only? Wot? o)
Aren't global/flow context vars and message objects the first class citizens in node-red?

In my flows I'd like to configure node settings in one place, like email-hostnames, mqtt-prefixes, ip-addresses, filesystem-paths etc. Right now I need to pick dozens of nodes and edit them manually after deploying the flow in another environment, this is error prone and arrg. o). I came across the "contrib-config" node linked below, it manages to get the "central editing" done, but now we still have many nodes which do not support input messages for configuration (some are starting points of sequences, some just don't look at "msg.server" e.g. (like the email-out node).

Wouldn't it possible to support a placeholder syntax for input fields in the node editor to inject context and/or message variables as well (like its possible for ENV vars already)?

  • ${global:foo}
  • ${flow:bar}
  • ${msg.foobar}
  • ..basically any sane syntax will do! o)

For "Server" text input field in the email-out node I'd simply enter ${msg.myhostname}, if I want the email server to be set via incoming message or I use ${} if I want to use some value from my "central point of configuration"-object.


  • dynamic input for nodes which do not accept input message at all (mqtt-in etc.) or for which setting an important property via message is not supported (like msg.server for the email-out node).
  • less clutter in sequences/flows
    (many function/change nodes only setup the upcoming node, no real flow-functionality added)
  • avoid node forks
    (I had to fork the "watch" node to allow dynamic folder input e.g., I really don't wanna do that for the email-, mqtt-, http-nodes etc. again, since nobody will ever update them.)

ENV var disadvantages:

  • they cannot be edited/maintained in the node-red editor easily
  • they do not export with the flows
  • they do not handle flow restarts/resets well
  • creating/changing them dynamically within a flow is questionable and creates extra clutter
    (if all you want is to use them with the placeholder syntax)

Below is the link to the node-red-contrib-config node I mentioned above. Setting up and resetting global/flow objects and variables right before a flow starts is easily done with that, so half the solution is already there.

Thank you for your attention! o)

How would that work?

msg input is dynamic whereas environment variables are effectively static (only change on startup).

What you suggest has merit of course, but it may require just about every node to be revisited and to support it even if they could.

For example, in uibuilder, if you made the URL setting dynamic like that, a flow could dynamically change the name of the URL in-flight. It is very unlikely that any code changes would be able to handle that. It would certainly make for a very bad user experience and would likely cause odd failures as things moved about (which takes time).

Some things wouldn't be so bad - the topic for example - but many settings wouldn't be feasible.

You will need to set the port, whether or not you use ssl, the username and the password.
How many email configs do you use; 1, 2?

Mqtt, set the topic to # and filter as you go, but I'm sure everyone welcomes a fork for dynamic topics that can be merged into NR.

less clutter in sequences/flows

In return for added complexity.

Instead of using "dozens" of nodes, why not just use 1 and use link nodes to get your msg to the node.