Legion: Configuration

The Legion: Configuration node doesn't do any image work itself. It's the control panel for the whole LegionPower idea: this is where you tell the pack how to spawn a second, separate ComfyUI instance - a "worker" - and which workflow that worker should run. Everything else in the pack hangs off the legion_config output this node produces.

LegionPower is a young, niche orchestration pack (v0.1.1, still an MVP). The pitch: run a workflow in a separate ComfyUI process so it doesn't trash your main instance's VRAM or block your graph. The config node is the foundation - no config, no worker, no point to any of this.

How it works

On the outside it's gloriously simple: one big YAML text field in, one typed object out. The YAML gets parsed and wrapped in a LegionConfig object, which flows into a Legion: Master node (or Warmupper) as the legion_config input. That object is read fresh on every run, so you can fork two Masters off one config - one worker each on different ports - or reuse it across a whole graph.

The node ships pre-filled with the default template (loaded from default_legion_config.yaml at install), and the template currently defaults to dry_run: false. In other words, it will really execute. If you're just exploring the plumbing, flip execution.dry_run to true first so it simulates the data exchange without launching a worker.

The fields that actually matter

You can safely ignore most of the template. These are the ones beginners hit:

• workflow: - the filename (e.g. my_worker.json) of the worker workflow to run. It must live in ComfyUI/user/default/ComfyUI-LegionPower/workflows/. The default points at plain_face_restore_api.json, which won't exist on your machine until you drop a file there - that's the first thing that bites.
• comfyui.port: - auto (default) assigns a free port starting at 8200; a fixed number targets a specific, possibly externally-running instance.
• execution.asynch: - false (default) makes Master block until the worker finishes and hand back real results. true returns immediately and you collect results later with Legion: Join.
• execution.extra_args: - extra CLI flags for the worker, e.g. --lowvram --preview-method auto.
• execution.env_vars: - environment for the worker. CUDA_VISIBLE_DEVICES: "1" pins it to GPU 1; PYTORCH_CUDA_ALLOC_CONF: "max_split_size_mb:512" reins in fragmentation.
• comfyui.paths: - leave comfyui_path and python_executable empty to auto-detect; that's the right call for most people.

The output is a single legion_config of type LEGION_CONFIG, which wires into any Legion: Master or Legion: Warmupper's legion_config input.

Installing

Via ComfyUI Manager, search "LegionPower" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Transhumai/ComfyUI-LegionPower.git
cd ComfyUI-LegionPower
pip install -r requirements.txt

Restart ComfyUI after that. The whole dependency story is requests - no models to download, no torch version fights. The heavy lifting is done by the copy of ComfyUI it spawns, which is your existing install.

Troubleshooting

• Invalid YAML = dead node. If the YAML doesn't parse, the node returns None and the workflow stops. Indentation mistakes in the template are the classic culprit; check the console for [LegionPower] ERROR: Invalid YAML configuration.
• Workflow not found - the workflow: filename isn't in any configured workflows root. Put the file in user/default/ComfyUI-LegionPower/workflows/.
• Worker won't start - the config names a fixed port that's already taken, or auto-detection picked the wrong Python/ComfyUI. Watch the console; the Master prints the exact command it's launching, so you can run it by hand.

One honest caveat: this pack is new and barely has a community footprint, so you're partly a beta tester. The config node is the most solid piece - but dry-run everything before you commit real workloads to it.