Remote Server Upload (Video)

What it's for

Video generation is where "the file is on the machine that made it" stops being an acceptable answer. A Wan or LTX run is minutes of GPU time and hundreds of megabytes of output, and the machine doing it is usually headless, in another room, and not where you're watching or editing. The normal workaround is a network share you hope is mounted, or copying the file off by hand after every batch.

This node takes the VIDEO socket and posts the finished clip to the same /upload endpoint the rest of the pack uses - one file, one upload, done. It's the pack's simplest node and the one the timeout settings exist for.

How it works

The interesting part is the container extension, because it decides what your server stores and what mime type it's told. The node only trusts the video's source path when that path actually comes back as a string - which means "this video came from a file on disk". For anything assembled in-graph from components, there's no filename to steal an extension from, so it falls back to mp4.

Then it does something deliberately unglamorous: it writes the whole video out to a uniquely-named temp file under the pack's _temp/ folder with that extension, uploads that file, and deletes it on success. The comment in the source says why - a real file path lets the encoder infer the container format reliably across ComfyUI versions, where handing it an in-memory stream is guesswork. The cost is one full copy of the clip on disk while the upload runs, and you should size your free space for it. A multi-gigabyte render is a multi-gigabyte temp file.

Failure handling is the same as the LoRA node and it's the good kind: if the upload doesn't go through, the temp copy is kept and its path is logged. You lose nothing, you can inspect the file, and the error tells you which one it was.

The connection protocol is the pack's shared one: a GET against the server root has to come back under HTTP 400 (a bare 401 counts as reachable when credentials are off), then the file's timeout is derived from its size against the assumed bandwidth, with a safety multiplier and a floor. Defaults are 5 MB/s, 3.0×, 30 seconds - all adjustable in Settings → Remote Server Upload.

Inputs and outputs

video, filename_prefix (default video), and the four connection/credential fields: address, port, use_credentials, username, password. No outputs.

Set the prefix and stop worrying about it, with two caveats worth knowing before you type anything clever. First, the extension is appended - the node writes prefix + "." + ext - so a prefix of shot.mp4 gives you shot.mp4.mp4. Second, the token table in the README overpromises for this node: the source calls the filename helper without a batch index and without image dimensions, so %index%/%batch_num% are left literal in the filename and %width%/%height% come out as 0. Only the date and time tokens resolve. render_%date:yyyy-MM-dd%_%hour%%minute% is the shape that actually works.

Installing

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

Restart, or grab it through ComfyUI Manager with the same URL. No models, no extra downloads - requests, tqdm, safetensors, Pillow and numpy are the entire dependency list and all of them ship with ComfyUI. Needs a reasonably current build (ComfyUI ≥ 0.12.3); it's a V3-API pack.

Where people get burned

Timeouts, and only for this node. An image upload that takes 40 seconds is fine; a 600 MB video on a 5 MB/s assumption gets a budget in the minutes, which is right for a LAN and wrong over anything slower. Lower Assumed Bandwidth and raise the Safety Multiplier if clips die mid-upload. The nice property of this node is that a timeout is cheap - the temp file survives, so nothing you waited for is lost.

A server root that isn't happy with a GET. The health check runs before the upload and a sub-400 response is required. A minimal receiver with no index route will fail the probe while /upload works perfectly, which sends people hunting in the wrong place entirely.

Body-size limits on the receiving end. Videos are the first thing that trips whatever sits in front of your file server, and a reverse proxy with a modest max request size is the usual culprit. That's a server-side fix, not a node setting - but it's the one to check first when small files land and clips don't.

_temp/ growing quietly. Successful uploads clean up after themselves. Failed ones don't. If you've been re-queueing against a server that's down, go empty ComfyUI/custom_nodes/comfyui-remoteserverupload/_temp/.

One design note, since this node always runs: the pack's outputs are marked non-idempotent so the queue can't skip them. Re-queue and your clip uploads again. Usually that's exactly what you want; occasionally it means you've now got three copies of the same render on the far end.