Apply Values to Remote Nodes

Dispatching a job to a remote ComfyUI instance is great until you need that remote run to use a different checkpoint, a different step count, or a different value on just one node - without keeping two separate workflow files in sync by hand. This node is how NetDist_Plus handles that: point it at a node ID and a parameter name on the remote graph, give it a value, and it packages that as an override to be applied right before the job fires.

Inputs and outputs

Four fields:

• nodeid - the target node's internal ID inside the remote workflow, as a string.
• param - the parameter name to override, e.g. seed, steps, ckpt_name.
• value - the replacement value, typed as plain text.
• type - a dropdown locked to STRING, INT, FLOAT, or BOOL, defaulting to STRING. Set it to match what the target parameter actually expects.

One output: remote_apply, a REMOTEAPPLY type. Plug it into any of the ten remoteapply1–remoteapply10 optional slots on RemoteQueueSimple-Nux or RemoteChainStart-Nux. Each of those nodes has ten such slots, so you can stack up to ten overrides on a single queue call.

The other "Apply Values" node

The pack also ships RemoteApplyValuesMulti-Nux, with the same display name and nearly identical fields. The only real schema difference is type: here it's a restricted dropdown, on the Multi version it's a free-typed string. Functionally they wire into the same slots and do the same job - use whichever one you reach for first.

Installing it

ComfyUI Manager: search ComfyUI_NetDist_Plus. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/nux1111/ComfyUI_NetDist_Plus
pip install requests

Restart ComfyUI. No models to download.

Where people get burned

The most common miss is nodeid drift - the ID has to match what's actually saved in the remote workflow's JSON, and if that workflow's been edited since it was last saved, the number you see in your own local canvas may not match anymore. Open the remote workflow directly and check the real node ID (dev mode / node properties) before assuming your override should have landed.

Getting the type dropdown wrong for the target field is the second common trap - set it to STRING for a parameter the target node expects as INT, and the override is likely to fail quietly, or throw an error on the remote instance's own console rather than surfacing anywhere you're looking.

Category-wise this sits under remote/advanced for a reason - it's not something you need for the basic dual-GPU setup in the README. Reach for it once you're actually trying to vary what a remote job does from queue call to queue call, not before.