Most image-generation apps hide the work behind a prompt box and a few sliders. ComfyUI does the opposite: it shows you the whole chain as a graph of nodes you wire together. Load a model, encode the prompt, sample, decode, save, each step is a box on a canvas. That is exactly why it looks intimidating, and exactly why it is the most flexible open-source image tool there is. For a business making images every week, it is also a way to stop paying per credit.
The good news for a first run: you do not have to build anything. ComfyUI ships with a default workflow already wired up. Your job for the first hour is “edit the prompt, click a button, get an image.” Everything we produce runs through ComfyUI, and daily use really is that simple once it is set up. This guide gets you there, then shows how we turned the default graph into a repeatable pipeline and how a local language model can write the prompts.
What do you need to run ComfyUI locally?
What you will end up with
- ComfyUI installed and running in your browser at
http://localhost:8188. - A model in the right folder so the default workflow has something to run.
- Your first generated image, made entirely on your own machine.
No subscription, no credits, no images leaving your disk.
Before you start
You need a Mac, Windows, or Linux machine with 16GB of system RAM. A GPU is strongly recommended: Apple Silicon, NVIDIA, or AMD all work. For the better models like Flux you want 8GB or more of VRAM, or 16GB-plus of unified memory on a Mac. You can run on CPU, but it is slow enough that you will not enjoy it.
This is a power-user tool, the most involved setup we cover. The payoff is that nothing else gives you this much control. If you only want to type a prompt and get an image with zero learning curve, Fooocus uses the same underlying engines with a far simpler interface, and it is what we hand to beginners.
On Mac and Linux you will need Python 3 and git. On Windows there is a portable build that skips all of that, covered below. If you want to turn frames into video clips later, install ffmpeg too (brew install ffmpeg on a Mac) and make sure it is on the PATH. It does no generation; it is the post step.
How do you install ComfyUI?
Step 1: Install ComfyUI
On Windows, take the easy path: the portable build.
- Go to https://github.com/comfyanonymous/ComfyUI/releases.
- Download
ComfyUI_windows_portable.7zand extract it. - Run
run_nvidia_gpu.batif you have an NVIDIA card, orrun_cpu.batif you do not.
On macOS and Linux, install from the repo into a virtual environment:
# clone
git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
# create a venv (recommended)
python3 -m venv venv
source venv/bin/activate
# install requirements
pip install -r requirements.txt
On Apple Silicon, that requirements install uses MPS for GPU acceleration automatically, nothing extra to configure. That is the reason a single Mac can carry a whole image pipeline. On Linux or Windows with an NVIDIA card, install the CUDA build of PyTorch first, then the rest:
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
pip install -r requirements.txt
Step 2: Download a model
ComfyUI does not ship with a model, and it will warn you if it cannot find one. The default workflow expects a checkpoint in models/checkpoints/. A standard SD 1.5 model is a fine starting point because it is small and runs on almost anything:
curl -L -o models/checkpoints/v1-5-pruned-emaonly.safetensors \
https://huggingface.co/runwayml/stable-diffusion-v1-5/resolve/main/v1-5-pruned-emaonly.safetensors
The folder structure matters more than you would expect. Checkpoints, VAEs, LoRAs, encoders and embeddings each go in their own subfolder under models/. Put a file in the wrong place and it simply will not appear in the UI, with no error to explain why.
Step 3: Launch and open the canvas
Start the server:
python main.py
Then open http://localhost:8188 in your browser. The default workflow loads automatically, a basic generation pipeline already wired together. You are looking at a graph of connected nodes. Do not try to understand all of it yet.
How do you generate your first image in ComfyUI?
You can generate your first image without building anything:
- Find the Load Checkpoint node and confirm your model name appears in it. If it does not, the model file is in the wrong folder, go back to step 2.
- Find the CLIP Text Encode (Positive Prompt) node and edit the text to whatever you want to generate.
- Click Queue Prompt in the top right.
- Watch the progress move through the nodes.
- The finished image appears in the Save Image node.
That is the whole loop, and it is the loop you will use every day: edit the prompt, queue, look at the result. The first time it works, remember what just happened. The image was generated on this disk, no cloud, no credits spent.
To get a feel for the node graph, change one parameter, the seed, the step count, or the sampler, and queue again. Comparing two runs that differ by one setting is the fastest way to understand what each node does.
From the default graph to a Flux Schnell workflow
The graph we actually use for production is a Flux Schnell pipeline. It needs more files than the default, each in its own folder: the Flux model in models/diffusion_models/, the T5 and CLIP encoders in models/text_encoders/, and the VAE in models/vae/. Once those files showed up in their nodes, the graph ran. The first Flux generation was slow, because the model is large (12GB or more for the FP8 build) and has to load. Every generation after that was fast. That first-load lag is a one-time cost per session, not the per-image speed.
The habit that turns a node graph into a pipeline is saving it. Once a graph is built, save it as a JSON file. Dragging that file onto the canvas reloads the entire pipeline at once, so nothing is rebuilt: drag in the workflow, edit the prompt node, and queue. For batch work we let the graph run a set rather than a single image, such as thumbnails, social cards and header variations. The same graph that makes one image makes fifty without anyone touching it between runs.
How do you turn frames into a clip with ffmpeg?
Some jobs want motion, not a still. When ComfyUI produces a sequence of numbered frames, ffmpeg assembles them into a clip:
ffmpeg -framerate 24 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p output.mp4
That stitches the frames at 24 frames per second into an MP4. ffmpeg does none of the AI work. The flag order matters: input options go before -i and output options after.
What are the gotchas with ComfyUI?
ComfyUI rewards the time you put in, but a few things bite newcomers. In our own build the breakage was never the model. It was always the plumbing.
- The node graph is a real learning curve. Nodes go everywhere, and it feels like a lot at first. For most use, “drag in a workflow, edit the prompt, run” is the entire job, and the curve is paid once.
- Model folders are unforgiving. A file in the wrong subfolder under
models/just will not show up. When something is missing from the UI, check the folder first. - The first Flux generation is slow. The Flux model is large (12GB or more for the FP8 version) and takes time to load. Once it is in memory, later generations are fast.
- On Apple Silicon, VRAM is unified memory. You can run Flux on a 32GB-plus Mac, but it eats into everything else while it is loaded, so plan around having it resident.
- PyTorch on a Mac holds on to GPU memory. By default it reserves memory in chunks and does not release it, which starves other processes on a shared pool. Setting
PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0forces it to allocate and release on demand. - Custom nodes can break on update. ComfyUI ships frequently, and community node packs sometimes lag behind. If a workflow matters, pin ComfyUI and its custom nodes to a known-good state rather than updating blindly.
- Workflows are not always portable between machines. Different model file names, paths, or node versions can break a shared workflow, because the JSON alone does not carry the files. Write down the exact model file names each workflow expects.
Our verdict, in short: ComfyUI is the cornerstone of our image production, and every featured image we make runs through it. We reach for Fooocus when teaching beginners or showing a client something fast, but for actual production it is ComfyUI every time, because we need specific models, we rely on custom workflows, and the community ships new model support as ComfyUI nodes first. It earned that place for an unglamorous reason: it gave us a process we can repeat instead of a box we have to coax. The node graph pays back fast for any team making more than a handful of images a week.
How does ComfyUI compare on cost with a paid image subscription?
Paid image-generation subscriptions are priced by month and by generative credits. Their plans cost about US$9.99 to US$19.99 a month for 2,000 to 4,000 credits, from the vendors’ published prices on 17 October 2026. The plans we read do not say how many images a credit buys, so we cannot turn those prices into a cost per image without guessing, and we will not guess.
ComfyUI has no subscription and no credits. Once the machine and the models are on your disk, another image costs electricity and waiting time. We have not timed a fixed batch of images at publish size with SD 1.5 or with Flux in ComfyUI on our test machine, for example 50 social cards with Flux Schnell, so there is no images-an-hour, peak memory, electricity-per-image or cost-per-image figure here. That test is on our list.
The case for a business rests on consistency more than price. The saved JSON file fixes the model, the sampler and the steps, so the image on Friday matches the image on Monday, and a second person can produce it without learning the graph. Whether the volume a given team needs justifies the learning curve is a question we have not measured. There is also a rights and privacy reason: briefs, unreleased product names and client references never leave the machine.
Staff time sits on the other side of the ledger: this is the most involved setup in our guides, and Fooocus, mentioned above, is the gentler route for colleagues who only want a prompt box. Commercial terms differ by model, so read each model’s licence on its Hugging Face page before using its images in paid work. A workflow is only as usable as its least permissive file.
What should you learn in ComfyUI next?
Two upgrades matter most once the basics work. First, install ComfyUI Manager (https://github.com/ltdrdata/ComfyUI-Manager), which makes finding and installing nodes and models far less painful. Second, once you are comfortable, move up to a stronger model like Flux for sharper results, with the larger download and VRAM cost that comes with it.
The fastest way to learn the node graph is to load someone else’s workflow rather than building from zero. Drag a workflow JSON file onto the canvas and the entire pipeline loads at once. The official examples and the Civitai community are full of them.
A third upgrade is a local language model that writes the prompts. Type “cyberpunk street market at night” and you get something generic: a row of neon signs, a wet road, a figure in a trench coat. The model did what you asked, but the prompt is far shorter than what Flux or SDXL needs to produce something distinctive.
How do local LLMs connect to ComfyUI?
ComfyUI has no built-in LLM capability. To add one, you need a custom node that either makes HTTP calls to an LLM server or loads a GGUF model directly.
The cleanest pattern is to run the LLM as a separate server. Ollama runs as a background service on the Mac and exposes an OpenAI-compatible API on http://localhost:11434/v1. A ComfyUI custom node sends a chat completion request to that endpoint, gets back text, and passes it into a CLIP text encode node. The image model never sees the LLM, only the expanded prompt. Pull a small model like qwen3.5:4b or gemma4:e2b for lightweight prompt expansion, or qwen3-vl:8b if you want vision support.
On the ComfyUI side, the comfyui-ollama-image-to-prompt node supports both vision mode (image-to-prompt with VLMs) and text mode (keyword-to-prompt with regular LLMs). It ships with presets for different output formats: dense descriptive prose for Flux, Danbooru tags for NoobAI, JSON extract for structured workflows. The ComfyUI-LLM-text-processor node is built for Apple Silicon and runs a Gemma 4 GGUF model via an auto-downloaded macOS llama.cpp binary.
The alternative is to load the LLM inside ComfyUI with a node pack that bundles llama.cpp bindings. The ComfyUI-LLM-Session pack does this for Llama, Mistral, Qwen, DeepSeek, Gemma and other GGUF models, with no external daemon, persistent multi-turn sessions stored in files, and an image input through its vision handler. ComfyUI_LocalLLMNodes takes the same route. On a Mac, the standard ComfyUI GGUF loader has had issues with Apple’s MPS backend: without a fork of ComfyUI-GGUF that patches the dtype handling, you get an “unknown model architecture” error. The patches have been submitted upstream.
How does a local LLM change the prompt?
A raw prompt like “abandoned library, overgrown” produces a usable image but a predictable one. The LLM expands it into something a diffusion model can work with: “A grand Victorian-era library with collapsed oak shelves, vines creeping through broken stained-glass windows, dust motes suspended in shafts of amber light, scattered leather-bound books with gold foil peeling, moss on the marble floor, a single candle flickering on a reading desk.”
The nodes do this with a system prompt such as “You are an expert at creating detailed Stable Diffusion prompts. Output only the expanded prompt, no explanation.” The output connects directly to a CLIP text encode node, so nothing is edited by hand between the LLM and the image step. Vision-capable models like Qwen3-VL or Gemma 4 E4B can also describe a reference image, its lighting, composition and mood, and that description becomes the seed for a new generation.
How much memory do an LLM and an image model need together?
On unified memory the GPU and CPU share one pool, which is a hard constraint for running two models at once. An 8B LLM in Q4_K_M needs 5 to 6 GB on top of the image model. With a Flux dev variant loaded as well, a 16 GB Mac has almost no room left for the OS, a 32 GB Mac is tight but workable, and a 64 GB Mac runs the combined pipeline comfortably.
The separate-server pattern helps. When the LLM is not generating, Ollama unloads it, and the ComfyUI process keeps the image model loaded, so the two rarely compete. Loading the LLM inside ComfyUI keeps it resident in the same process as the image model, and that route suits machines with 48 GB or more. A hybrid also works: a small model inside ComfyUI formats prompts while a larger vision model on Ollama describes input images. It is the most flexible pattern and the one with the most nodes to wire.
Our own measurement shows why the order matters. On our test machine, two models fitted side by side easily on 48 GB, but when both generated at once the faster one lost 65 percent of its speed, as we found when we ran two models at once on 48 GB. Those were two language models, not an LLM and an image model, so treat it as a warning rather than a measurement of this pipeline. The Ollama pattern runs the prompt step and the image step one after the other. We have not timed an LLM prompt step feeding Flux on our M4 Pro, so we give no images-per-hour figure and no cost per usable image; that run, with a count of outputs usable without edits, is on our list.
Text encoders on Apple Silicon had their own issue. A March 2026 pull request to the Comfy-Org/ComfyUI repository found that the text_encoder_device() function forced text encoders onto the CPU instead of the MPS GPU. The fix adds VRAMState.SHARED to the device-selection condition. Without it, non-quantized text encoders like a bf16 Gemma 3 12B run entirely on CPU and prompt encoding slows down. The fix has been merged in recent ComfyUI builds.
Video is further behind than images. Our LTX-Video test on ComfyUI on an M4 Pro produced a 3.9-second, 768 by 512 clip in just over three and a half minutes, blurry and not usable, after a VAE format trap and a DualCLIPLoader bug.
You now have a complete image-generation pipeline running on your own machine, where every step is visible and adjustable, and not a single image leaves your disk.
