# Single instance subflow

**URL:** <https://discourse.nodered.org/t/single-instance-subflow/99434>\
**Category:** Feature Requests\
**Created:** [17 October 2025 20:11 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434 "2025-10-17T20:11:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [17 October 2025 20:11 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/1 "2025-10-17T20:11:46Z")

</div>

Each time a subflow is used, it creates a new instance. Most of my subflows don't need separate instances. It would be so cool to have an option to make a subflow singleton. Not only nice to have in terms of performance, but sometimes straight up necessary.

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [17 October 2025 20:21 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/2 "2025-10-17T20:21:19Z")

</div>

It sounds like you need to use the `link call` node?  
It offers much of the same benefit + your requirements?

it "looks" different - but is the same principle but with a state engine, that is shared in the flow - given its in the flow

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [17 October 2025 20:23 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/3 "2025-10-17T20:23:19Z")

</div>

It doesn't offer much IMO. Always 1 input, always 1 output. Takes space in flows. I want something flexible where I can choose any amount of outputs and zero input. Something that can take env vars in a nice menu. With nice icons sprinkled on too 😃 And source code is always hidden away outside flows when I don't need to look at it. I much enjoy how subflows hide how things are done, which lets me focus in flows on what is done.

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [17 October 2025 20:32 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/4 "2025-10-17T20:32:01Z")

</div>

So if your intent is to stick with a subflow -you know that a subrow can still use vars outside its context - emulating a single state?

```auto
flow.get('$parent.xxxx')

```

I, of course am not aware of your setup, but some flexibility is not documented well IMO.  
With my example above, all sub flows, **can** share the same state

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [17 October 2025 22:00 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/5 "2025-10-17T22:00:01Z")

</div>

Sure I could share state with parent flow. I'd also like to keep single instance, like a link call. Both are useful, but not the same thing.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [17 October 2025 22:26 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/6 "2025-10-17T22:26:35Z")

</div>

Hey folks.

@ThingsTinkerer  
I sort of feel your confusion.

`subflows` were around long before the `link call` and so I went down the `subflow` path because I had a LOT of repeated _code_ in a LOT of places and updating them was painful.

The `link call` came out and I tried to use it and it didn't work.  
(I'm not assigning blame here)  
And after a lot of mucking about I did get SOME of them working and it does work for some instances where I use it now.

> [@ThingsTinkerer](#):
>
> Always 1 input, always 1 output.

_Yes, but you didn't exactly say anything about how many outputs you want._

I do get the _takes up space_ argument too. Believe me: flows nowadays are way bigger than they used to be. 🙂

I'm not saying either way is _BETTER_ than the other.

But you stated `SINGLE INSTANCE SUBFLOW` in the title, so I'm confused.

Yes, it is nicer and _neater_ with the subflow's node, colour and icon....  
But if it is SINGLE INSTANCE...... 🤷

You can _tuck it away_ in a corner of the flow, or..... put it in/on it's own flow.  
(And you can hide that flow if you really want. But I digress.)

You may need to think a bit more about what you are wanting to do.  
Again: I'm not saying it is wrong.

If you'll indulge me:  
(And I'm still guilty of this myself.)

When I made flows, everything was _THERE_, mixed up.  
The machinery of getting things done and the GUI.  
(the _workings_ and the _eye candy_ - if you will)

And all this was done on the _OLD_ `dashboard`

So if/when I update to the newer one, it is ...... painful.

It would have been easier if I kept the two parts separated in/on the tab.  
That way I would just add the newer node beside the older one, test it, and then delete the older one once happy.  
The way i have it there is no difference to doing it, but the nodes are _WAY DOWN IN THE GUTS OF THINGS_ and I have to dig through the wires to get clean access to the GUI node.

So: should I redesign all the flows ti suite the new idea? I don't know.  
But it is something of which I am putting a bit of thought into.

I suspect this scenario is very VERY similar to mine.

## What do you want?

If it is a _ONE OFF_, it isn't a problem - I'm guessing - which way you go.  
But it may be interesting to try both ways.  
That way you (should) learn something about the workings of the other way and it may help you in the future.

Just saying.

Good luck. It is not fun when you are stuck with this kind of choice: _Do I do it this way or that way?_  
Remember: There is no wrong way, as long as it works.

---

<div class="post-metadata">

**Author:** ![bakman2](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bakman2/32/6207_2.png) [@bakman2](https://discourse.nodered.org/u/bakman2)\
**Post date:** [18 October 2025 05:12 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/7 "2025-10-18T05:12:36Z")

</div>

Recently i posted a feature request for [collapsable groups](https://discourse.nodered.org/t/collapsible-expandable-groups-ie-like-subflows-without-instantiation/99207) (which is similar to your request), not sure if they give it a second thought.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [18 October 2025 05:48 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/8 "2025-10-18T05:48:47Z")

</div>

I don't understand exactly what you mean by a Singleton subflow.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [18 October 2025 07:10 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/9 "2025-10-18T07:10:37Z")

</div>

> [@bakman2](#):
>
> they give it a second thought

A second, third and more.

I think it has benefits. A group (collapsible or not) with an input and one or more outputs would be pretty good as far as I'm concerned. It would be pretty much a portable, singleton flow with the benefit of having its own environment variables. Then if it could be called via link call, all sorts of magic starts to happen. Yes, I think it's a pretty good idea, but it's a lot of work and it's going to need a lot of thought, design, fleshing out, traction & support. Perhaps it is what link-call subroutines should have been?

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [18 October 2025 17:07 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/10 "2025-10-18T17:07:44Z")

</div>

I can give one example: Made a subflow 'wrapper' for input node, or more precisely the cron node. It has menu to select interval for generating a message (an event), used to trigger something, for example I/O (read some data, then write it or send it somewhere, db, api etc.). Can configure to every 1 minute, 5 minutes, 1 hour++. It can also have option to add some flags if it is whole hour. Since subflows can't add buttons like input has, I also have an input which I can attach a normal input to, which will generate a message with a manual trigger flag (picked this up from another node and it was really useful). Maybe all this sounds useless for what you're doing, but I use it a lot.

Very close to normal nodes, but with some additional features sprinkled on top. Every time I use this subflow, it creates new instances of these nodes. But it's excessive, I only need one.

This is probably insignificant in terms of performance. But I have more complex use cases too where I need values in context to be handled "atomically" or at least very low risk of race conflicts. I was forced to use link call for this task, but it would be a lot cleaner to have it in a subflow instead.

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [18 October 2025 19:58 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/11 "2025-10-18T19:58:03Z")

</div>

I think the runtime creates a new instance because if there was a single one, the runtime would end up triggering all nodes connected to this singleton node, and not just the branch that started it. For example,

Considering B is the singleton subflow

A -\> B -\> C

D -\> B -\> E

When A's output flow into B, B's output would trigger both C and E, like if a cloned message teleported to another branch. However, it is expected that only C is triggered since there is no direct connection between the graphs.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [18 October 2025 20:01 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/12 "2025-10-18T20:01:20Z")

</div>

What is the functional difference between a singleton subflow and a normal subflow?

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [18 October 2025 20:15 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/13 "2025-10-18T20:15:06Z")

</div>

Maybe the solution is to allow developers to select multiple nodes of the same type and provide a new context menu option called “Bind.” When clicked, all selected nodes would share the same node context, credentials and configs. Each node instance would still exist separately to ensure proper message routing, but they would now share a single context store, credentials and configs, effectively behaving like a singleton.

There could also exist multiple shared instances groups of nodes of same type. For example, consider a node type B in these isolated graphs:

A -\> B -\> C  
D -\> B -\> E  
F -\> B -\> G  
H -\> B -\> J

Nodes B from branches 1, 2, and 3 could share a context store, credentials and configs, while the B node from branch 4 share a different context store, credentials and configs.

When editing a config or credential of node that pertains to the same shared instance, all nodes of its group change as well. In memory, they all have a reference to the same config or credentials object.

A visual cue would help users identify which nodes belong to the same shared instance.

A new prop called "shared\_instance\_id" would be added to the exported json.

```json
[
{
  "id": "1111111",
  "type": "B",
  "shared_instance_id": "99999999",
},
{
  "id": "1111112",
  "type": "B",
  "shared_instance_id": "999999999",
},
{
  "id": "1111113",
  "type": "B",
  "shared_instance_id": "99999999",
},
{
  "id": "1111114",
  "type": "B",
  "prop": "brazil",
},
{
  "id": "99999999",
  "type": "shared_instance",
  "prop": "uk",
}
]

```

A node can't be in two different shared instances at the same time.

When mapping context stores, shared\_instance\_id would be used instead of the node's id.

What do you guys think of this design? It would not change much of the core and it would be kind simple to implement, "I THINK"

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [18 October 2025 21:09 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/14 "2025-10-18T21:09:31Z")

</div>

#### Singleton Sublows

The concept of a ‘singleton subflow’ has been around since the day we added subflows to Node-RED - [Singleton subflows · Issue #596 · node-red/node-red · GitHub](https://github.com/node-red/node-red/issues/596) - 10 years…. but hasn’t made it further (yet).

One of the challenges is, as @AllanOricil described, is that if they are all the same instance, then routing the outputs is a tricky problem to solve. It could be done with message meta-data, but that would break if, for example, a Function node generated ‘new’ message objects inside the subflow. These are the same restrictions faced by the Link-Call nodes.

#### Collapsing Groups

There is definitely merit to this idea, but again, there is some tricky detail that can’t just be waved away. Lets say I’ve created a large group in the middle of the workspace. I now collapse it down to a single ‘group’ node. That has left a big gap in the middle of the workspace, so I rearrange all my nodes to use that space. What happens when I expand the group again to modify its contents? It will overlap all of my other nodes. This is one of the reasons subflows open in a new tab.

#### A combination of the two….

I think the ultimate answer will be a combination of the two.

_If_ we can figure out the technical implementation of singleton subflows (to solve the output routing), _and_ all of the UX to avoid confusion between regular subflow instances and singleton subflow instances, then there would be no reason they couldn’t also be ‘callable’ by link nodes.

We already have the ‘selection to subflow’ action to create a subflow from flows you’ve already created. That works just as well turning a group into a subflow.

@AllanOricil It feels to me that is trying to solve a different set of problems here. I don’t immediately see how that would work in practice with how Nodes exist in the runtime.

My preference is (and has been for 10 years it would appear) to look at the singleton subflow approach as its a natural extension of concepts users are already familiar with.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [18 October 2025 21:21 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/15 "2025-10-18T21:21:32Z")

</div>

> [@ThingsTinkerer](#):
>
> It has menu to select interval for generating a message (an event), used to trigger something, for example I/O (read some data, then write it or send it somewhere, db, api etc.). Can configure to every 1 minute, 5 minutes, 1 hour++. It can also have option to add some flags if it is whole hour

Do you mean your subflow let's you configure these options on each instance of the subflow? Or that you configure the node inside the subflow how you want and just add instances of the subflow where you need it?

Maybe a screenshot/export of an example flow would be helpful to understand your scenario.

With a singleton subflow approach, you wouldn't be able to set properties differently between different instances. If you edited one, those changes (properties, env vars etc) would apply to all instances by definition as thats what singleton means here.

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [18 October 2025 22:16 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/16 "2025-10-18T22:16:51Z")

</div>

Hmm yeah you're right. Not sure if possible, but it would have to distinguish on env variables as I make the subflow menu to select which interval to output on. Not nodes inside, they're dynamic to use the selected env settings.

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [19 October 2025 00:11 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/17 "2025-10-19T00:11:30Z")

</div>

> [@knolleary](#):
>
> @AllanOricil It feels to me that is trying to solve a different set of problems here. I don’t immediately see how that would work in practice with how Nodes exist in the runtime.

Suppose we have a subflow B used multiple times in different graphs. The current setup looks like this:

```auto
Graph 1: A -> B -> C
Graph 2: D -> B -> E
Graph 3: F -> B -> G
Graph 4: H -> B -> I

```

### Problem:

Currently, Node-RED treats each usage of subflow B as a separate instance. That means if the user wants the same behavior across graphs 1, 2, and 3, he end up creating 3 identical copies of B (3\*number of nodes in B). Each copy has its own:

- Message queue
- Configuration
- Environment variables
- Credentials
- Context store

This causes unnecessary duplication and makes it hard to maintain a “single source of truth.”

### Current workaround:

Users sometimes manually wrap B with link nodes to reuse a single instance:

```auto
Graph 5: LI -> B -> LO

```

And then connect it to graphs 1, 2, and 3:

```auto
Graph 1: A -> LC5.1 -> C
Graph 2: D -> LC5.2 -> E
Graph 3: F -> LC5.3 -> G
Graph 4: H -> B -> I
Graph 5: LI -> B -> LO

```

### Problem with this workaround:

- Extra link call nodes (LC5.x) increase visual complexity, and possibly the runtime setup because of the extra nodes and virtual wires.
- Graphs become harder to read and maintain. User must move around different parts of the canvas to find where the link call node leads, and then open the subflow. There is also the extra cogntive load caused by extra virtual wires drawn in the canvas. Whereas in my approach Users just have to click on the node to open its subflow, and no extra visual information, besides a simple visual cue to let users know which nodes are bound together, has to be rendered.

### Proposed solution:

Instead of wrapping B with link nodes, we could allow multiple nodes to share a single subflow instance internally, when "Binding" nodes:

```auto
Graph 1: A -> B1 -> C
Graph 2: D -> B2 -> E
Graph 3: F -> B3 -> G
Graph 4: H -> B4 -> I

```

Where:

- B1, B2, and B3 all reference the same internal instance of subflow B because the User selected the 3 and then clicked on "Bind"
- B4 is a separate instance, independent of the shared one. This one is an example to show the user can still have another independent instance of the subflow B.

### Benefits:

- No extra link nodes — the graph stays compact and readable.
- Reading the flow is easier since you dont have to move around the canvas to understand what the link call node is calling.
- Single source of truth for multiple graphs sharing the same instance of subflow B— updates to one of the nodes that share this instance of subflow B automatically propagate to all other nodes using the same shared instance.
- Minimal duplication — only one actual runtime instance exists for shared nodes
- Simpler maintenance — message queues, context, and config are centralized

Essentially, each “node” can proxy messages to a shared internal subflow instance without changing the external graph structure.

What do you think? Is it clearwr now? If is not, can we do an exercise and simulate scenarios to verify if this model breaks? @knolleary

### How to turn the whole type into a Singleton

If the User select only one node of any given type, another context menu called "Bind All" appears which can be used to effectively turn that type a singleton. Any node of that given type added to the canvas after turning the "type" into a singleton is bound to the same instance. The exported json has to have a new entry to enable the editor know that the type is a singleton and any new node added of that type must also be bound to the unique singleton group.

```json
[
{
   "singletons": ["B"],
}
]

```

This new prop is added in the beginning of the flow.json and is an array of strings. It stores all types that were turned into a singleton.

### How can Bind Selected/Bind All be implemented without breaking the core

When processing flows.json additional wires are created automatically (runtime only) to ensure routing from the B node goes into the subflow nodes, and then return to the node that is expecting the output in the right graph. For example, the B node of graphs and 2 are bound, and visually look like

```auto
Graph 1: A -> B -> C
Graph 2: D -> B -> E
Graph 3 (subflow B): in -> B.1 -> B.2 -> out

```

When processed, the runtime graph becomes

```bash
A -> B1.1 -> B1.2 -> C
     | |
D -> -> E

```

obs: Bx.y

- where x is the index of the subflow instance (remember, there can exist 1:n bound groups - when there is only one it means it is a type singleton)
- where y is the index of the node instance inside the subflow instance

The msg is automatically injected with a core param called `msg.__output_ids` which is set with the Ids of the nodes connected to their respective B nodes (from the real graph) right before entering the subflow. The subflow output will determine the index of the port it has to send the msg to using `msg.__output_ids` and then create the right array to pass to send, for example `this.send([undefined, msg])` would be used if B1.2 needs to send its output to E only, therefore selecting the right output port.

`msg.__output_ids` must be non enumerable, non writable, and non configurable array of strings to ensure the core implementation isn't ruined at runtime.

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [20 October 2025 22:30 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/18 "2025-10-20T22:30:12Z")

</div>

No comments?

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [21 October 2025 08:48 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/19 "2025-10-21T08:48:32Z")

</div>

@AllanOricil Thanks for clarifying it. It is a possible approach. I think one of the main design challenges will be what makes sense for the user in the workspace.

With your proposal, then subflows will ‘sometimes’ be singletons - and may have different groups of singletons. Visually, that’s quite a lot of information to communicate in a way that doesn’t overload the user.

The alternative of just saying ‘this is a singleton subflow’ then we just need one visual way to indicate this consistently across all of the instances of the subflow added.

That wouldn’t stop us iterating in the future to allow the hybrid approach, but I do think we need to take this one step at a time.

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [21 October 2025 20:38 UTC](https://discourse.nodered.org/t/single-instance-subflow/99434/20 "2025-10-21T20:38:32Z")

</div>

@knolleary

> [@knolleary](#):
>
> With your proposal, then subflows will ‘sometimes’ be singletons - and may have different groups of singletons. Visually, that’s quite a lot of information to communicate in a way that doesn’t overload the user

I understand the concern around visual overload — especially if subflows can have multiple binding groups that behave like separate singleton sets. That said, this feature is deliberately opt-in and targeted at advanced users, not part of the default workflow.

The core intent behind “binding groups” is memory and state optimization, not visual proliferation. In practice, most users who enable it will create only a single binding group per subflow type — effectively making it a singleton.

When viewed from that angle, this feature actually reduces visual and cognitive load. Instead of wiring multiple link call nodes and tracing virtual connections across the canvas, users can rely on a single shared instance, simplifying both the design and the runtime representation.

In short, while it introduces an advanced capability, the net visual complexity goes down, not up, because bound or singleton subflows collapse redundant elements rather than adding new ones.

> [@knolleary](#):
>
> The alternative of just saying ‘this is a singleton subflow’ then we just need one visual way to indicate this consistently across all of the instances of the subflow added.

I’ve been thinking about how to visually represent “binding groups,” including cases where an entire type is a Singleton.

Here’s a proposal: use the ASCII symbol ⦿ in the top-left corner of nodes that belong to a binding group. I chose this symbol because it visually represents the concept: a circle contained within a boundary — much like a “binding group,” where related instances are encapsulated within a shared context.

- ⦿ indicates the node is part of a binding group.
- Same color ⦿ → same binding group. Colors are randomized based on an algorithm that uses the node's color as input and outputs the color with the best contrast. If the User wants to choose a different color for a specific binding group he can do it opening the node's editor panel.
- Black ⦿ → Singleton.
- Singleton types also display the ⦿ symbol in the Palette, so users can immediately recognize that the type has been defined as a Singleton.
- TODO: think about a way to show/manage the binding groups of a specific type somewhere in the UI. This is going to be used mostly by advanced Users and can be implemented later.

This approach keeps the visual language compact, consistent, and intuitive—without adding extra UI elements or clutter.

> [@knolleary](#):
>
> That wouldn’t stop us iterating in the future to allow the hybrid approach, but I do think we need to take this one step at a time.

I completely agree that we should move step by step and begin with the Singleton implementation — it’s the most straightforward use case and provides immediate value. However, it’s important that the initial design and data model are built with binding groups in mind, even if they’re not fully exposed at first. That way, we won’t need to refactor core logic later when expanding beyond singletons; we’ll simply extend the existing structure to support multiple groups seamlessly.

**obs: the whole idea and design WAS NOT made by AI. I only used AI to rewrite my thoughts in a better way since I'm not good at english**

If you guys agree with implementing the idea, improve and review the design, I can help with the implementation as a tester and reviewer. I got motivated to design a solution to the singleton problem but I don’t have the drive to implement it. @GogoVega is probably a good candidate to implement this

[Next page](https://discourse.nodered.org/t/single-instance-subflow/99434.md?page=2)