Load LoRA from URL (fal)

Standard LoraLoader reads a .safetensors out of your models/loras/ folder. Great locally, useless the moment the workflow runs on a machine that doesn't have your folder. This node is the same LoRA loader with one change that matters: instead of a filename dropdown, it takes a URL and downloads the LoRA at run time. Model in, model out, LoRA baked on - just fetched from the web rather than pulled off local disk.

It lives in the ComfyUI-fal-Connector, fal's tooling for running a ComfyUI graph on their serverless GPUs. Hit "Save as fal format," POST the workflow to fal.run/fal-ai/comfy-server, and the remote worker needs every asset by URL because it has no access to your drive. A LoRA is exactly that kind of asset. Feed the lora_url from a String Input node and callers of your workflow-as-API can swap the LoRA per request without you touching the graph.

What a LoRA is doing here, briefly

A LoRA is a small trained patch that nudges a base model toward a style, character, or concept - a few dozen megabytes that ride on top of a full checkpoint rather than replacing it. That's why this node sits between your model loader and your sampler: it takes the base MODEL and CLIP, applies the LoRA's weight deltas, and passes the modified pair downstream. Nothing about the remote version changes that math; it only changes where the file comes from.

The inputs that matter

• lora_url (required) - a direct link to the LoRA .safetensors. Default points at pixel-art-xl on Hugging Face; replace it with your own. Use the raw file URL (huggingface.co/<repo>/resolve/main/<file>.safetensors), not the model's landing page.
• model and clip (required) - the base model and CLIP you're patching, wired in from a checkpoint loader.
• strength_model (default 1.0) - how hard the LoRA hits the model weights. This is the dial you actually tune. Most LoRAs are trained to sit around 0.7–1.0; push past that and the effect fries, pull it down to blend subtly. The schema technically allows -20 to 20, which is absurd for real use - negative can invert a concept as a party trick, but you live in roughly 0 to 1.2.
• strength_clip (default 1.0) - the same idea applied to the text-encoder side. Common practice is to match strength_model or set it a touch lower; if a trigger word feels weak, this is the knob.

Outputs are MODEL and CLIP - the patched versions. Chain them straight into your sampler and CLIP Text Encode. Want to stack LoRAs? Feed this node's outputs into another RemoteLoraLoader and repeat.

Installing it

The connector ships with fal's bundle (per the README):

git clone --recursive https://github.com/badayvedat/ComfyUI-fal.git
cd ComfyUI-fal
pip install -r requirements.txt

Add your fal API key to fal-config.ini - and note the README's warning that the file belongs in ComfyUI-fal/custom_nodes/ComfyUI-fal-Connector/, not the repo root. The optional Hugging Face token in that same file matters here specifically: it's what lets the remote worker pull a LoRA from a gated HF repo. Start with main.py.

Only want the node locally? ComfyUI Manager → search ComfyUI-fal-Connector, or cd ComfyUI/custom_nodes && git clone https://github.com/badayvedat/ComfyUI-fal-Connector, then restart. The connector itself downloads no models - every LoRA is fetched from the URL you give it.

Where people get burned

The URL, first and always: it must resolve to the file bytes, not an HTML page, or the download fails before any LoRA applies. Gated or private Hugging Face repos return 401 unless the HF token is set in the config - this is the single most common "it works locally but 401s on fal" story. Architecture mismatch is the other trap: an SDXL LoRA on an SD1.5 base (or vice versa) either errors or produces garbage, and the node can't save you from pointing it at the wrong family. And if the LoRA "does nothing," check strength_model isn't near zero and that you actually wired both outputs downstream - patching the model but sampling from the original untouched one is a classic silent no-op.