Load LoRA From URL

What it is

Normal ComfyUI LoRA loading assumes a file already sitting in your models/loras folder. That's fine on a desktop box you control, and a genuine pain everywhere else - a serverless runner, an API pipeline, a shared or headless box you don't have shell access to. Load LoRA From URL skips the "download it, then drag it into the folder, then restart" dance entirely: you give it a URL, it fetches the file and patches your model with it, in one node. The author's own framing is narrower than "grab any LoRA off the internet" - it's built for people hosting their own LoRAs on their own servers with public URLs, not as a CivitAI-link shortcut. It happens to work for any direct file link, but that's the use case it was written for.

If that sounds like a niche problem, it's the exact problem comf.icu-style platforms hand you: this site's own model policy is external URLs only, no direct upload. Anywhere generation runs on infrastructure you don't own, "point at a URL" beats "put a file somewhere."

How it works

It's a thin wrapper around a pattern you may already know: ComfyUI's core has a LoraLoaderModelOnly node that patches a MODEL with a local LoRA file and nothing else. This node does the same patching - merging the LoRA's low-rank weight deltas into the model at your chosen strength - except the file comes from a URL instead of a local filename. That's the entire value-add, and it's a good one.

One thing worth knowing before you wire this in: it only touches MODEL, not CLIP. Most LoRAs live almost entirely in the model's cross-attention layers, so this covers the vast majority of what a LoRA does. But some style and concept LoRAs also carry a small text-encoder shift, and a model-only loader can't apply that half. If a LoRA looks a bit weaker here than it did somewhere with a full model+clip loader, that's why.

Inputs and outputs

• url (string) - a direct link to the LoRA file, not a webpage. Since the pack is built around "your own server with a public URL," treat it the same way: it needs to resolve straight to the file bytes, no auth headers, no login wall, no share-page redirect.
• model - the MODEL coming out of your checkpoint loader, same as any other LoRA node.
• strength - 0 to 10, step 0.01, default 1. Don't be fooled by the wide range: 1.0 is "as trained," and in practice most people land somewhere around 0.5–0.8 because full strength is often stronger than you actually want. There's no negative option here (unlike some core loaders), so you can't invert a LoRA's effect - only dial it up or down.

Output is a single patched MODEL, which goes straight into your sampler chain like any other model output.

Installing it

Two paths, same as most custom nodes: search "ComfyUI_LoRA_from_URL" in ComfyUI Manager and install from there, or do it by hand -

cd ComfyUI/custom_nodes
git clone https://github.com/a-und-b/ComfyUI_LoRA_from_URL

then restart ComfyUI. It's a single, small node with no models or heavy dependencies bundled in - nothing to download up front, nothing to configure. That's genuinely rare in this ecosystem, where the median "install a node" experience is fighting a requirements.txt conflict with something else already in your environment.

Troubleshooting

The README here is about as minimal as they come, so keep expectations grounded - a few things follow directly from how the node is built rather than from documented bug reports:

• "It can't fetch the file." Almost always means the URL points at an HTML page (a CivitAI model page, a Google Drive viewer link) rather than the raw file. It needs a link that returns the .safetensors bytes directly when requested.
• Private or expiring links won't work. The whole design assumes a plain public URL. Signed S3 URLs that expire, or anything behind auth, are outside what this node is built to handle.
• "The LoRA doesn't apply on load." Check the node actually appeared after install - if ComfyUI Manager says it's installed but the node's missing from the menu, that's the standard "forgot to restart" gap, not something specific to this pack.
• Wrong base architecture. Same rule as every LoRA everywhere: it has to match the checkpoint it was trained against. A LoRA trained for one model family silently misbehaves or does nothing useful on another - that's not a bug in this node, it's how LoRAs work.
• Every run needs live network access to that URL at generation time. If your host is down, rate-limiting, or slow, that failure shows up mid-run. Worth keeping in mind if you're building an automated pipeline around this rather than clicking Queue by hand.