Diffusers Image Outpaint

This is the node that actually does the work - every other node in the pack exists to feed it. Plug in a model, a controlnet, your two prompts and a padded image, and it hands back a latent with the empty canvas filled in around your original picture.

Under the hood it's a straight port of fffiloni's diffusers-image-outpaint HuggingFace Space, rebuilt as ComfyUI nodes. That's an important detail, because it means this isn't running through ComfyUI's own sampler and model-management stack - it's driving a diffusers pipeline directly, SDXL-only, with the pipeline logic and configs hardcoded. That's also why the pack ships its own model/controlnet loaders instead of using ComfyUI's built-in ones: diffusers wants a different folder layout than ComfyUI's native .safetensors checkpoints.

If you're catching up on where outpainting stands in 2026: the honest take is that instruction-editing models (Qwen-Image-Edit, Flux Klein) have mostly taken over "extend this image," because you can just pad the canvas and tell the model what's behind the padding. What this node still gives you that those don't is a strength dial - controlnet_strength and guidance_scale are real numbers you can tune, not a yes/no instruction - and it stays on the SDXL stack, which matters if you're doing anything the big edit models won't touch.

The inputs you'll actually touch: guidance_scale defaults to a low 1.5 (range 1.01–10) - that's not an oversight, it's because the recommended model is an SDXL Lightning build, and distilled models want CFG left low; crank it toward 7-10 expecting more prompt adherence and you'll just cook the image. steps defaults to 8, again a Lightning-appropriate number (range 4-20). controlnet_strength (default 1, range 0-10) controls how hard the controlnet anchors the fill to the padded/masked image you feed in. sequential_cpu_offload is the VRAM-vs-speed toggle: on, it shuffles the unet and controlnet between CPU and GPU so only one is resident at a time - VRAM usage drops to roughly 6GB from ~8.3GB, but you're paying the PCIe tax to get there, and that tax is real (system RAM bandwidth is roughly an order of magnitude slower than VRAM). Leave device and dtype on auto unless you have a specific reason not to.

One thing the author flags directly and is worth knowing before you get confused: the steps count is real, but there's no reliable seed-locking behavior here the way you'd expect from a KSampler - whatever's floating in the UI just nudges the RNG toward a different result each run, it won't let you reproduce a specific outpaint deterministically.

Wiring: model and scheduler_configs come from Load Diffuser Model, control_net from Load Diffuser Controlnet, positive/negative from two Encode Diffusers Outpaint Prompt nodes, and diffuser_outpaint_cnet_image from Pad Image For Diffusers Outpaint's third output (not its IMAGE output - that one's just a preview). The single LATENT output goes straight into a normal ComfyUI VAE Decode - grab the VAE from a Checkpoint Loader Simple or a separate VAE Loader, same as any other SDXL workflow.

Installing the pack and its models: git clone it into custom_nodes (or search "ComfyUI-DiffusersImageOutpaint" in the Manager) and restart. If Manager didn't grab the Python deps, cd into the extension folder inside your ComfyUI venv and pip install -r requirements.txt. Then download an SDXL unet-only model - the author's tested example is RealVisXL_V5.0_Lightning - into models/diffusion_models, and an SDXL controlnet-union model (they use xinsir's promax variant) into models/controlnet.

Where people get stuck: newer transformers/diffusers versions throw a missing 'loaded_keys' error - the fix is pinning back with pip install transformers==4.45.0 --upgrade diffusers==0.32.2 --upgrade inside your ComfyUI environment (portable installs run the same command through python_embeded\python.exe -m pip). The author has only verified RealVisXL_V5.0_Lightning paired with the promax controlnet-union; they explicitly say mixing RealVisXL with the non-promax union threw errors for them, so don't assume any SDXL model/controlnet pair will work - start with the tested combo before you go hunting for alternatives. And don't bother looking for a Flux version: the author tried, gave up, and the node's configs are hardcoded to SDXL.