SwarmUI: a .NET front end that generates ComfyUI graphs for you

The gap between ComfyUI's graph engine and a usable form

ComfyUI exposes the generation pipeline as a node graph. That is a good execution model and a poor first-run experience. SwarmUI's stated emphasis is making powertools easily accessible, and the README frames the split audience directly: beginners get the Generate tab, advanced users get the Comfy Workflow tab where the raw graph is exposed. The project supports image models (Krea 2, Stable Diffusion, Flux and others), video models (MiniMax H3, Wan, LTX-2) and some audio models such as ACE-Step. The README says new model families will be added as they are released publicly. So the target user is someone who wants current model coverage across modalities without writing node graphs for each one, and who is willing to run a local server rather than a hosted service. The README notes the project is in Almost-Release status, with the author describing it as recommended for most users while a few areas remain unfinished.

What actually runs when you press Generate

The repository is C# on the server side, with JavaScript on the front end, and Python underneath for the model execution layer. The topics list confirms the dependency: comfyui and python sit alongside csharp and javascript. The README describes an auto-workflow-generation feature in the Generate tab, which is the mechanism that matters. You fill in parameters, and SwarmUI constructs the graph rather than asking you to wire nodes. The Comfy Workflow tab is the escape hatch: the README calls it the unrestricted raw graph and notes that even advanced users return to the Generate tab for the image editor and for powertools such as the Grid Generator. That two-tab arrangement is the architecture in one sentence. The Generate tab is a parameter surface that emits a graph; the Comfy tab is the graph itself. Anything you can express in the graph you can still run, but the convenience features live one layer up. The README does not document the internal API between the C# server and the Python backend, so the exact call path is not something I can describe from the supplied material.

Installing it: two runtimes, two SDKs, one launch script

On Windows, the README points at the install-windows.bat file attached to the 0.9.8-Beta release. The instructions say to store it somewhere other than Program Files, run it, and note that it sometimes needs to be run twice before it proceeds, which the README itself flags as a TODO. The installer places a desktop icon for relaunching the server, then opens the install UI in the browser, where you follow on-page steps. The manual Windows path is explicit about the runtime: install git, install DotNET 8 SDK, and also install DotNET 10 SDK because the README says a future version will target .NET 10. Then clone the repository and run launch-windows.bat. On Linux the prerequisites are git and python3 with pip and venv, and the README gives distro-specific commands: sudo apt install git python3-pip python3-venv on some Ubuntu desktop versions, sudo apt install git python3-full on Debian or Ubuntu Server. Python 3.11 or 3.12 is the recommendation, 3.10 should work, 3.13 might work, and the README says plainly not to use 3.14 or later. The easy path downloads install-linux.sh from the 0.6.5-Beta release URL (the README notes the link is still current), makes it executable, and runs it. A manual Linux path exists, starting with git clone https://github.com/mcmonkeyprojects/SwarmUI and ./launchtools/linux-dotnet-install.sh.

Two ways to run it without owning a GPU

The README documents a Google Colab notebook at colab/colab-notebook.ipynb, with a warning attached: Colab does not necessarily allow remote WebUIs, particularly on free accounts. That warning is worth taking literally, because the failure mode is a working server you cannot reach, not a broken install. For rented GPUs there are two templates. Runpod's template is maintained by a third-party contributor, nerdylive123, which means its update cadence is not controlled by the SwarmUI maintainer. Vast.ai has a template as well, and the README warns that first startup may take several minutes, with setup progress visible in the container logs and usage hints in the template's question-mark info panel. If you are evaluating SwarmUI before installing anything locally, the Colab notebook is the lowest-commitment route, but the remote-WebUI restriction makes it unreliable as a permanent setup.

Where SwarmUI is the wrong choice

The version numbers tell their own story. The releases listed are 0.9.8-Beta, 0.9.7-Beta and 0.9.6-Beta, spaced roughly four to seven months apart, and the README repeats the beta label in its own first line. There has been no 1.0. If your deployment needs a versioned stability guarantee, this project does not currently offer one. The README also lists a feature target that is not implemented: LLM-assisted prompting, where it notes an extension exists but that LLM control should be native. If LLM-driven prompt generation is central to how you work, you are relying on an extension rather than the core. The Python constraint is a second hard boundary. The README states 3.14 or later should not be used, and recommends 3.11 or 3.12. On a machine where another tool has already pinned the system Python to 3.14, you are looking at a virtual environment or a container, not a straightforward install. Finally, if you have already invested in a library of hand-authored ComfyUI graphs, SwarmUI's value proposition inverts: the auto-generated workflow is the thing you would be working around, not the thing you came for.

How it differs from ComfyUI on its own and from Automatic1111-style UIs

The clearest comparison is against ComfyUI alone, because SwarmUI depends on it rather than replacing it. ComfyUI gives you the graph and nothing above it. SwarmUI keeps the graph reachable in the Comfy Workflow tab but adds a parameter layer that emits graphs, plus an image editor and a Grid Generator for systematic parameter sweeps. The difference is not the execution engine, which is shared, but who writes the graph. The second comparison is against the Automatic1111-style single-page UI pattern, where the form is the whole application and there is no graph underneath to inspect or extend. SwarmUI sits between those two positions: a form on top, a graph below, and a documented route from one to the other. The README's own framing supports this, describing the Generate tab as convenient for advanced users even when they prefer the raw graph. The cost of that middle position is the install: you are running a C# server and a Python stack together, with two .NET SDKs on Windows, where a pure Python UI would need only one runtime.

Licence, maintenance and what upgrading costs you

SwarmUI is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive arrangement and it does not impose copyleft obligations on your own code. I am not a lawyer and this is not legal advice; if you are redistributing SwarmUI inside a product, read the LICENSE file in the repository rather than this paragraph. On maintenance, the README is candid about its own rough edges. The Windows installer sometimes needs two runs, marked as a TODO in the documentation. A self-contained .msi or .exe installer is listed as a TODO as well. Desktop app mode is described as untested on Linux, with a probable dependency on WPE WebKit. Those are maintenance costs you absorb at install time rather than ongoing costs. The ongoing cost is the dual runtime: .NET 8 now with .NET 10 SDK installed in advance, and a Python version the README constrains to 3.11 or 3.12. Every upgrade has to keep both sides compatible, and the Runpod template is maintained by a third party, so its lag relative to a SwarmUI release is outside the maintainer's control.

Who should install it, and what to check first

Install SwarmUI if you want current model coverage across image, video and audio from one interface, you are comfortable running a local server, and you value the Grid Generator and image editor enough to accept a beta label. Skip it if you need release stability, if your pipeline is built on hand-authored ComfyUI graphs, or if your Python environment is pinned past 3.13. Before you commit, read docs/Basic Usage Guide, which the README points to as the next step after install, and check the Feature Announcements discussion thread to see how the LLM prompting gap is being handled. Then verify the one thing the README cannot tell you: whether your specific GPU and driver combination is handled by the backend options the install UI presents. That check is local and takes minutes, and it is the difference between a working Generate tab and a container log you keep reading.

Editorial conclusion

Adopt SwarmUI if you want ComfyUI's execution engine with a form-driven Generate tab and a Grid Generator for batch sweeps, and you can live with .NET 8 plus Python 3.11 or 3.12 on the same machine. Do not adopt it if you need a stable release contract, if your workflow depends on hand-tuned ComfyUI graphs you would have to keep re-exporting, or if your Python is already pinned to 3.14 or later. Before committing, open the docs folder and read the Basic Usage Guide end to end, confirm your GPU backend appears in the install UI's options, and check the Feature Announcements discussion thread for the LLM prompting gap the README still lists as unimplemented.

Official sources

1. Issues
2. License: MIT
3. mcmonkeyprojects/SwarmUI on GitHub
4. README
5. Releases