Lmcq Auth LoRA Encryption

Same idea as the pack's model encryption node, scoped to LoRAs: this locks a .safetensors LoRA file behind a password (and optionally specific hardware) so you can distribute it without handing over a copy anyone can immediately re-share. It's the encryption half of a pair - LmcqAuthLoraDecryption on the other end is what a recipient uses to actually load it.

Who reaches for this. If you train character or style LoRAs and sell access to them - Patreon tier, Discord shop, whatever the distribution channel - plain safetensors files are trivially copyable the moment one paying customer shares them. This node is LMCQ's answer: encrypt the file, and only someone with the password (and the right node from this same pack) can turn it back into something ComfyUI can load. If you're just training and using your own LoRAs locally, this node has nothing for you - skip it.

The fields. lora_name is a dropdown of the LoRA files sitting in your models/loras folder - pick the one you're protecting. key is the password; whoever decrypts it needs to enter this exactly. save_name (default encrypted_lora) names the resulting file. machine_codes is a multiline field for optionally binding the encryption to specific hardware - leave it empty for password-only protection, or paste in one machine code per line (gathered from each authorized buyer via LmcqGetMachineCode) to also require the file only ever open on those specific machines. This node is a terminal output node - no wired outputs, it just writes the encrypted file to disk.

How this connects to the rest of the Auth family. This is part of LMCQ's cloud-backed "Authentication Server" system, distinct from the pack's simpler "Runtime" protection family (LmcqRuntimeLoraEncryption). Per the README, the Auth system ties into a hosted platform where creators register with an auth_key/auth_secret and get real-time validation, usage limits, and revocation on the decryption side - meaningfully more capable than a static password check, but it also means the recipient's decryption may depend on network access to LMCQ's servers rather than being fully offline. If you want a purely local, no-account setup, the Runtime family is the simpler option; if you're managing many buyers and want to be able to revoke or adjust access after the fact, Auth is the one built for that.

Installing it. Through ComfyUI Manager (search "ComfyUI-LMCQ") or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/sebord/ComfyUI-LMCQ

Restart ComfyUI afterward.

The trust question worth asking before you use this. Custom nodes in ComfyUI run with full, unsandboxed access to your machine, and this pack's own documentation describes its core protection logic as deliberately compiled into a binary format specifically to resist reverse-engineering - which is the point for a node whose job is protecting someone's IP, but it also means you can't read the code doing the encrypting. That's a bigger ask than the average custom node, where at least the Python is inspectable. Nothing in this pack's reported history suggests misuse, but it's worth being deliberate about where you run it.

Troubleshooting. The recurring, reported issue with this pack: a compiled runtime module the Auth nodes depend on has gone missing on some installs, throwing a ModuleNotFoundError referencing runtime.model_protection (or api_model_protection) at startup - and because that failure happens inside the pack's shared __init__.py, it takes the entire pack down, not just the encryption nodes. If none of the Lmcq nodes show up in your search, that's almost certainly why. The pack's January 2026 changelog documents the fix: copy the runtime files matching your Python version into the runtime folder, remove the mismatched ones, and restart.