August 2025 archive: a reproducible ComfyUI onboarding record
A successful ComfyUI installation should be demonstrated by a saved, inspectable output rather than an application window alone. This archive now provides an onboarding record that separates environment preparation, model provenance and the first completed workflow.
Record the intended installation
Write down the operating system, accelerator model and installation route before changing the machine. Consult the maintained system requirements for that specific combination. Support for a brand does not establish support for every device, driver or installation method sold under its name.
Keep the application version and any required environment information with the project. Avoid treating a tutorial screenshot as the installation specification. Record where the installer or repository came from and do not install an unrelated download merely because its filename resembles a missing component.
Keep the first workflow small and identifiable
Use the maintained basic text-to-image example as the initial compatibility check. Identify every required model component and its source. Download permissions and licences remain relevant even when an example workflow is publicly available; a graph does not include permission to use every possible replacement model.
Save the unmodified example separately from your experiments. Use a harmless original prompt and a supported output size. Do not add optional extensions, adapters and enhancement stages before you have evidence that the basic route completes on the intended environment.
Define what passing actually means
Check that the final file exists, opens correctly and corresponds to the intended input. Preserve the graph and output together. A successful queue submission, a visible preview or the absence of a startup error is not the same as a complete saved deliverable.
Repeat the example after restarting the application. Record any manual intervention, missing-component messages or changes needed for completion. If the test only succeeds at a smaller size, keep that limitation visible rather than describing the full target workload as verified.
Turn failures into a useful support record
Capture the first observable error and the stage where it occurs: startup, model loading, sampling, decoding or saving. Remove credentials and private paths before sharing logs. Change one condition at a time in a copy, keeping the original failing case available for comparison.
The previous archive did not provide a defensible census of installations or commercial adoption. This revision makes no such numerical claim. Its deliverable is a repeatable onboarding record: environment, input, exact workflow, completed file and a limited statement of what was actually checked. Revisit it when dependencies change.