XLDB LoRA
XLDB LoRA — the loader that knows what a DreamBooth-trained kohya LoRA looks like
- model
- clip
- MODEL
- CLIP
"XLDB" is "XL DreamBooth," and that tells you the whole story: this is a LoRA loader built for one workflow - train a DreamBooth LoRA with kohya, then load the exact artifact it produced. ComfyUI already ships a perfectly good LoraLoader, so this node has to earn its place. It does, in two small ways: it knows how to find a kohya pytorch_lora_weights.bin inside a training checkpoint folder, and it caches the loaded weights per node so re-runs skip the disk read.
It's the local half of komojini's ComfyUI_SDXL_DreamBooth_LoRA_CustomNodes pack, paired with its S3-flavored sibling. The repo is a hobby-scale single commit and the README is just the title, so treat the source as the docs - which is fine, because the node is small enough to read end to end.
How it works
The lora_name dropdown lists everything in ComfyUI/models/loras, plus a None entry that passes model and clip straight through untouched - handy for A/B-testing a LoRA against no LoRA without rewiring the graph.
The interesting branch is in the loading. If the selected path contains the string checkpoint, it steps up to the parent directory and loads pytorch_lora_weights.bin - the weight file kohya's sd-scripts writes for a trained LoRA. Otherwise it loads the file the normal way. Either way, the weights get fed through ComfyUI's standard load_lora_for_models, and the same weights are cached on the node instance, so queuing the same workflow again doesn't re-read the file.
The inputs and outputs
Just the essentials: model (MODEL), clip (CLIP), and lora_name (the dropdown). Outputs are MODEL and CLIP, wired like any loader - MODEL into the sampler, CLIP into conditioning. And here's the honest catch: that's all there is. There is no strength input - it's hardcoded to 1.0. If you want to blend at 0.6, stack three LoRAs, or toggle weights, ComfyUI's built-in LoraLoader does all of that and is what the community actually reaches for. XLDB's niche is a DreamBooth test harness: train, let kohya write its pytorch_lora_weights.bin into a checkpoint folder, drop this node in, and you're testing the exact artifact you trained.
Install
Shared with its sibling - ComfyUI Manager, search ComfyUI_SDXL_DreamBooth_LoRA_CustomNodes, or:
cd ComfyUI/custom_nodes
git clone https://github.com/komojini/ComfyUI_SDXL_DreamBooth_LoRA_CustomNodes
pip install -r requirements.txt # boto3, gdown, python-dotenv
Restart ComfyUI. No models to download; the LoRAs it loads are yours.
Where people get burned
- The
checkpointmatch is a substring test on the path, and that bites. Name a regular.safetensorsfilemy-checkpoint-style.safetensorsand the node will assume it's a DreamBooth folder, go looking forpytorch_lora_weights.binnext to it, not find one, and error out. Keep the word "checkpoint" out of your ordinary LoRA filenames. - Fixed strength surprises people. You expect a weight slider like every other loader; there isn't one. Reaching for a strength control and not finding it is the number one "wait, why?" moment.
- The cache can serve stale weights. The node holds loaded weights per instance, so if you overwrite the file on disk mid-session, an existing instance may keep the old weights until you reload the workflow or restart.
Verdict: if you train with kohya and your LoRAs come out of checkpoint-500 folders, this is a decent shortcut. If you mostly download finished LoRAs and blend them, the built-in loader - or rgthree's Power Lora Loader for stacking - does more. Know what you're installing and this one node is fine; expect a general-purpose loader and you'll be mildly annoyed.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora_name | COMBO | 1 options: None |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |