krita-ai-diffusion: Inpainting Inside Krita with a ComfyUI Backend

The problem is not generation, it is where generation happens

Text-to-image tools produce a whole picture from a whole prompt. That is the wrong shape for most editing work. You have a canvas, a selection, a layer stack, and a specific region you want changed. The README states the project's first goal as precision and control, and it names the reason plainly: creating entire images from text can be unpredictable. The plugin's answer is to keep generation inside Krita and let existing editing constructs do the scoping. A selection becomes an inpaint region. A layer becomes a region with its own text description. A sketch or line art layer becomes a ControlNet input. The audience is therefore narrow and identifiable: illustrators, concept artists and retouchers who already work in Krita and want generative fill as one more brush-adjacent operation rather than a separate application. Someone who wants a prompt box and a gallery of finished images is not the target, and the README's second goal, workflow integration, says so directly by describing the project as an unobtrusive tool rather than a parameter dashboard.

ComfyUI does the sampling, the plugin does the canvas plumbing

The architecture is a split one. The plugin is a Krita Python extension, and the README states that it uses ComfyUI as the backend. Image generation itself runs on Stable Diffusion and Flux model families, with the model list in the feature section naming Flux 2, Z-Image, Stable Diffusion 1.5, XL and Illustrious. The plugin's job is the translation layer: turning Krita selections, layers and control layers into a request the backend understands, and turning results back into something you can preview and keep. Several features fall out of that split. The job queue exists because sampling is asynchronous relative to drawing, so you can queue and cancel generations while continuing to work on the image. History exists because results are previews first and committed content second. Live painting is the same loop run continuously against the current canvas state. ControlNet inputs, listed as Scribble, Line art, Canny edge, Pose, Depth, Normals and Segmentation, are read from layers rather than typed as parameters. Regions are the clearest example of the design: text descriptions are assigned to image areas defined by layers, so composition control comes from the layer stack you already maintain.

Installation is a Krita plugin import plus a backend decision

The README gives a short technical path. Install Krita at version 5.2.0 or newer. Download the plugin from the releases page. In Krita, use Tools ▸ Scripts ▸ Import Python Plugin from File and point it at the downloaded ZIP archive. Restart Krita, open or create a document, then enable the docker via Settings ‣ Dockers ‣ AI Image Generation. Inside the docker, click Configure to either start a local server installation or connect to one. That Configure step is where the second decision lives. The plugin can install and manage a ComfyUI server for you, or you can run your own. The README notes that if the server is already running locally before Krita starts, the plugin will try to connect automatically, and that a remote server works the same way. If you go the manual route, the README points to a list of required extensions and models on docs.interstice.cloud and warns that you should check it to make sure your installation is compatible. That compatibility check is the part people skip, and it is the part that produces confusing failures. Hardware support is documented per vendor: NVIDIA through CUDA on Windows and Linux, AMD through ROCm, Intel through XPU, Apple Silicon through MPS on macOS 14 or newer, and CPU with the explicit note that it is supported but very slow.

The 6 GB VRAM floor is a real boundary, not a suggestion

The README recommends a powerful graphics card with at least 6 GB VRAM for local generation, and then states the consequence without softening it: otherwise generating images will take very long or may fail due to insufficient memory. Treat that as a hard constraint on the local path rather than a tuning target. The feature list includes upscaling to 4k, 8k and beyond without running out of memory, which implies the plugin manages tiling or staged work internally, but the README does not describe the mechanism, so how much headroom that buys on a 6 GB card is not something the supplied material establishes. The other limitation is structural: this is a client. If ComfyUI is not reachable, the plugin has nothing to talk to. A backend update that changes node interfaces can break compatibility, which is precisely why the documentation maintains a required extensions and models list. There is also a support boundary worth reading carefully. The README asks users to use discussions, Discord or the issue tracker, and states that official Krita channels are not the right place to seek help with issues related to this extension. Segmentation, for selecting objects or removing a background, is not in this plugin at all; the README points to a separate project, Acly/krita-ai-tools. If your workflow is mostly cutouts, this is the wrong repository.

Against a standalone diffusion front end

The obvious comparison is a standalone generative UI such as ComfyUI's own graph interface or any of the single-purpose image generation apps. Those tools put model and sampler parameters at the centre of the screen and treat the image as output. This plugin inverts that: the README's stated aim is to be unobtrusive and to synergize with Krita's editing workflow, which is why it ships what it calls strong defaults and versatile default style presets to keep the interface small. The practical difference shows up in what each tool makes easy. In a standalone front end, getting a generation into a specific region of an existing painting means exporting, masking, generating, and compositing back. Here, the selection or layer is the mask, and the result lands in the document. Conversely, a standalone front end gives you direct access to the sampler graph. This plugin abstracts that away, and customization is expressed through presets, custom checkpoints, LoRA and samplers rather than through rewiring nodes. If you want to build unusual pipelines, the abstraction is a cost, not a feature. If you want to keep painting, it is the whole point.

Licence, updates and what maintenance actually involves

The repository is licensed GPL-3.0. That matters for anyone considering bundling the plugin into a distributed Krita build or modifying it for internal redistribution, because the licence carries obligations that a permissive licence would not. This is not legal advice; read the licence text and talk to counsel if you plan to redistribute. On the maintenance side, the release history in the supplied material shows a steady cadence: v1.52.0 in late June 2026, v1.52.1 two days later, and v1.53.0 in late August 2026, with the last push to the default branch on 2026-08-28. The patch release two days after the minor release is a normal signal that regressions get fixed quickly, though the material does not describe what changed in any of these versions, so do not assume a specific fix. The upgrade cost is split across two moving parts. The plugin updates through the same ZIP import path used to install it, and the backend updates on its own schedule, which is why the required extensions and models list exists as a compatibility contract. Budget for the possibility that a ComfyUI update runs ahead of the plugin's tested set. The plugin's own configuration, presets and downloaded models live outside the plugin archive, so a plugin reinstall does not by itself reset your setup, but the supplied material does not document where those files are stored, and that is something to confirm in the user guide before you plan a migration.

Who should install it, and what to check first

Install it if you paint in Krita and your work involves iterative edits to existing images: filling a selection, extending a canvas, swapping a face with IP-Adapter, or driving pose and depth from layers you already keep. The layer-as-region model is the strongest argument for it, because it means your composition control lives in the document rather than in a separate prompt file. Skip it if your hardware is below the documented floor and you are not willing to use cloud generation, if you need segmentation built in, or if you want a tool that runs with no server process at all. Before you commit, verify three things. First, that your Krita is 5.2.0 or newer. Second, that your GPU path is one of the documented ones and that you have the VRAM the README asks for. Third, that your ComfyUI installation, if you bring your own, matches the required extensions and models list at docs.interstice.cloud/comfyui-setup. That last check is the one that decides whether the plugin connects at all.

Editorial conclusion

Adopt it if you already paint in Krita and have an NVIDIA card with at least 6 GB VRAM, or if you are willing to point the plugin at a ComfyUI instance you run yourself. Do not adopt it if you want a self-contained application with no server process, or if you work on hardware below the documented floor. Before installing, confirm your Krita version is 5.2.0 or newer, check the required extensions and models list on docs.interstice.cloud against your ComfyUI build, and decide whether the local server or a cloud connection is the path you want.

Official sources

1. Acly/krita-ai-diffusion on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases