Remote Server Upload

What it actually does

You've got ComfyUI on one machine and you want the files somewhere else - a NAS, a box that serves a gallery, the GPU-less machine that runs your trainer. The default answer is "save to output/, then rsync, or remember to sync". This node deletes that step. Drop it at the end of the graph, give it an address, and every frame of the incoming IMAGE batch is encoded as PNG and POSTed straight to http://{address}:{port}/upload. Nothing is written to ComfyUI/output/ at all.

That last part is a real difference from SaveImage, which is where most workflows end and which is also the thing that embeds your whole graph in the file - the workflow and prompt text chunks the KB's image I/O essay is built around. This node encodes with Pillow and attaches no such chunks. The PNGs that land on your server are bare images: drag one back into ComfyUI and you get nothing. If you sometimes want the graph back, keep a SaveImage in parallel. They're not exclusive, and doubling up costs you disk, not clarity.

How the mechanism actually works

Two things happen before a single byte of image is sent. First, a health check: the node GETs the server root and accepts anything under HTTP 400 as alive - plus a bare 401 when you haven't turned credentials on, on the reasoning that the server is up and just wants a login. Fail that and it raises server at http://host:port/ is unreachable, so the queue item errors loudly instead of posting into the void.

Then, per file, it works out its own timeout: twice the measured round-trip, plus file size over Assumed Bandwidth, times the Safety Multiplier, floored at Minimum Timeout. The defaults are 5 MB/s, 3.0 and 30 seconds, and all four live in the pack's settings.json, read fresh each run. That's why small images don't flake on a flaky link while a fat batch can - the budget scales with the payload.

It also always runs. The schema marks it non-idempotent and fingerprint_inputs returns a timestamp, which is the engine's "yes, I changed, run me again" signal - ComfyUI's cache opt-out, the same family as the NaN trick the plumbing doc describes. Queue the same prompt twice, touch nothing, and it uploads twice. That's the point (re-push renders to the remote box without fiddling), but it also means a stray re-queue re-posts the batch.

Inputs and outputs

The whole surface is images, filename_prefix, address, port, use_credentials, username, password - all required, no optionals. And there is no output socket. It's a terminal sink: if it's in the graph, it runs; delete it and nothing uploads.

Three of those you actually set. Connect images. Set address and port (they pre-fill as 192.168.1.100:8765 from the pack's settings panel, which you should change once rather than per node). Give filename_prefix something - the default is image_%index%, and the prefix is a small template: %index% becomes a five-digit counter (00000), %batch_num% the plain index, plus %width%, %height%, %hour%, %date:yyyy-MM-dd% and friends. Right-click the node → Insert Filename Token if you'd rather not remember them. renders/%date:yyyy-MM-dd%/%hour%-%minute%_%index% is a nice one.

Auth is opt-in and slightly sneaky: Basic Auth is sent only when use_credentials is ticked and username is non-empty. An empty username means no credentials at all, which is precisely how you get a 401 while staring at a ticked toggle.

Installing it

ComfyUI Manager → Install via Git URL → paste https://github.com/wakaura-asaho/comfyui-remoteserverupload, then restart. Or, by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/wakaura-asaho/comfyui-remoteserverupload

Restart ComfyUI. That's the whole story - no model downloads, no _temp folder to pre-create. requirements.txt lists requests, tqdm, safetensors>=0.4.2, Pillow, numpy>=1.25.0, every one of which already ships with ComfyUI, so don't pip install torch into an existing environment to satisfy it. It's a V3-API pack (io.ComfyNode, define_schema, no NODE_CLASS_MAPPINGS dictionary if you go looking in the source), so it wants ComfyUI ≥ 0.12.3 and frontend ≥ 1.37.11. That's "new", not "broken".

Where people get burned

The health check is stricter than you think. A receiver that 404s its own root - plenty of minimal upload servers just have no index route - fails the probe even though /upload works fine. Same for a 403. Test the root in a browser or with curl -I http://host:8765/ before blaming the node.

401s split into two causes. No auth configured on the node, or wrong username/password. The error string it raises for that case literally says to check use_credentials, username and password, because those are the three moving parts.

Timeouts on big batches. Tune Assumed Bandwidth down and Safety Multiplier up under Settings → Remote Server Upload. On Wi-Fi the default 5 MB/s assumption is optimistic, and the multiplier is the only headroom you get.

Filename collisions. If your prefix has no %index% or %batch_num%, every frame asks for the same filename. Whether that overwrites or errors depends entirely on your server.

One more thing, since a node whose job is holding a login is exactly the shape the ecosystem's one real malware incident took (kg/entities/llmvision-incident.json - a node that harvested credentials and ended in a federal conviction): this pack is small and readable, remote_upload.py is 700 lines of requests, and it's worth a skim before you feed it a password. Also know that use_credentials and username are always saved into the workflow JSON; only the password is conditional, and only encrypted (RUENC1: blobs) if you set a Workflow Password Encryption Secret. That secret, and default_password in settings.json, sit in plain text on disk. Sharing a workflow with an embedded login is a decision, not an accident - make it deliberately.