RunningHub Node Info Replace
Build field overrides for a RunningHub API workflow
- node_info
- new_seed
This is a developer node, not a creative one, and it only makes sense if you're publishing workflows as APIs on RunningHub - the cloud ComfyUI host (that's what the RHAPI category stands for). If you're generating images at home, close this tab; nothing here helps you. If you're wiring up a RunningHub workflow that other code will call over HTTP with different inputs each time, this is one of the plumbing pieces.
The context that makes it click: RunningHub, like most things that let you reach ComfyUI over a browser, fully exposes the ComfyUI API. So you can take a workflow, mark certain nodes as parameters, and call the whole thing programmatically - new prompt here, new seed there, run it a thousand times. The catch is you have to describe which field on which node you're overriding. This node builds exactly that description, right inside the graph, and hands it out as a NODEINFO object the rest of the RHAPI machinery consumes.
How it works
You're not editing a node when you use this - you're producing a little override record that says "on node X, set field Y to value Z." That record travels out the node_info output. It has two extra tricks layered on top of the plain set-a-value case:
- a match/replace pass, so instead of overwriting a field wholesale you can find a substring and swap it - useful when you want to keep most of a prompt and only change one token per call.
- a seed cursor, so across repeated calls the value advances in a controlled pattern rather than staying fixed. That's what the
new_seedoutput is for: you feed it back in on the next iteration and the node walks forward.
None of this fires a generation by itself. It's a descriptor factory. The actual run happens when RunningHub's API executes the workflow with these overrides applied.
The inputs and outputs that matter
There are a lot of fields, but only a handful carry the load. The core three:
node_id(STRING) - which node in the target workflow you're overriding. This has to match the node's id in that workflow exactly, or the override lands nowhere.field_name(STRING) - which field on that node (the widget/parameter name).field_value(STRING, multiline) - the value you want it to take.
Then the optional-behavior fields (all still required inputs, just leave them at defaults when unused):
match/replace(STRING,replacemultiline) - substring find-and-swap on the field instead of a full overwrite. Leave both empty to just setfield_valuestraight.seed(INT),increment(INT, 1–1000), andrandom_mode(enum) - the cursor.random_modepicks how the seed advances:normal,reverse,odd_forward,even_forward,odd_reverse,even_reverse. The odd/even variants stride through alternating values; forward/reverse sets the direction. Not cycling anything? Leave it onnormal.comment(STRING) - a label for your own sanity; it doesn't change behavior, just keeps a complex override chain readable.
Outputs:
node_info(NODEINFO) - the override record. Wire it into the rest of your RHAPI graph. This type only means something to RunningHub's API layer, so don't expect to plug it into a stock ComfyUI node.new_seed(INT) - the advanced seed. Loop it back into the next call'sseedto keep the cursor moving.
How to install it
It's part of the ComfyUI-Addoor pack (the author's "葵花宝典 / Sunflower Manual" utility collection), in the newer RHAPI group:
- ComfyUI Manager - search ComfyUI-Addoor, install, restart.
- Git -
cd ComfyUI/custom_nodes && git clone https://github.com/Eagle-CN/ComfyUI-Addoor, thencd ComfyUI-Addoor && pip install -r requirements.txt, and restart ComfyUI.
No models, no heavy dependencies - it's plain-Python glue. On RunningHub the node is already available in their editor; you'd only install locally to build and test a workflow before pushing it up.
Common issues & troubleshooting
The number-one failure is a mismatched node_id or field_name. These are exact-match string keys into the target workflow - a typo, or a stale id after you rearranged the graph, means the override silently does nothing and your API call runs with the old value. When a parameter "won't take," check those two strings against the actual workflow JSON first.
Second: the NODEINFO output is RunningHub-specific, not a general ComfyUI type, so it only connects to nodes that expect it - don't route it into a normal sampler or text node.
And if you're using the seed cursor, new_seed has to flow back into the next iteration for the pattern to advance; otherwise every call gets the same starting seed and random_mode does nothing visible.
The honest summary: this is niche automation tooling for one cloud platform. It's well-shaped for what it does, but if "RunningHub API workflow" isn't a sentence you were already trying to build, this node isn't the one you were looking for.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| node_id | STRING | — | |
| field_name | STRING | — | |
| comment | STRING | — | |
| field_value | STRING | — | |
| match | STRING | — | |
| replace | STRING | — | |
| seed | INT | 00–18446744073709550000 | — |
| increment | INT | 11–1000 | — |
| random_mode | COMBO | normal | 6 options: normal, reverse, odd_forward, even_forward, odd_reverse, even_reverse |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| node_info | NODEINFO | — |
| new_seed | INT | — |