Fal API Flux Dev with LoRA Inpaint
ComfyUI Node Guide
- image
- mask_image
- lora_1
- lora_2
- lora_3
- lora_4
- lora_5
- IMAGE
This node is the img2img LoRA node with one more input added: mask_image. Instead of regenerating the whole picture toward your prompt, it only touches the region the mask marks, which makes it the pick for fixing a specific part of an image - swap a background, redo a face, remove an object - while a trained LoRA still shapes how the regenerated area looks.
The inpainting-specific inputs are image (the source, required), mask_image (required), and strength (0–1, default 0.8), which behaves inside the masked region the same way it does in plain img2img: higher lets the model diverge more from what was there, lower keeps it closer to the original content. On mask polarity, the schema itself doesn't document which color means "regenerate this" - most ComfyUI inpaint workflows use white for the area to fill and black for the area to protect, and that's the sane first guess here too, but if your first test comes back inverted from what you expected, just flip the mask rather than assuming something's broken.
Generation controls are the same set as every Dev-with-LoRA node: prompt (write it as a sentence - Flux's T5 encoder wants natural language, not tags), width/height (1024 default, step 8, this sets fal's output canvas), num_inference_steps (28 default, 1–100), guidance_scale (3.5 default, 0.1–40), num_images (1–4), enable_safety_checker, and optional seed. LoRAs go through lora_1–lora_5, each fed by a "Fal API Flux LoRA Config" node's LORA_CONFIG output - none required, stack as many as five.
Output is IMAGE.
Installing it. Standard for the pack: ComfyUI Manager search "ComfyUI-Fal-API-Flux," or a manual clone of the real repo (https://github.com/yhayano-ponotech/ComfyUI-Fal-API-Flux.git - the README's own example command has a placeholder username baked in, so don't copy it verbatim) plus pip install -r requirements.txt. Then, without exception, a config.ini next to the node's code with a [falai] section holding your fal.ai api_key. Nothing runs without it, and there's no in-UI place to enter it instead.
Where inpainting jobs specifically go wrong. If the result edits far outside your mask boundary, you're either sending the wrong mask or strength is high enough that the model is taking real liberties even inside the marked region - pull it down toward 0.5–0.6 for tighter edits. If the edit looks pasted-in with a visible seam, that's a fal-side compositing limit rather than something you can dial away from here; since this call goes straight to fal's hosted endpoint and comes back as one finished image, you don't get the local VAE-encode/decode control that native ComfyUI inpaint workflows expose, so if seams bother you, compositing the returned region back over your original outside ComfyUI is the more reliable fix than chasing settings. And the same LoRA caveat as everywhere else: lora_url must resolve to a raw, publicly downloadable .safetensors file, not a CivitAI page link.
Inputs (16)
| Name | Type | Default | Description |
|---|---|---|---|
| prompt | STRING | — | |
| width | INT | 1024 | — |
| height | INT | 1024 | — |
| num_inference_steps | INT | 281–100 | — |
| guidance_scale | FLOAT | 3.500.1–40 | — |
| num_images | INT | 11–4 | — |
| enable_safety_checker | BOOLEAN | true | — |
| image | IMAGE | — | |
| strength | FLOAT | 0.800–1 | — |
| mask_image | IMAGE | — | |
| seedopt | INT | 00–18446744073709550000 | — |
| lora_1opt | LORA_CONFIG | — | |
| lora_2opt | LORA_CONFIG | — | |
| lora_3opt | LORA_CONFIG | — | |
| lora_4opt | LORA_CONFIG | — | |
| lora_5opt | LORA_CONFIG | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |