InvokeAI: a node-based Stable Diffusion workspace you host yourself

What InvokeAI solves, and for whom

Most diffusion front ends force a choice. A command-line script gives you reproducibility but no canvas. A single-page prompt box gives you speed but no way to compose a multi-step pipeline. InvokeAI sits in the middle: it runs a locally hosted web server with a React UI, and inside that UI it offers a Unified Canvas for inpainting, outpainting and brush work alongside a node-based workflow editor.

The README describes the project as a creative engine that "serves as the foundation for multiple commercial products", and the pyproject classifiers list both End Users/Desktop and Developers as intended audiences. That dual framing is accurate. An illustrator can open the canvas and paint; an engineer can build a graph that chains a checkpoint, a ControlNet and an upscaler, then hand the same graph to the illustrator as a reusable workflow.

The repository layout supports this reading. There is a frontend build path (pnpm modules, an OpenAPI schema generator, a typegen step) and a Python package under invokeai/. The Makefile exposes both sides: frontend-dev, frontend-build and frontend-test on one hand, and mypy, test and wheel on the other. This is not a thin wrapper around a script.

The node graph, the canvas and the gallery as one data flow

InvokeAI's architecture is a Python server exposing an API, with a React UI on top. The Makefile includes targets named openapi and frontend-openapi, which generate the OpenAPI schema for the app, and frontend-typegen, which generates frontend types from that schema. That tells you the API contract is the boundary between the two halves: the UI does not reach into Python internals, it calls documented endpoints.

On top of that boundary sit three user-facing surfaces. The workflow editor is a node graph, where each node is a generation step and edges carry images, latents or parameters. The Unified Canvas is a single surface that combines generation with in/out-painting and brush tools, so an artist can extend an image or paint a mask without leaving the view. The board and gallery system stores outputs with metadata, and the README states that images can be dragged and dropped onto any image-based UI element and that "rich metadata within the Image allows for easy recall of key prompts or settings".

That last point matters more than it sounds. If the metadata travels with the image, a result generated six months ago can be reconstructed by reading its settings rather than by keeping a separate notes file. The same metadata is what a workflow node consumes when you re-run a graph.

Model support is broad and explicit. The README lists SD 1.5, SD 2.0, SDXL, SD 3.5 Medium and Large, Flux.1 Dev, Schnell, Kontext, Krea, Redux and Fill, Flux.2 Dev and the Klein 4B and 9B variants, Qwen Image and Qwen Image Edit, Z-Image Turbo and Base, Krea 2 Turbo and Raw, Anima, Ideogram 4, ERNIE-Image and ERNIE-Image-Turbo, plus CogView 4. Three entries are marked API Only: Nano Banana, GPT Image and Wan. The README also notes support for ckpt, diffusers and some gguf models, and mentions SAM and SAM2 for object segmentation and selection.

Installing InvokeAI and running a first generation

The README does not ask you to pip install anything. It says: "To get started with Invoke, Download the Launcher" from the invoke-ai/launcher releases page. The launcher is a separate repository, so the install path is a downloaded binary rather than a Python package install. The README points to the installation docs at invoke.ai/start-here/installation/ for the details, and to a troubleshooting FAQ for common installation problems.

If you are working from the repository itself rather than the launcher, the Python requirement is fixed in pyproject.toml: requires-python is ">=3.11, <3.13". A Python 3.13 environment will not satisfy that constraint. The build backend is setuptools with pip and wheel.

The editable install pulls the pinned dependency set, which includes diffusers[torch]==0.40.0, compel>=2.4.0,<3, gguf, and mediapipe==0.10.14 for the mediapipeface ControlNet model. Note that bitsandbytes is conditional on sys_platform!='darwin', so macOS installs skip it.

Once the server is running, the README's feature list is the practical starting point: open the web UI, then choose between the canvas and the workflow editor. For a first real use, the workflow editor is the better entry point because it makes the pipeline visible. Add a model node, a prompt node, and a generation node, connect them in order, and run. The gallery stores the result with its metadata attached.

If you are building against the API rather than the UI, the Makefile gives you the schema target:

make openapi

That target generates the OpenAPI schema for the app, outputting to stdout, which is the same contract the frontend types are generated from.

Where InvokeAI is the wrong tool

The install model is the first constraint. InvokeAI is a locally hosted server. If your team's requirement is a browser tab that works on a locked-down laptop with no GPU, the launcher-and-local-server path does not fit, and the README offers no hosted alternative. The FAQ link exists for installation problems, which is an implicit acknowledgement that installation is where users get stuck.

The second constraint is the Python version window. ">=3.11, <3.13" is narrow. If your infrastructure standardises on Python 3.13, you are either running InvokeAI in a separate environment or waiting. The pinned diffusers==0.40.0 has the same effect: you cannot float that dependency to a newer release without stepping outside what the project tests against.

The third is the API-only model list. Nano Banana, GPT Image and Wan are marked API Only in the README. That means those models are not running on your hardware; requests leave your machine. For anyone whose reason for choosing a self-hosted tool is data locality, those three entries are a different product category sitting inside the same UI, and the distinction is easy to miss when you are scanning a feature list.

Finally, the README's model list is long but specific. If your work depends on a checkpoint family that is not on it, the README does not promise compatibility, and gguf support is described as "some gguf models" rather than all of them.

InvokeAI against ComfyUI: two answers to the same question

The comparison people actually search for is InvokeAI versus ComfyUI, and the difference is where each puts the burden. ComfyUI is a node graph first: the graph is the application, and everything else is built around it. InvokeAI is a canvas and gallery first, with a node graph available when you need to define a repeatable pipeline.

That ordering shows up in the surfaces. InvokeAI's Unified Canvas is described in the README as "a fully integrated canvas implementation with support for all core generation capabilities, in/out-painting, brush tools, and more". A ComfyUI user typically reaches comparable inpainting through a graph of nodes with a mask input. Both approaches work; the question is whether you want to paint on the image or wire the operation.

The second difference is packaging. InvokeAI ships a launcher as the recommended install, and its repository carries a frontend build pipeline with pnpm, an OpenAPI schema step and generated types. That is the shape of a product with a supported install path. ComfyUI's ecosystem is broader and its custom-node culture is deeper, which cuts both ways: more extensions, and more variation in what any given setup does.

Neither is strictly better. If your output is a reusable pipeline that you want to hand to a colleague as a graph, InvokeAI's workflow editor plus its metadata-carrying gallery is a coherent answer. If your output is a bespoke node arrangement that depends on community extensions, the other side of the comparison is where that lives.

Licence, releases and what upgrades cost

InvokeAI is Apache-2.0, and the README calls it "free to use under a commercially-friendly license". That is the project's own wording; it is not legal advice, and the LICENSE file in the repository root is the document that governs. The repository also carries separate licence files: LICENSE-HiDiffusion.txt, LICENSE-PiD.txt, LICENSE-SD1+SD2.txt and LICENSE-SDXL.txt. Those are model-related licences sitting alongside the application licence, and they matter because the application being Apache-2.0 does not make every model you load Apache-2.0. Stable Diffusion model cards carry their own terms, and the repository includes Stable_Diffusion_v1_Model_Card.md at the top level.

On cadence, the last push to main was on 2026-08-25, the same day v6.14.0 was released. Before that came v6.14.0-rc2 on 2026-08-16 and v6.13.8 on 2026-08-13. The presence of a release candidate two days before the tagged release suggests a normal stabilisation window rather than continuous shipping.

Upgrade cost is dominated by the pinned dependencies, not by the application code. diffusers is pinned exactly at 0.40.0, and the pyproject comments describe the pins as being there "for reproducible builds". That is a deliberate trade: you get a known-good combination, and you accept that bumping diffusers means testing against a version the project has not certified. The mistral-common pin carries an explicit warning in the comment, noting that the loader depends on private surface (Tekkenizer internals) for the FLUX.2 dev Mistral encoder. Dependencies on private internals are the kind of thing that breaks on a minor version bump, which is presumably why the pin is there.

If you install via the launcher, upgrade handling belongs to the launcher, not to you. If you install from the repository, upgrading means re-resolving the pinned set and re-checking the Python version window.

Editorial conclusion

Adopt InvokeAI if you want a self-hosted generation workspace where the canvas, the gallery and a node graph live in the same application, and if you are willing to run a Python 3.11 or 3.12 environment with a GPU. Do not adopt it if you need a hosted service with no local install, or if your pipeline depends on a model family the README does not list. Before committing, verify three things: that your GPU and driver combination is covered by the installation documentation, that the models you intend to use appear in the supported list, and that the API-only entries (Nano Banana, GPT Image, Wan) are acceptable to you, because they route through an external API rather than a local checkpoint.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes