Nodes/comfy_remote_run/RemRun Serializer Output (Internal)
ComfyUI Node

RemRun Serializer Output (Internal)

How Results Get Back to Your Machine

By LatentRat·Created 2 years ago·Updated 9 months ago· 12
RemRun Serializer Output (Internal)
  • input_0
  • input_1
  • input_2
  • input_3
  • input_4
  • input_5
  • input_6
  • input_7
  • input_8
  • input_9
  • STRING
serializationfancy_safetensors
max_size_mb32
gzip_compressionfalse
gzip_level9
responsebinary
is_changedfalse

The Deserializer node is the inbox on the far side; this is the outbox. RemRun Serializer Output runs at the end of a remote-run subgraph - on the remote machine - and is responsible for turning whatever it's handed into a serialized blob and shipping it back to your local ComfyUI. It lives in Remote Run/__Internal__/, and like its Deserializer counterpart, you won't normally drag it into a graph yourself. The RemRun Input and RemRun JSON nodes generate it automatically when they expand your workflow for the remote side.

If you're wondering how anything makes the round trip at all: this is it. The local machine posts the subgraph to the remote, the remote computes, and this node packs up the results and fires them back over a websocket that the local side is listening on.

How it works

Every input wired into it gets serialized with whatever serialization mode you chose, and the bytes are sent back one of two ways, set by response:

  • binary (default) - the serialized bytes are sent as a raw binary websocket message with a magic integer header (the pack uses a specific message id so the receiver can recognize it as a RemoteRun response rather than random websocket traffic). This is the fast path.
  • base64_result - the data is base64-encoded and returned as a normal ComfyUI result, which is the mode you'd want if you're driving the remote via plain API calls where binary websocket messages are awkward.

gzip_compression and gzip_level (default 9) will compress the payload first, and the node is smart about it - it only keeps the compressed version if it actually shrank the data by at least 1%, otherwise it sends the original and says so in the log. max_size_mb (default 32) is the guardrail: exceed it and the node raises a clear "Serialized data too large" error instead of choking downstream.

The inputs

serialization (required) - fancy_safetensors, unsafe_torch_pt, or safe_torch_pt, matching whatever the local side used. Then input_0 through input_9 for the values to send back, plus max_size_mb, gzip_compression, gzip_level, response, and is_changed.

Its one output is a STRING - in binary mode it's just an empty string (the real payload traveled over the websocket), in base64_result mode it's the encoded blob.

The gotcha that bites

Binary mode needs a connected client. The node sends its payload via ComfyUI's prompt server to the currently-attached client session, and if there isn't one it raises No client connected to send binary response to. That's the single most common way a remote run fails in this pack: you fire a run through a bare API call with no browser session on the local machine and the far side has nobody to hand the result to. If you hit it, either keep the local ComfyUI web UI open, or switch response to base64_result. It's one of those "the name is a lie" moments - nothing about this node is obviously web-session-dependent until it silently can't send.

CategoryRemote Run/__Internal__/

Inputs (16)

NameTypeDefaultDescription
serializationCOMBOfancy_safetensors3 options: safe_torch_pt, unsafe_torch_pt, fancy_safetensors
input_0opt*
input_1opt*
input_2opt*
input_3opt*
input_4opt*
input_5opt*
input_6opt*
input_7opt*
input_8opt*
input_9opt*
max_size_mboptINT320–8192
gzip_compressionoptBOOLEANfalse
gzip_leveloptINT91–9
responseoptCOMBObinary2 options: base64_result, binary
is_changedoptBOOLEANfalse

Outputs (1)

NameTypeDescription
STRINGSTRING