Remote Server Upload (LoRA)

What it's for

The training loop is annoying in a very specific way. You train on the workstation, then the LoRA has to exist on the inference box before you can look at what it actually does - so out comes scp, or a shared folder that half the time isn't mounted, or a USB stick if you're honest about how this has gone before. This node collapses that into the same queue press that produced the weights: hook a LoRA-model output to it, press queue, and the .safetensors file is on the server.

It's the least dramatic of the pack's four nodes and probably the most convenient, because LoRA files are small - tens of megabytes, occasionally a couple hundred. Nothing here is a bandwidth problem.

How it works

There's no shortcut where a file gets copied. The node takes the LoRA object, serializes its state dict to a temporary .safetensors file inside the pack's _temp/ folder, then POSTs that file as application/octet-stream with whatever name your prefix resolves to. On success the temp file is deleted. On failure it's kept and its path is logged, which is genuinely useful - you can go look at exactly what the node tried to send rather than guessing.

Serializing is also a small safety upgrade. Safetensors is a length-prefixed JSON header plus raw tensor bytes, and nothing in it is executable - that's the entire reason it replaced pickle-based .ckpt files, where downloading a model was functionally downloading an executable. Re-writing a state dict through safetensors.torch.save_file means what lands on your server is that clean format, not a re-upload of whatever container your trainer happened to hand you.

The trade: what gets written is the tensor dict and nothing else. The node passes no metadata into the file, so a trainer's header extras - kohya's ss_ tags that model sites read to display training parameters - don't travel. If the receiving side only needs to load the thing, that's fine and invisible. If you're archiving training provenance, keep the original file too.

Connection handling is identical to the rest of the pack: GET the server root, accept anything under HTTP 400 (plus a 401 when credentials are off), compute a per-file timeout from size and measured round-trip, and raise if the file doesn't make it.

Inputs and outputs

lora (the LORA_MODEL type), filename_prefix (default lora), then address, port, use_credentials, username, password. No outputs - terminal node, it either uploads or errors.

The tooltip on lora is the author being blunt: "The LoRA model to upload. Do not use the model with LoRA layers." Take the raw LoRA handle, not a model that already has layers merged into it. A merged MODEL is a different socket type anyway, so the type check protects you from the obvious mistake; the one to avoid is grabbing the wrong output from a loader that offers both.

Tokens don't all work here, despite what the README's table implies. The source calls the filename helper for this node without a batch index, so %index% and %batch_num% stay literal in the filename, and %width%/%height% resolve to 0. Only the date and time tokens do anything. That's fine, because what you actually want on a single-file upload is versioning:

lora_%date:yyyy-MM-dd%_%hour%%minute%

The .safetensors extension is appended by the node, so don't type it into the prefix unless you enjoy lora.safetensors.safetensors.

Installing

Same pack, same install, whether you're here for one node or all four:

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

Restart ComfyUI, or install through Manager's Install via Git URL with that link. No model files to fetch. The dependency list is requests, tqdm, safetensors>=0.4.2, Pillow, numpy - all already present in a standard install. It's a V3-API pack, so it wants ComfyUI ≥ 0.12.3 and modern frontend.

Where people get burned

Repeated failures fill up _temp/. Every failed upload leaves its .safetensors behind by design - good for debugging, less good when your server's been down for a week and every queue press drops another file in ComfyUI/custom_nodes/comfyui-remoteserverupload/_temp/. Clean it out once you've found the problem.

A health check failure kills the run before the upload. If the probe can't get under 400 from the server root, you'll never see whether the LoRA path was fine. Test the root separately.

Credentials are saved in the workflow. use_credentials and username always are; the password only if "Save Password in Workflow" is on, and then as an encrypted blob that only decrypts on a machine sharing the same Workflow Password Encryption Secret. Handing a workflow to someone else is handing them a login unless you've dealt with that.

Your receiver has to accept multipart. The endpoint contract is a POST to /upload with a files field. A webhook expecting raw JSON bodies will not be delighted. For a smoke test, point address at 127.0.0.1 and port at any throwaway file-receive server that speaks multipart.