Flux Virtual Try-On v2 (BFL)

Clothing swap is one of those tasks where local models have always been fiddly - you fight with garment regions, face preservation, and inpainting seams. FluxVirtualTryOnV2_BFL sidesteps most of that by handing the whole job to Black Forest Labs' hosted flux-tools/vto-v2 endpoint: you give it a photo of a person, a photo of a garment, and it returns the person wearing the garment. The v2 model, which BFL shipped in July 2026, specifically targets the two things people hated about v1 - sharper face preservation and better garment detail - and it accepts inputs up to 4 megapixels.

This is a cloud call, not a local pipeline. Your images go up to api.bfl.ai, and you pay BFL for the try-on. Given that the alternative is assembling an IDM-VTON or IC-Light-style local workflow, renting the API is a very reasonable trade for most people. Just remember what you're buying: BFL's moderation runs on everything that enters or leaves, so the pipeline is strictly censored.

How it works

Under the hood it's the pack's standard recipe: POST to /v1/flux-tools/vto-v2 with your arguments, then poll get_result every five seconds until the job lands on Ready, then download the result and hand it back as a ComfyUI IMAGE tensor. The node is implemented as a subclass of the v1 node that only swaps the endpoint path - the request format is identical, so v1 workflows swap straight across.

The two inputs that matter are person and garment, and here's the catch: both must be base64-encoded strings, not IMAGE tensors. So the workflow is: LoadImage → Image to Base64 (BFL) (set image_format to png if you care about lossless) → wire those STRING outputs into the try-on node. That's a step beginners miss, and the node gives you no error for it beyond a failed request.

The rest of the inputs

• prompt - defaults to "TRY-ON: The person of image 1 wearing garments of image 2." The tooltip says it plainly: describe the garment and how it's worn while preserving the person's face and pose. Editing this genuinely changes results.
• safety_tolerance (0–5, default 2) - 0 is most strict, 5 least. You'll hit this when moderation rejects a legitimate fashion shot.
• output_format - jpeg or png.
• seed - set a value for reproducible results; -1 means random.
• webhook_url / webhook_secret - optional async notifications; skip unless you're automating.
• config (optional) - per-node key/base URL/region override.

The single output is IMAGE, ready for the usual save/preview nodes.

Installing it

One install covers the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/gelasdev/ComfyUI-FLUX-BFL-API.git
cd ComfyUI-FLUX-BFL-API
pip install -r requirements.txt

Or via ComfyUI Manager, searching "ComfyUI-FLUX-BFL-API". Dependencies are just torch - no model downloads, nothing heavy. You do need a BFL API key in the pack's config.ini or a Flux Config (BFL) node wired into the config socket (the node route survives updates, which keeps wiping config.ini).

Where people get burned

The base64 requirement tops the list - the person and garment sockets are strings, so a bare IMAGE wire does nothing. Beyond that, treat the moderation as real: if the request returns Content Moderated, it's not a bug, it's BFL's policy. And keep inputs reasonable - v2 accepts up to 4MP, but bigger images mean slower requests and bigger bills, and the API-side resize will eat excess resolution anyway. Start small, verify the face holds, then scale up.