LoraLoaderFromFolder

ComfyUI's built-in LoRA loader only sees files inside models/loras - the folder baked into your install. LoraLoaderFromFolder is the workaround for anyone whose LoRA collection lives somewhere else: an external drive, a shared folder between multiple SD tools, a training output directory you don't want to duplicate into ComfyUI's own tree. Same job as the stock loader, different source.

How it works

You point lora_folder at any directory, and lora_name becomes a dropdown populated from whatever's actually in that folder - same live-scan pattern ComfyUI uses for its own model folders, just aimed somewhere you chose. From there it behaves like the standard loader: it patches model with the LoRA's weight deltas at strength_model, and - if you give it a clip_opt - patches that CLIP too, at strength_clip. Skip clip_opt and you get back a model-only patch; nothing forces you to touch the text encoder if the LoRA you're using doesn't need it (or if you're patching CLIP through some other node instead).

This solves a different problem than rgthree's Power Lora Loader, which is the other LoRA-loading node people reach for constantly - that one stacks several LoRAs on one node with per-entry toggles and trigger-word lookups, but it still reads from ComfyUI's own models/loras folder. LoraLoaderFromFolder doesn't stack anything; it loads one LoRA, same as the stock node, but from anywhere on disk. Different axis, not a competing feature.

Inputs and outputs

• model - the checkpoint you're patching.
• lora_folder - the folder to scan. Absolute path, not relative to ComfyUI's own tree.
• lora_name - a dropdown populated from that folder's contents.
• strength_model (default 1, range −20 to 20) - how strongly the LoRA patches the U-Net. Negative values subtract the LoRA's effect instead of adding it.
• strength_clip (default 1, same range) - same idea, for the text encoder. Only matters if clip_opt is connected.
• clip_opt (optional) - wire this in if you also want the LoRA applied to CLIP.

Outputs: MODEL and CLIP, same as any standard LoRA loader - wire them onward exactly the way you would the built-in node's outputs.

Installing SP-Nodes

Via Manager: search "SP-Nodes," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Restart once cloned. No model download for the node itself - you supply the LoRA files; it just needs read access to wherever they live.

Common issues

The dropdown-doesn't-update problem is the one worth knowing up front: lora_name is populated by scanning lora_folder when the graph loads, so if you drop new LoRA files into that folder while ComfyUI is already running, they won't show up until you refresh or restart - a standard ComfyUI folder-scan gotcha, not unique to this node, but easy to blame on the node when it happens.

Beyond that, architecture mismatch is the real trap: a LoRA trained for one base model doesn't transfer to another - a Flux LoRA won't do anything sensible loaded against an SDXL checkpoint, and vice versa. This node doesn't validate that for you; it'll happily patch a model with an incompatible LoRA and let you find out from broken output. If results look wrong after loading, check the LoRA's intended base model before assuming the strength values are off. And if you point lora_folder at a path that doesn't exist or that ComfyUI's process can't read, expect an empty dropdown rather than a clear error - worth checking the path first if lora_name shows nothing to pick from.