# Is it possible to include credentials (env variables) in a flow json?

**URL:** <https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254>\
**Category:** Developing Nodes\
**Created:** [27 January 2026 10:01 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254 "2026-01-27T10:01:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattjcj](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/mattjcj/32/105562_2.png) [@mattjcj](https://discourse.nodered.org/u/mattjcj)\
**Post date:** [27 January 2026 10:01 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254/1 "2026-01-27T10:01:46Z")

</div>

Hi everybody !

I'm trying to package a subflow as a module. This subflow should transparently subscribe to a MQTT topic and change it's output accordingly.

It will be deployed on a Kubernetes cluster, and the goal is to have the MQTT broker configuration node retrieve it's credentials from environment variables. The MQTT settings of this node are implementation details, and ideally I'd like to hide all of them including the credentials, to avoid users breaking anything.

I searched a bit, and found somewhere ( ~~maybe on this forum, but I can't find the post anymore~~ Found it again: [https://groups.google.com/g/node-red/c/Dfhkiu9X8r0/m/vz2URAdsBgAJ](https://groups.google.com/g/node-red/c/Dfhkiu9X8r0/m/vz2URAdsBgAJ)) that it may be possible to just include them on the node in the `flows.json` file like so:

```js
[
    // previous nodes...
    {
      "id": "338acaed95291164",
      "type": "mqtt-broker",
      "name": "Semi-public broker",
      "broker": "my-mqtt-broker.com",
      "port": "8883",
      "tls": "e422096c3f00881b",
      "clientid": "",
      "autoConnect": true,
      "usetls": true,
      "protocolVersion": "5",
      "keepalive": 60,
      "cleansession": true,
      "autoUnsubscribe": true,
      "birthTopic": "",
      "birthQos": "0",
      "birthRetain": "false",
      "birthPayload": "",
      "birthMsg": {},
      "closeTopic": "",
      "closeQos": "0",
      "closeRetain": "false",
      "closePayload": "",
      "closeMsg": {},
      "willTopic": "",
      "willQos": "0",
      "willRetain": "false",
      "willPayload": "",
      "willMsg": {},
      "userProps": "",
      "sessionExpiry": "",
      "credentials": {
        "user": "${MQTT_BROKER_USERNAME}",
        "password": "${MQTT_BROKER_PASSWORD}"
      }
    },
    // next nodes ...
],

```

And by extension, maybe I could do the same in my subflow json. This would be perfect for my use case as the credentials are just references to environment variables so there is no sensitive data stored in the subflow json file, and the subflow would be self-contained.

When I tried, at first it seemed like everything would be working fine as the credentials were picked up by the editor before packaging it.

 ![Credentials from subflow JSON picked up by Node-RED editor](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/6/960e79008d7a1d62a3618789a8490c6ebc329ed5.png)

However, at runtime, it cannot connect to the broker, and it seems like the credentials are undefined. Setting the same credentials in `flows_cred.json` works as expected.

Only official documentation I could find about inline credentials in a flow is for the `POST /flows` endpoint ( [POST /flows : Node-RED](https://nodered.org/docs/api/admin/methods/post/flows/) ) which I guess is kinda unrelated to the way the runtime reads the `flow.json` file and the packaged subflows.

So my question is, is that use case supported ? Has anyone done that ?  
Or was it not supposed to be picked up by the editor which is why it confuses me ?

Thanks for your help !

**Edit 1**  
I'm running Node-RED v4.1.4

**Edit 2**  
I found a few related posts including

> [@FR: export / import flows WITH the username and password - when they are ENV VARs](https://discourse.nodered.org/t/fr-export-import-flows-with-the-username-and-password-when-they-are-env-vars/63602):
>
> username and password are lost when export / import even though they are ENV VARs Could this be supported?

When considering exported flows, the answer makes sense, but in my case this is about flows/subflows which are edited manually to include the env variables to use when imported

**Edit 3**  
Found again the post where @knolleary mentionned flows can include credentials

> **[Sending MQTT username/password in flow JSON](https://groups.google.com/g/node-red/c/Dfhkiu9X8r0/m/vz2URAdsBgAJ)**

---

<div class="post-metadata">

**Author:** ![mattjcj](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/mattjcj/32/105562_2.png) [@mattjcj](https://discourse.nodered.org/u/mattjcj)\
**Post date:** [27 January 2026 10:26 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254/2 "2026-01-27T10:26:46Z")

</div>

Completely forgot, but during my research I also ended up on this issue where @knolleary seems to imply that my use case should be supported ?

> The runtime API's support the flow including credentials as that is what the editor uses to set them in the first place.

> <https://github.com/node-red/node-red/issues/925>
>
> Currently it is not possible to import a flow that has credentials attached to i…ndividual nodes. This is a reflection of the fact you cannot export a flow with credentials attached. But there are valid cases for wanting to import a flow that includes credentials, even if, currently, such a flow would have to have had the credentials added by hand.

So the question now is, is that not supported anymore ? Or is it a bug ?

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [27 January 2026 12:42 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254/3 "2026-01-27T12:42:28Z")

</div>

Welcome to the forum @mattjcj

Have you looked at combining environment variables with [dynamic subscription](https://discourse.nodered.org/t/dynamic-mqtt-nodes-actions-connect-guidance-needed/58878/2) for the mqtt nodes?

Perhaps set the variables in the flow tab where they will be in plain text but unobtrusive.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/9/690f00c73b3e564f0632aaa7ff3f50c8ab823a7f.png).

Use a function node to retrieve them and connect/disconnect/publish/etc dynamically.

---

<div class="post-metadata">

**Author:** ![mattjcj](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/mattjcj/32/105562_2.png) [@mattjcj](https://discourse.nodered.org/u/mattjcj)\
**Post date:** [27 January 2026 15:44 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254/4 "2026-01-27T15:44:27Z")

</div>

Hey, thanks !

Thank you for the suggestion. I was actually planning on using dynamic subscription as a workaround 🙂

I'll pre-configure these environment variables probably in `settings.js` or in the entrypoint of the container, so that they're fetched automatically from a secret manager with all the different credentials the users might need.

But I still wanted to figure out if the behavior I encountered was expected or an eventual bug. Fortunately the MQTT nodes are quite flexible and can be configured dynamically, but I'm not sure it'll be the case with all the nodes I'll end up working with later in my subflows.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [28 March 2026 15:45 UTC](https://discourse.nodered.org/t/is-it-possible-to-include-credentials-env-variables-in-a-flow-json/100254/5 "2026-03-28T15:45:11Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.