Upload To Remote

UploadToRemote-Browser is a sink: images go in, nothing comes out - but somewhere else, your render arrives as a base64-encoded JSON POST to a URL you chose. Think "webhook for your generations." You run a batch, and the results get shipped off to your own API, a serverless function, a custom gallery, a Discord-style bot endpoint, or any receiver that speaks JSON.

It fits the pack's whole pitch - ComfyUI Browser is about making your outputs and workflows portable - and this is the node that pushes results to the outside world instead of just storing them.

How it works

The node takes your IMAGE batch, re-encodes each image to the extension you picked (at the quality you set), optionally embeds the full workflow into the file's metadata, base64-encodes it, and POSTs a JSON payload - {"images": [...], "extra": ...} plus optional track_id and unique_id - to remote_url. It runs in a background thread, so the queue doesn't stall waiting on a slow remote. The workflow embedding is the ComfyUI-native touch: the same "workflow included" reproducibility culture that lives in PNG metadata, shipped over the wire instead.

The inputs that matter

• remote_url (required) - where the JSON POST goes. Reachable from your ComfyUI machine, since the request is made server-side, not from your browser.
• extension - jpeg, webp, png, jpg, or gif. You'll mostly use jpeg for size, png for lossless.
• quality - 1–100, default 85. Only meaningful for jpeg/webp.
• embed_workflow - true/false: embed the full workflow JSON as metadata (PNG PngInfo text, or EXIF for webp) so the receiver can reproduce the run.
• images (optional) - the batch to send; wire from your sampler/VAE decode.
• extra (optional, forceInput) - a string you have to wire in from another node (say, a Dify answer or a filename), included verbatim in the payload.
• track_id (optional) - your own id, posted as track_id so the receiver can correlate runs.

There are no outputs. It's a terminal node.

Gotchas worth knowing

Three real ones, all visible in the source. First, in the non-jpeg/webp branch the code hardcodes format="PNG", so choosing gif doesn't give you GIF bytes - it still ships PNG-encoded data. The label is aspirational; treat gif as "also PNG." Second, the node doesn't check the response: it logs the status code to the console and moves on, and the whole thing runs on a background thread. Build a tiny test receiver (even a python -m http.server-style stub) before you trust it with real results. Third, embed_workflow makes every payload dramatically bigger - fine for a private endpoint, wasteful if you're paying per request.

Install

Same pack, standard path:

cd ComfyUI/custom_nodes && git clone https://github.com/talesofai/comfyui-browser

or ComfyUI Manager → search comfyui-browser, then restart. No model downloads; the pack's dependencies (requests, numpy, pandas, tqdm, urllib3) are light. If you're pairing it with the pack's Dify node, remember both need their remote endpoints reachable from ComfyUI - a URL that works in your browser doesn't necessarily work from a headless server.