# ComfyUI: the offline claim needs a flag, three UI packages are pinned exactly, and the badges point at another repository path

> A node graph engine for diffusion models, licensed GPL-3.0, with a weekly release rhythm and a dependency file that pins the interface but floats the inference stack. Most of what a user needs is in requirements.txt and pyproject.toml, not in the readme.

**Comfy-Org/ComfyUI** — The most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.

- Repository: https://github.com/Comfy-Org/ComfyUI
- Website: https://www.comfy.org/
- Stars: 134,951 · Forks: 15,987
- Language: Python
- License: GPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/comfy-org-comfyui

## The badges and the manifest both name a different repository path

The release badge, the release date badge, and both download counters are built against github.com/comfyanonymous/ComfyUI. The project metadata agrees: the repository URL in pyproject.toml is that path, and the release process section links its first repository, ComfyUI Core, to the same place. The repository this page is about sits under a different owner name, and the readme does not explain the difference. Consequence for the reader: a badge is a URL that people paste into issues, forks, and dependency notes, so following one lands on a path that is not the one you cloned, and anything you derive from those links points at the older name. The homepage in the manifest is not the repository at all but the vendor site, so the manifest alone will not tell you which tree a package came from.

## The offline promise holds only once you pass one flag

The features section makes a strong claim and then gives it a switch. It says ComfyUI runs fully offline and that the core does not download anything unless you request it, and it names the flag that disables the optional paid Comfy API nodes and forces all built-in functionality to stay offline.

```
--disable-api-nodes
```

There is a directory in the tree named for those API nodes, and partner nodes are offered for closed source models, so the networked path exists in the product by design. Consequence for the reader: the default install is not the offline install, and the readme does not say where in the interface the flag can be turned on, so somebody who needs a hard offline guarantee has to launch with it. The sentence also covers the core only, and a tree that carries a custom nodes directory is a tree where an extension can reach the network on its own.

## Three packages are pinned exactly and the inference stack is not pinned at all

requirements.txt opens with three exact pins: the frontend package at 1.53.6, the workflow templates at 0.11.70, and the embedded documentation at 0.5.13. Two more packages are pinned the same way further down. Everything else is either a floor or bare: torch, torchsde, and torchvision have no version at all, numpy asks for 1.25.0 or newer, transformers asks for 4.50.3 or newer, aiohttp asks for 3.11.8 or newer, and av asks for 17.0.0 or newer. Consequence for the reader: the interface, the templates you start from, and the docs bundled with the app are frozen until a human edits the file, while the numerical stack floats with whatever your index serves. Two machines on the same commit can therefore show the same interface and behave differently underneath it, which makes a bug report without a lock file hard to reproduce.

## A block of non essential dependencies decides which nodes exist for you

After the main list, requirements.txt marks a second group as non essential: kornia, spandrel, pydantic, pydantic-settings, PyOpenGL, and comfy-angle. Nothing in the readme ties a feature to any of them. Consequence for the reader: a minimal install that skips the block does not fail loudly, it just lacks things, so the first sign of trouble is a node that will not run and a traceback pointing at an import rather than at your workflow. The grouping is the only statement of what is optional in the whole dependency file, and it is a comment above a list rather than a per-feature note, so anyone building a container image has to guess which of the six their use needs.

## Ruff is set to catch eval and exec, while pylint has a long list switched off

The lint configuration is asymmetric on purpose. Ruff selects a naming rule, two rules about dynamic evaluation, one about print usage, the pycodestyle error and warning sets, and the pyflakes set, while ignoring line length, bare except, lambda assignment, comparison style, and import placement. Pylint is pinned to a Python 3.10 target, allows the pydantic extension package, prints colourised reports, ignores imports when comparing similarity, and then disables a long list: missing docstrings of all three kinds, line too long, broad exception raising and catching, unused arguments, dangerous default values, duplicate code, too many arguments, too many lines, and invalid names. The list ends with a comment saying the next warnings should be fixed in the future.

Consequence for the reader: a green run tells you the project does not evaluate strings and follows a style, and tells you nothing about structure, because the checks that would complain about sprawling modules and swallowed exceptions are switched off in configuration rather than satisfied in code.

## The release rhythm is weekly, and the version numbers move faster than the docs

The release section describes a weekly cycle targeting Monday and admits that this changes regularly because of model releases or large changes to the codebase. It names three interconnected repositories and says the core publishes a new major stable version roughly every two weeks. The listed releases match that pace, with v0.38.0 dated 2026-09-29, v0.37.0 on 2026-09-21, and v0.36.0 on 2026-09-15, and the version field in pyproject.toml reads the same 0.38.0, so the manifest and the tag agree. Consequence for the reader: a minor version is weeks old at most, and the readme documents no upgrade path between versions, with the root carrying no upgrade notes file and the guidance pushed to the documentation site. A team that pins a ComfyUI version is pinning to something that will be superseded on a schedule set by model releases rather than by you.

## A database, a linted API spec, and a guard file with a hash in its name

The root of the tree tells you more about the architecture than the feature list does. There is a database layer with an alembic configuration and a migrations directory, an OpenAPI specification file with a Spectral configuration beside it, and separate directories for the api server, middleware, execution, extras, configuration, and blueprints, plus two test directories and a pytest configuration. There is a requirements file for the extension manager, an example file for adding model search paths, a quantization document, a security policy, a codeowners file, a code review bot configuration, and a file whose name is a hook breaker followed by a commit-like hash. Consequence for the reader: state is kept in a migrated database, the HTTP surface is specified in a file that a linter checks, and an extension tool's dependency versions are decided by the core repository. The hash-suffixed guard file is the one place the tree admits something is parked rather than fixed, and nothing in its name says when it goes away.

## Conclusion

Use ComfyUI when you want every parameter exposed and the work reproducible as a JSON workflow, and when your hardware is modest enough that you care about memory behaviour, because the project's pitch is control and local execution rather than a hosted product. Do not treat it as fully offline by default: the core downloads nothing on its own, but paid API nodes and partner nodes for closed models are in the tree, and the only documented way to force the offline guarantee is a command line flag. Before you depend on it, check four things: that your Python is 3.10 or newer, which the manifest requires; that the three pinned packages, the frontend, the workflow templates, and the embedded docs, are versions you can live with, since they move only by hand edit; that the non essential dependency block is installed if you need image processing or OpenGL paths, because a minimal install simply lacks them; and how a custom node will reach the network, since the offline sentence covers the core and says nothing about extensions.

## FAQ

### how to install comfyui

There are three local routes: a desktop application for Windows and macOS, described as the easiest way to get started, a portable install, and a manual install that supports all operating systems and GPU types, naming NVIDIA, AMD, Intel, Apple Silicon, and Ascend. The readme gives no command for the manual path, which is handled in the documentation.

### Is ComfyUI totally free?

The repository is GPL-3.0 and the readme says the core downloads nothing unless you ask it to. Around that free core sit paid surfaces: an official paid cloud version for people who cannot afford local hardware, optional paid Comfy API nodes that the --disable-api-nodes flag switches off, and partner nodes that reach closed source models.

### Is ComfyUI safe to use?

The readme states that the core does not download anything unless you request it, and the repository root carries a security policy file. The parts that reach a network are the paid API nodes and the partner nodes for closed models, which is why the offline flag exists.

### Can ComfyUI generate videos?

Yes. The feature list names a video generation template set including Wan 2.1 and 2.2, LTX-Video 2 and 2.3, HunyuanVideo 1.5, Kandinsky 5 Video, CogVideoX, Cosmos Predict2, Bernini-R, SCAIL 2, and Mochi, and the built-in tools include frame interpolation and high dynamic range video saving and loading.

### how to use comfyui manager

The repository root carries a requirements file dedicated to the manager, so its dependency versions are pinned by the core project, and extensions themselves live in the custom nodes directory. The readme says ComfyUI can be extended with custom nodes but does not describe the manager interface, which is left to the documentation.

### how to use comfyui locally

Locally you can use the desktop application on Windows and macOS, the portable install, or a manual install covering all operating systems and GPU types from NVIDIA to Apple Silicon and Ascend. The manifest requires Python 3.10 or newer, and the core stays offline unless you ask it to fetch something.

## Sources

- [Official documentation](https://www.comfy.org/)
- [Official README](https://github.com/Comfy-Org/ComfyUI#readme)
- [Project repository](https://github.com/Comfy-Org/ComfyUI)
- [Release notes](https://github.com/Comfy-Org/ComfyUI/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/comfy-org-comfyui