Remote Server Upload (Dataset)

What it's for

Same pack, same connection widgets, one job beyond the plain image uploader: this one takes a list of images and, if you wire it, a matching list of caption strings - and uploads the whole thing as image files plus .txt sidecars.

That's the training-set convention every trainer reads: 0001.png sitting next to 0001.txt, same basename, one caption per image. kohya requires it, ai-toolkit and OneTrainer follow it, and it's the reason captions are separate files rather than baked into the pixels in the first place - you can bulk-edit them with ordinary text tools and see at a glance which image is missing one. Caption content is a whole discipline and the KB's LoRA training essay owns it; this node is only the plumbing that gets the pairs onto the training machine.

That's the use case. Your dataset lives on the machine with the good screen and the folder of hand-picked references. The trainer lives on the box with the good card. Instead of zipping and scp'ing after every curation pass, you wire the images up, queue, and the folder appears.

How it works, mechanically

This node declares is_input_list. That's the engine feature that lets a node accept lists instead of single values - each item in the list becomes one uploaded file, and each image (or caption) can arrive from a separate upstream node rather than from one fat batch. Every list item image is PNG-encoded and POSTed as a multipart files field, exactly like the base node, and for the same reason it carries no embedded workflow chunk.

When texts is connected, the caption at the same index goes up with the same basename and a .txt extension, UTF-8 encoded. Pairing is strictly by position and nothing else - no fuzzy matching, no ordering cleverness. Counts don't need to be identical, though: the loop only writes a sidecar when a caption actually exists at that index, so a few excess images still upload, just caption-less. The progress counter credits sidecars only for images that have them.

The connection probe and the per-file timeout math are the pack's standard kit: a GET against the server root must come back under HTTP 400 (a bare 401 counts as reachable), and each file's timeout scales with its size against the configured bandwidth assumption. Read the sibling node's article if you want that reasoning in full - it's identical here.

Inputs and outputs

images (the list), texts (optional, and note it's a wire-only input - force_input, so you can't type a caption into the node itself), filename_prefix (default image_%index%), then address, port, use_credentials, username, password. No outputs, same as the rest of the pack: it's a terminal output node.

Two things that matter more than they look:

Shared settings come from the first list entry. filename_prefix, address, port and the credentials are read off entry zero and applied to every file in the run. Wire ten loaders with ten different addresses and nine of them are decoration. Set the connection once on the node and stop thinking about it.

Order is the whole caption contract. One caption per image, in the same order. If you're getting captions from a one-text-node-per-image setup, that's on you to keep aligned - the node just zips positionally and will happily attach image 7's caption to image 7 even if image 7 is the wrong picture.

Naming: the default prefix produces image_00000.png and image_00000.txt. %index% is the zero-padded five-digit counter, %batch_num% the plain one, and %width%/%height%/date tokens resolve here too. Include an index token - a prefix that resolves to one fixed name gives you one file per run at best, and a clobbered dataset at worst.

Installing

Identical to the rest of the pack, because it is the rest of the pack:

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

Restart, or use ComfyUI Manager's Install via Git URL with that same link. No models to download. The dependency list (requests, tqdm, safetensors, Pillow, numpy) is all stuff ComfyUI already has. The pack targets ComfyUI ≥ 0.12.3 on the V3 node API.

Where people get burned

• 401s and health-check failures - same three suspects as the image node: use_credentials off, username empty (auth is skipped entirely when it is), or a receiver that doesn't answer its own root path with something under 400.
• Timeouts on a big set. A few hundred images over Wi-Fi will outrun the default 5 MB/s bandwidth assumption. Drop it, raise the Safety Multiplier, and re-queue - the node has no resume, so a failing run restarts from the top.
• Captions landing one image off. Almost always a misaligned list, not a node bug. Upload five files and check the pairing before you push a thousand.
• Expecting the uploaded PNGs to carry your workflow. They don't, same as the base node - Pillow writes no text chunks. If your dataset images need to be reproducible as graphs, they're not that.