Superside FLUX.1 Pro Fill (dedicated inpaint)
FLUX.1 Pro Fill — the inpaint model that treats the mask as a condition, not an afterthought
- image
- mask
- image
- info
If you've done masked inpainting, you know the eternal complaint: the unmasked region comes back close but not identical. Most inpaint approaches are a masked img2img - image plus mask plus a strength number, with the result blended back in afterward. This node is the other school: FLUX.1 Pro Fill is architected for inpainting end-to-end, feeding the masked image and the mask to the model as explicit conditioning channels instead of blending things together after the fact. In practice that means the unmasked area comes back dramatically closer to pixel-identical. It's the API version of the open FLUX.1 Fill architecture, hosted on fal (fal-ai/flux-pro/v1/fill).
Inputs are image, mask (native MASK, white = regenerate), prompt, and api_key. The optional list is small because the model's philosophy is "fewer knobs": seed (-1 = random), num_images (1–4), output_format (png/jpeg), safety_tolerance (1–6, default 2, where 1 is most strict - the tooltip is explicit), and enhance_prompt (off by default, lets the model expand your prompt). Outputs are image (IMAGE) and info (STRING, result URL).
The trade-offs are the interesting part, and the README states them without flinching:
- No
strengthknob. Fill always fully regenerates the masked region - there's no denoise dial to soften the change. If you wanted the jacket a bit darker, this isn't your node; that's a masked img2img job. - No LoRA support on this base endpoint. There is a LoRA variant (
fal-ai/flux-lora/inpainting), but a LoRA trained on Z-Image or another family won't transfer - LoRAs aren't portable across model families, so you'd need one retrained against FLUX's own weights. If your workflow depends on a trained LoRA, the pack's Z-Image inpaint node is the one that takes them. - What you get instead is tighter preservation of everything outside the mask, which is precisely the failure mode people cite for whole-image edit models - "it changes every pixel."
Where this sits in the KB's inpainting map: it's the dedicated inpainting model category - fine-tuned on masked image pairs, understanding the mask as a condition, giving better edge blending than a generic checkpoint treating the mask as "generate here." The reason this matters in 2026 is that instruction-edit models (Kontext, Qwen-Edit) have eaten most of the inpainting job, but they drift: unmasked pixels come back similar-but-not-identical, and the drift compounds across a chain of edits. A real mask-based inpaint like this keeps everything else bit-identical, and the KB says that's the one thing edit models still can't do.
Two honest notes before you wire it up. First, it's a fal call - metered credits, your image leaves the machine, key goes in the api_key widget (blank falls back to FAL_KEY). Second, FLUX.1 Fill has open weights; if you have the VRAM and want this offline, the local path exists and is free per run. This node is for the "I don't want to install another model, just give me the inpaint" case.
Install - ComfyUI Manager (search "comfyui-superside-nodes") or:
cd ComfyUI/custom_nodes
git clone https://github.com/Superside/comfyui-superside-nodes
pip install -r requirements.txt
Restart ComfyUI, find it under Superside. No model files to download - the pack's only real dependency is fal-client.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| mask | MASK | — | |
| prompt | STRING | — | |
| api_key | STRING | — | |
| seedopt | INT | -1-1–2147483647 | -1 = random |
| num_imagesopt | INT | 11–4 | — |
| output_formatopt | COMBO | png | 2 options: png, jpeg |
| safety_toleranceopt | COMBO | 2 | 1 = most strict, 6 = most permissive. |
| enhance_promptopt | BOOLEAN | false | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| info | STRING | — |