Upgrade a ComfyUI environment with a tested rollback path
An environment upgrade can change model compatibility, node behaviour and output even when the graph file is unchanged. Keep a recoverable baseline and a representative acceptance set before updating a working ComfyUI installation or its supporting libraries.
Capture the working state
Record the ComfyUI revision, Python environment, backend, driver and custom-node revisions. Keep model identifiers and hashes alongside a successful workflow and its permitted inputs. Save the installation's configuration without exposing credentials or private filesystem paths in shared notes.
Identify how the environment can be restored using your normal backup or version-management process. A screenshot of installed nodes is useful orientation but not a complete rollback plan. Confirm that the recorded dependencies can actually be located before changing them.
Test outside the production path
Use a separate test installation or another recoverable environment suited to the project's deployment method. Apply the planned change there first. Avoid updating every dependency at once unless that combination is required and explicitly recorded as the unit being tested.
Run the maintained baseline before importing the full project graph. If the basic workflow fails, isolate that problem before adding custom extensions. Keep the complete error report and distinguish a dependency problem from a model-selection error.
Compare behaviour and resource use
Use representative ordinary and difficult inputs. Check output acceptance, workflow loading, optional branches, completion time and memory observations. Preserve changed results rather than assuming that a fixed seed guarantees identical images after an upgrade.
PyTorch documents reproducibility limits across releases and platforms. Decide whether a difference is an acceptable variation or a regression against the project's requirement. A visually attractive new result does not establish that every important workflow still behaves correctly.
Release with an explicit stop condition
Record the tested version set, release date and conditions that would trigger rollback. Keep the previous environment available until the changed system has passed the required checks. Do not modify the rollback copy while using it as the comparison baseline.
This page replaces unrelated strategic speculation and unsupported optimisation figures with a maintenance procedure. It does not claim that every update improves speed or memory use. The useful outcome is a documented change whose effects can be tested and reversed, rather than an installation that only works until the next unexplained update.