Lmcq Auth Flux Encryption

This is LMCQ's model-encryption node scoped specifically to Flux - where the pack's general LmcqAuthModelEncryption handles a full checkpoint bundle, this one is built around Flux's split architecture, where the diffusion transformer (the "UNET" file) is typically loaded separately from CLIP and VAE rather than as one combined checkpoint. If you've fine-tuned a Flux model - a merge, a heavily-trained variant, a distilled custom build - and want to distribute access without giving away the raw weights, this is the encryption half; LmcqAuthFluxDecryption on the other end is what a buyer uses to load it back.

Why Flux specifically needed its own node. Flux Dev is a 12B-parameter model, and the community has spent since its August 2024 launch working out how to fit that on consumer hardware - fp8, GGUF, NF4, each trading size for quality differently. Because Flux weights typically ship and load as a standalone diffusion-model file rather than a full checkpoint, encrypting and decrypting it needed different handling than a bundled SD1.5/SDXL-style checkpoint. That's the gap this node - and its decryption counterpart - fills.

The fields. model_name is a dropdown of your local Flux model files - pick the one you're protecting. model_password is the key; whoever decrypts needs it exact. save_name (default encrypted_flux) names the output. machine_code is an optional multiline field for hardware-locking - leave it blank for password-only protection, or paste in codes from LmcqGetMachineCode (one per line) to restrict decryption to specific authorized machines. output_dir lets you point the encrypted file somewhere other than the default location - useful if you're staging files for distribution outside your models folder. This is a terminal node with no wired outputs; it writes the encrypted file and that's the entire job.

The cloud dependency worth knowing about. This node is part of LMCQ's "Auth" family, which the README ties to a hosted authentication server - creators register with an auth_key/auth_secret, and decryption on the recipient's side can involve real-time validation against that service rather than a purely offline check. If you'd rather keep everything local with no third-party account required, note that this specific Flux-encryption capability only exists in the Auth family in this pack - there's no Runtime-family equivalent for Flux models among the nodes covered here.

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, stated plainly. ComfyUI gives every installed node full, unsandboxed access to your system, and this pack's core protection code is deliberately shipped compiled and obfuscated - by the README's own description, specifically to resist inspection. For a node whose entire job is protecting someone's IP, that's the design intent, not a red flag by itself, but it does mean you're trusting closed logic from a small team rather than something you or anyone else can audit. Worth knowing going in, especially before building a paid distribution workflow around it.

Troubleshooting. The most common failure with this pack has nothing to do with Flux specifically: a compiled runtime module the Auth nodes rely on has gone missing on some installs, throwing a ModuleNotFoundError (runtime.model_protection or api_model_protection) at ComfyUI startup - and because that import failure sits in the pack's shared __init__.py, it takes down every Lmcq node at once, encryption-related or not. If this node isn't showing up in your search, check your console log for that error before anything else. The pack's January 2026 changelog has the fix: copy the Python-version-matching runtime files into the runtime folder, delete the mismatched ones, restart.