FLUX Virtual Try-On

Take a photo of a person, a photo of a garment, and this node produces a shot of that person wearing that garment - seams, folds, and all. It's Black Forest Labs' FLUX Virtual Try-On model (bfl:flux@vto), hosted on Runware, and it's one of the most immediately comprehensible things in the whole pack. You don't need to understand diffusion to know what "put this jacket on this person" should look like.

This is the classic use case for fashion e-commerce, but it's also just a fun node to reach for when you want to test an outfit idea on a consistent subject. And because it runs in the cloud, there's no VRAM barrier, no 12GB FLUX download, no LoRA hunting for the "right" try-on model. Install the Runware pack (ComfyUI Manager → Runware, or clone into custom_nodes/), add an API key, and it's a two-builder workflow away.

How it works - the Reference Images builder is the whole game

Here's the part that trips up everyone on first contact: this node doesn't take IMAGE sockets directly for the person and garment. It takes a single referenceImages socket (RUNWARE_REFERENCEIMAGES), and you build what goes into it with the Runware Reference Images builder. That builder has a role dropdown with exactly three values:

• person - exactly one. The subject wearing the clothes.
• garment - one to eleven. The clothing items to try on.
• pose - optional, one. A pose reference if you want control over the stance.

Each reference also needs a tag that starts with @ (e.g. @person1, @shirt) so the prompt can mention it, and the builder's type is instruct. This role/tag structure is how the model knows which input is the body and which is the jacket - skip the tags and the model has nothing to hang your prompt mentions on.

The rest of the inputs

• positivePrompt - describes the final shot and references the tagged inputs, e.g. "the person wearing the jacket, studio lighting, full body."
• steps - here's the notable one: default 4, max 4. Virtual try-on is a distilled, fixed-step pipeline; you don't tune this, and the locked ceiling is a hint that "more steps = better" does not apply.
• seed - pin it when a layout works.
• numberResults (1–20) - batch out candidates; try-on is where a few variations earn their keep.
• safety toggle + the standard outputFormat/outputQuality set.

Output is a single image (IMAGE) into Preview or Save, with per-run cost on the title bar.

Where it goes wrong

• Missing or malformed roles - one person and at least one garment, or the request is rejected. The builder drops incomplete features silently, so a missing role often manifests as "nothing happened," not an error.
• Tags that don't match the prompt - @shirt in the builder and "the shirt" in the prompt is a mismatch; the prompt has to mention the tag for the reference to bind.
• Wrong count - more than one person role is invalid. The tooltip says it: exactly one person, one to eleven garments.
• Expecting a full fashion shoot - try-on renders the garment on the person; it doesn't invent fabric texture the garment photo didn't capture. Flat-lay garment shots with even lighting work dramatically better than wrinkled or folded ones.

This is the rare model where the API wrapper is almost transparent - the hard part is feeding it the right structure, and the builder makes that structure explicit. Once the role/tag habit clicks, it's genuinely hard to go back to the manual inpainting workflows people used to cobble together for this.