BASE CONFIG — the central control panel of a professional graph
A large ComfyUI workflow becomes manageable only when its major processing systems can be enabled, bypassed and tested from one place. BASE CONFIG is the graph’s control plane: it defines which modules participate in the current runtime profile.
BASE CONFIG answers the question: “what runs at all?”
In a large production graph, changing CFG, denoise or steps is not enough. First you must decide which major systems participate in the current run: loaders, inputs, preprocessors, masks, PEOPLE, SDXL, FLUX, upscale and output.
BASE CONFIG centralizes that decision. It does not replace per-node parameters; it sits one architectural level above them and controls the state of the workflow.
Which Hansen processing groups are controlled centrally
| Group toggle | Purpose |
|---|---|
| MODEL LOADERS | Load checkpoints, UNet, CLIP, VAE and other models |
| INPUTS | Base image, references, maps and other input data |
| CONTROL | Shared controls / selectors / global parameters |
| SAMPLER CONFIGURATION | Seed, steps, sampler, scheduler and related settings |
| ControlNet Preprocessors + Extras | Depth, edge and supporting preprocessing |
| MASKS | Architectural and local masks |
| PPL FLUX Generate | Separate people generation |
| PPL SEGMENTATION | People detection / segmentation |
| PPL FLUX Composite | People preparation and compositing |
| PPL 3D INPAINT Detail | Alternative branch for people already placed in the scene |
| Process SEGMENTATION | General segmentation processing |
| Process SDXL | Main SDXL stage |
| Process FLUX | Main FLUX refinement |
| Process UPSCALE | Upscale / HQ processing |
| Process ADD LOGO | Overlay / logo post-process |
| OUTPUT | Preview / save / delivery stage |
Bypassed, selected away and disabled are not the same state
In a large graph, distinguish physical connectivity, result selection and actual processing. Otherwise a connected branch can easily be mistaken for a branch that contributes to the current output.
| State | What happens | How to interpret it |
|---|---|---|
| ACTIVE | The group executes and its output is required downstream | Participates in runtime |
| BYPASSED | Processing remains in the graph but is skipped | Architecture exists; computation is off |
| SELECTED AWAY | The branch may be active, but a selector chooses another source | Does not affect the current result |
| DIAGNOSTIC ONLY | The result goes to a preview/comparer rather than production output | Used for observation |
Centralized bypass turns groups into controllable modules
The purpose of Fast Groups Bypasser is to avoid running around the canvas disabling dozens of nodes manually. Named groups are controlled from a single panel, which makes group names part of the workflow’s architectural API.
This leads to an important rule: group names must be stable and unambiguous. When the control plane addresses groups by name, ad-hoc renaming reduces readability and can break control behavior.
Hansen pattern
In the video, BASE CONFIG is used as a single enable/bypass panel for major workflow groups.
Engineering rule
Treat a group name as part of the module interface: concise, stable, and descriptive of function rather than editing history.
Group names should describe responsibility, not author or version history
| Weak | Better |
|---|---|
| group 1 | INPUTS |
| test2 | CONTROLNET · DEPTH |
| new final | PROCESS · FLUX |
| people stuff | PPL · SEGMENTATION |
| final final | OUTPUT |
Groups should be enabled by dependency chain, not at random
Modules have dependencies. PROCESS FLUX is meaningless to test when its input has not been produced by the previous stage. PPL Composite cannot work without a prepared person and placement data. BASE CONFIG should therefore be read as a dependency map, not a list of independent switches.
A professional BASE CONFIG should support minimal test profiles
Debugging does not require the entire Master Workflow to run. The fewer systems that are active, the easier it is to isolate the source of an error — and the lower the VRAM and time cost.
Debug principle
Enable the smallest route that can reproduce the problem; restore downstream modules only after the issue is resolved.
| Preset | Keep active | Purpose |
|---|---|---|
| TEST INPUT ONLY | Loaders + Inputs + Preview | Verify files, dimensions and canvas |
| TEST PREPROCESS | Inputs + required preprocessor + Preview | Verify depth / edge / map before generation |
| TEST MASKS ONLY | Inputs + segmentation/masks + Preview | Verify polarity, bounds and coordinate space |
| TEST PPL ONLY | PPL Generate + Segment + Composite + local previews | Isolate the PEOPLE module |
| TEST SDXL ONLY | Loaders + Inputs + SDXL + checkpoint preview | Verify base generation |
| TEST FLUX ONLY | Prepared input + FLUX + preview | Verify final refinement |
| FINAL FULL RUN | All approved production modules | Final integration run |
BASE CONFIG also controls the cost of a run
Disabling a heavy branch is not only about visual cleanliness. It avoids loading unnecessary models, keeping unused preprocessors in memory, and executing downstream work that is not part of the current test.
This is especially important on GPUs with limited VRAM: architectural control of the graph becomes part of performance engineering.
Practice: design BASE CONFIG before adding generative nodes
Create an empty training canvas and draw only these groups first: MODEL LOADERS, INPUTS, CONTROL, PREPROCESS, MASKS, PROCESS A, PROCESS B, OUTPUT. Then write down which groups must be active for three modes: Input Test, Module Test and Full Run.
No AI model is required for this exercise. The goal is to learn to design the control plane before the graph becomes large.