3.4 Setting Up: ComfyUI From Scratch

By this point you know which family you are in (3.1), what the settings do (3.2), and what your machine can run (3.3). This chapter is the workshop itself.

The first decision is not which software. It is whether you are building a pipeline or renting one, because that choice determines what you own at the end.

Three ways to work, and what each one costs you

A hosted generation UI. Services in this category — RunDiffusion, Freepik, OpenArt, Higgsfield, and the aggregator UIs — give you a browser, a GPU you do not own, and a monthly price. The setup time is measured in minutes.

What you buy: convenience, a GPU, and someone else's uptime. What you lose, and this is the part that matters:

• The workflow does not live in a file you can version. Your pipeline exists in their interface. You cannot diff it, back it up, or move it.
• The identity artifact is often out of reach. Some hosted tools will train a concept for you and let you use it inside their product. Fewer will hand you the weights. Chapter 4.5 insists the LoRA is the thing you own — check that the tool gives it to you before you invest a month.
• Your assets live on somebody else's disk, subject to their retention policy and their continuing existence.
• Batch work at 3 a.m. is not yours to schedule.

A hosted UI is a legitimate place to start and a bad place to build. The test is simple: if the service disappeared tomorrow, what would you still have?

A local ComfyUI installation. A node graph that runs on your hardware, stores its workflow as a JSON file you can version, and can load any open-weight model, adapter, upscaler, or detailer in the ecosystem. The setup cost is real — a few hours, and one specific step where most people fail. Everything else in this book assumes it.

No local pipeline at all: API only. Legitimate at low volume. If you are publishing fewer than roughly 30 assets a month, an API plus a scripted prompt library gets you to market without a GPU and without maintenance work that has nothing to do with content.

The hybrid, which is what most operators actually converge on: local for images and training, where the cost per asset is near zero and control matters most; API for video, where self-hosting costs a tier of hardware and a great deal of patience. Chapter 12.4 builds the continuity plan around that split.

Installing ComfyUI: the shape of the procedure

Specific version numbers move. The shape of the installation does not. [UNTESTED]

1. Prepare an isolated Python environment. A dedicated virtual environment or conda environment, on a supported Python version. Isolation is not optional: a system-wide install that shares dependencies with other tools will break, and it will break at the worst moment.
2. Install PyTorch built for your CUDA version. This is the step where most first attempts fail, and the failure is always the same mismatch — a PyTorch build compiled for a different CUDA version than your driver supports. Check your driver's CUDA version first, then install the matching build. If the first test generates noise or throws a CUDA error, this is the line to revisit.
3. Get the application and start it. Clone or download, launch, and confirm the web interface answers on the local port. Confirm you can generate a single image before installing anything else.
4. Install the manager. The community node-and-model manager is what makes the ecosystem navigable. Install it second, not first.
5. Install the identity stack. The adapters from 3.2 — IPAdapter and its face variant, InstantID, PuLID — plus the face recognition model that several of them require. That last component is the classic silent failure: the adapter loads, runs, and returns a stranger, because the recognition model is missing or wrong. Chapter 4.3 walks the stack in order.
6. Install upscalers and a face detailer, for the final stage of the pipeline from 3.2.
7. Run the smoke test. One 1024-pixel image, 20 steps, and record the time and peak VRAM. That number is the first row of the benchmark in 3.5.

The one habit that saves the most pain later: snapshot the environment when it works. Record the exact package versions, and keep a copy of the model manifest. A working environment is an asset, and recreating it from memory after a broken update costs an evening you will not enjoy.

The workflow file is the asset

A node graph is not a setting. It is a program, and it should be treated like one.

Export the graph and version it. ComfyUI serializes a workflow to a JSON file. That file is your pipeline: the exact node arrangement, the model paths, the samplers, the stage order from 3.2. Keep it in version control or at least in a dated archive, and keep one canonical file per job — generation, reference editing, repair, upscale, video.

Why this matters more than it sounds. When a node pack updates and breaks your graph, the difference between a ten-minute fix and a lost weekend is whether you can diff the working version against the broken one. When you onboard help in chapter 12.1, the workflow file is the deliverable that makes the pipeline reproducible by someone else. And when a hosted UI changes its interface overnight — which is the failure mode 3.4 opened with — a local workflow file is unaffected.

Keep a requirements record next to it. The graph and the environment versions belong together. A JSON workflow that references a node version nobody has anymore is a document about the past.

Where models live, and why the folder names matter

ComfyUI reads models from a fixed directory tree, and each node type looks in a specific place. Get this wrong and the model is invisible — the single most common "it does not work" report in every community.

The folders you will actually use:

The two that trip people up are insightface and the encoder folders. When an adapter produces an unrelated face, nine times in ten the recognition model is missing or in the wrong directory.

The training tool: four options, ranked by difficulty

You need one of these to produce the LoRA from chapter 4.5. They all emit the same artifact type — a .safetensors adapter file — so the choice is about friction, not output format.

The recommendation is to start at the top of that list and move down only when you need a capability the simpler tool lacks. The first training run should be the one most likely to succeed, because a successful run teaches you the pipeline and a failed run teaches you nothing except that you were tired.

Hosted training is the fastest first run of all. A rented GPU running a template, or a hosted trainer at roughly $2 for a base run, produces your first LoRA the same day without installing anything locally. [AS OF 2026-10] Do that once before you build a local training environment. Chapter 4.5 covers the parameters, which are the same regardless of where the run happens.

Managing models without drowning

At ten models this is a non-issue. At a hundred it is the reason you cannot find the checkpoint that produced your best frame from March.

Name for what the file is, not what it was called when you downloaded it. A name that encodes family, role, precision, and version — the persona LoRA's version number above all — is legible six months later and in a directory listing.

Never overwrite a LoRA. Keep every version. The training run is two to seven hours, and the version you overwrite is the one you spent a week tuning prompts against.

Keep a model manifest. One file listing what you have, its license, its source, and a checksum. This is the same record that chapter 11.5 requires for provenance, and it doubles as your reinstallation list when a drive fails.

Budget the disk before it fills. Full-precision checkpoints, video models, and rendered output add up quickly. Chapter 3.6 sets the archive structure.

Local from day one, or API first?

Note what is not on that list: what other people are doing. The correct answer is a function of your volume, your hardware, and whether you need to own the artifact.

Where this goes wrong

Installing everything before the first image works. Generate one image first. Then add one capability at a time, and confirm each one.

No environment isolation. A shared Python environment is a countdown timer.

Updating a working environment mid-project. Pin versions, snapshot when green, and update between projects rather than during one.

Choosing the hardest training tool because a tutorial used it. You are not being graded on difficulty.

Treating a hosted UI as a pipeline. If your workflow is not a file you control, you do not have a workflow; you have a subscription.

Ignoring the recognition model. The adapter that returns a stranger is almost always missing an insightface-class component.

Training before you can reliably generate. Learn inference first. Training amplifies whatever your prompting already does.

The gate

1. ComfyUI answers on its local port and generates one 1024-pixel image. Yes or no?
2. How long did that image take, and what was the peak VRAM?
3. Are all model directories populated, including the recognition model?
4. Which training tool are you using, and where will the LoRA file go when it is finished?
5. Is the environment snapshot recorded, with versions and a model manifest?
6. If your chosen hosted service disappeared tomorrow, what would you still have?

What you leave with

A decision about what you are building versus renting, the shape of a ComfyUI installation and the one step that fails, the directory map without which nothing loads, four training tools ranked by the friction they cost you, a model-management convention, and a table that answers local-versus-API with your own numbers rather than someone else's setup.