# Updating node config on deploy

**URL:** https://discourse.nodered.org/t/updating-node-config-on-deploy/90087
**Category:** Developing Nodes
**Created:** [10 August 2024 01:19 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087 "2024-08-10T01:19:35Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![TacticalNudge](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@TacticalNudge](https://discourse.nodered.org/u/TacticalNudge)
#### Post date: [10 August 2024 01:19 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/1 "2024-08-10T01:19:35Z")

</div>

Hi Everyone.

I am having a little difficulty with a scenario where we're interfacing with a third party system. The first time we deploy our node it does a considerable amount of setup and configuration that we have to use in subsequent interactions. Its a very manual, and multi-step process, and not something that we can repeat every time we deploy the flow.

The ideal place to store this additional information would be in the config that is passed to the node on initialization when a flow is deployed. We can use it as an indicator on the node editor that setup was previously done successfully and save us from having to do it again the next time the node gets deployed.

The only workaround I can think of at this point is to push a payload to the settings api (RED.settings.set) and use the node id as reference. The next time the node is opened for editing we would retrieve the settings via an ajax call for presentation purposes, and load it from the settings api when the node is deployed. The drawback with this will be that the additional settings will not be seen as part of the node and therefore won't be copied when the node is exported, requiring the setup process to be repeated if the node is copied (either locally or to a new NodeRed instance)

Any obvious workaround we are missing?

---

<div class="post-metadata">

### Author: ![ralphwetzel](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ralphwetzel/32/53713_2.png) [@ralphwetzel](https://discourse.nodered.org/u/ralphwetzel)
#### Post date: [10 August 2024 07:45 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/2 "2024-08-10T07:45:53Z")

</div>

Perhaps I'm not fully getting your issue - yet what I understand seems be achievable by standard NR features: Have you tried to implement your pattern by using [`Node properties`](https://nodered.org/docs/creating-nodes/properties)? Properties need not to be set (only) by UI, but can as well be populated by your node's code. They may as well hold any JS object (as long as they are serializable) allowing to store quite complex data.

---

<div class="post-metadata">

### Author: ![TacticalNudge](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@TacticalNudge](https://discourse.nodered.org/u/TacticalNudge)
#### Post date: [10 August 2024 09:46 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/3 "2024-08-10T09:46:12Z")

</div>

> [@ralphwetzel](#):
>
> Perhaps I'm not fully getting your issue -

Apologies. I tend to be very bad at explaining. I used "config" and "properties" interchangeably in my message.

We already have a couple of basic properties set when initializing the node in the backend, but part of the initialization process generates some additional values which we would like to persist as part of the properties.

eg:

```javascript

function FooSystemConfig(config) {
    let node = this;
    RED.nodes.createNode(node,config);

    if(!config.setup){
        config.setup = doReallyExpensiveSetup(config);
    }

    // config.setup won't be persisted as it wasn't set in the editor.

};
RED.nodes.registerType("FooSystem Config",FooSystemConfig);

```

I have built another version by wrapping the `doReallyExpensiveSetup` call in a webhook that gets triggered from the `oneditsave()` function in the editor. This does fit the bill for packaging `setup` as part of the properties, but it does mean that `doReallyExpensiveSetup` is done during the edit phase as opposed to the deploy phase. If you edited the flow but decide to discard changes by not deploying the flow, you have already done `doReallyExpensiveSetup` which now has to be reversed in the third party system. It also means that the connection between nodered and the third party system is broken for the duration between editing the node and deploying the flow, which is why I discarded this approach.

---

<div class="post-metadata">

### Author: ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [10 August 2024 10:31 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/4 "2024-08-10T10:31:22Z")

</div>

A common method is to do it in two steps:

1. user adds the node, configures static configs and deploys.
2. user reopens the node to configure all the new dynamically added configs. What matters here is the redeployment because without it you can't save new configs to NR.

If this method doesn't suit you, the only other solution is to use the Storage API to save your stuff but since it's not very used there aren't many examples.

---

<div class="post-metadata">

### Author: ![TacticalNudge](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@TacticalNudge](https://discourse.nodered.org/u/TacticalNudge)
#### Post date: [10 August 2024 10:48 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/5 "2024-08-10T10:48:40Z")

</div>

> [@GogoVega](#):
>
> A common method is to do it in two steps

Thanks! This is pretty much the solution for now, with the dynamic properties being merged in from the settings api during `oneditprepare`

The question was asked in part to make sure I didn't miss an obvious pattern where properties can be dynamically updated on deployment.

---

<div class="post-metadata">

### Author: ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)
#### Post date: [10 August 2024 11:01 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/6 "2024-08-10T11:01:06Z")

</div>

No need to use settings, you can use your own route with `$.getJSON`:

Editor:

> <https://github.com/node-red/node-red/blob/8af821d380ddd6a3368dfa6705ba1e58c72bfba8/packages/node_modules/%40node-red/nodes/core/network/32-udp.html#L114>

Runtime:

> <https://github.com/node-red/node-red/blob/8af821d380ddd6a3368dfa6705ba1e58c72bfba8/packages/node_modules/%40node-red/nodes/core/network/32-udp.js#L133>

---

<div class="post-metadata">

### Author: ![TacticalNudge](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@TacticalNudge](https://discourse.nodered.org/u/TacticalNudge)
#### Post date: [10 August 2024 11:59 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/7 "2024-08-10T11:59:44Z")

</div>

You still need to use `settings` in order for it to survive restarts.

```javascript
RED.httpAdmin.post("/fooService/getSettings", RED.auth.needsPermission("inject.write"), function(request,response) {
    response.json(RED.settings.get("FooService_" + request.body.nodeId));
});

```

---

<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: [24 August 2024 12:00 UTC](https://discourse.nodered.org/t/updating-node-config-on-deploy/90087/8 "2024-08-24T12:00:11Z")

</div>

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