Update or Roll Back Stable Diffusion WebUI Forge
A safe update starts before the download: preserve the working source, environment, settings and test result, then change one layer at a time.
Never update an unnamed state.
Before changing Forge, record the full commit, export sysinfo, preserve user-owned files and run one known-good workflow. Update the source without updating extensions or Torch in the same test.
If the result breaks, first launch with extra extensions disabled. Roll back source only after the failure survives that clean test. The safest exact-commit test is a second checkout with a separate venv, not a destructive reset of the working folder.
Start from the state you have.
“Update” means different operations for a Git checkout, a one-click package and an already broken environment.
Create the rollback point before the pull.
Stop Forge, confirm the original remote and a clean working tree, save the full HEAD hash and sysinfo, back up user state, then allow only a fast-forward update.
Use the Git update protocolKeep an untouched copy of the working package.
The package updater changes software state but does not give you a human-readable commit ledger first. A separate copy keeps the currently working package available while you test the updated copy.
Use the package protocolProve whether the failure follows the source or an extension.
Run the updated source with extra extensions disabled. If the baseline works, restore extensions one at a time. If it still fails, reproduce the saved commit in a separate clean checkout.
Start recovery triageThe official previous archive is a July 2024 snapshot.
It predates modern Forge FLUX support and is not a generic rollback target. Extract it into a separate folder and preserve it as-is; do not overwrite your current installation.
Read the F0.0.17 boundaryFive records make an update reversible.
Mark an item only after the evidence exists outside the state you are about to change. This checklist is a planning aid; it does not save files for you.
Seven gates before “latest.”
The goal is not to avoid change. It is to make the changed variable observable.
Read the maintainer’s backup warning ↗- 01
Stop Forge completely
Close the browser session and stop the console process. Updating files while the Python process is running makes the before/after state harder to trust.
- 02
Confirm the installation type and origin
For a Git checkout, verify that origin is the original lllyasviel repository. For a package, verify its official release source and exact folder before copying or updating it.
git remote get-url origingit status --short --branch - 03
Capture the working source and environment
Save the full Git HEAD, branch/status and a Forge sysinfo file. Sysinfo records the Forge commit, Python/Torch environment, settings and extension commits; review it before sharing because it includes local paths and system details.
git rev-parse HEADwebui-user.bat --dump-sysinfo - 04
Back up user-owned state
Preserve launcher edits, settings, styles, custom CSS, embeddings and extension records. Confirm where models and outputs live. Do not treat venv, cache or downloaded repositories as the only copy of valuable data.
PRESERVEwebui-user.bat · config.json · ui-config.json · styles.csv · user.cssLOCATEmodels · embeddings · extensions · outputsREBUILDABLEvenv · cache · repositories · tmp - 05
Run one baseline before updating
Generate or open the exact workflow you will use for comparison. Record model files, preset, prompt, seed, dimensions, sampler, steps, memory controls and enabled extensions.
- 06
Update one layer only
For Git, use a clean fast-forward pull. For the one-click package, run update.bat only after preserving a separate working copy. Do not update extensions or replace Torch in the same experiment.
- 07
Verify and record the new state
Start with extra extensions disabled, repeat the baseline, save the new commit/sysinfo and only then re-enable extensions one at a time. Keep the old rollback point until the workflow passes.
OLD HEADONE CHANGENEW HEADSAME TEST
A clean fast-forward update.
git pull --ff-only is intentionally allowed to fail. That refusal protects the install from silently merging a diverged history.
Prove origin and cleanliness
git remote get-url origingit status --short --branchgit diff --statExpected: the original Forge URL, the intended branch and no unexplained modifications.
Save the complete before hash
git rev-parse HEADwebui-user.bat --dump-sysinfoKeep the full 40-character hash and the generated sysinfo file with your dated backup.
Move only on a straight line
git pull --ff-onlygit rev-parse HEADIf the pull fails, stop. Do not turn the update guide into an unplanned merge or hard reset.
The folder is the rollback boundary.
The official README says to use update.bat after extraction. For later updates, preserve a known-working package copy before changing its embedded checkout.
- 01
Stop the working package and locate any models or outputs stored inside it.
- 02
Copy the verified package folder to a separately named test folder with enough free space.
- 03
Run
update.batonly inside the test copy; preserve the console output. - 04
Launch the test copy without adding or updating extensions, then repeat the same baseline.
- 05
Keep both folders until the updated copy passes. Never run both instances against one shared venv.
Find which layer actually broke.
A source rollback cannot fix a changed model, corrupted download or incompatible extension unless the failure truly follows the Forge source state.
Reproduce once
Same model files, preset, settings, seed and command-line flags. Save the first error and new sysinfo.
Disable extra extensions
Use the source-defined isolation flag. Do not uninstall anything yet.
webui-user.bat --disable-extra-extensionsBaseline works
The update can start without extra extensions. Re-enable one extension at a time and record its commit.
Route the extension symptomBaseline still fails
Keep the evidence and test the saved source commit in a clean side-by-side checkout.
Prove the regression firstProve the old state beside the new one.
A separate full clone protects the current checkout, creates a separate venv, and makes the comparison reversible.
- 01
Create an independent checkout
Run from the parent folder. The destination must not already contain another install.
git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git stable-diffusion-webui-forge-rollbackcd stable-diffusion-webui-forge-rollback - 02
Switch to the saved source point
Replace the placeholder with the full hash you recorded before the update.
git switch --detach <WORKING_COMMIT>git rev-parse HEAD - 03
Verify exact identity
The returned HEAD must equal the saved 40-character hash. Confirm the original remote and keep the detached state visible in your notes.
git remote get-url origingit status --short --branch - 04
Build a clean environment and test
Let this checkout create its own venv. Keep extra extensions disabled for the first comparison.
webui-user.bat --disable-extra-extensions
the exact saved HEAD is active, a separate venv was created, the same model and settings were used, and the previously working result or behavior is restored. “The UI opened” alone is not enough.
A historical package, not a moving undo button.
The official record contains one package. Its date and feature boundary matter more than the word previous.
webui_forge_cu121_torch21_f0017.7z
- Forge snapshot
- F0.0.17
- Maintainer test date
- 21 Jul 2024
- Release asset size
- 1,897,352,000 bytes
- Release digest
- Not published
- Modern FLUX rollback
- No · predates Forge FLUX support
A rollback is a test result, not a command result.
Use the same acceptance gate after updating and after rolling back.
| Check | Pass condition | If it fails |
|---|---|---|
| Source identity | Full git rev-parse HEAD equals the intended old or new hash. | Stop; you are testing the wrong source state. |
| Environment isolation | The checkout uses its own venv and recorded Python/Torch stack. | Rebuild in a separate folder before comparing behavior. |
| Extension baseline | The workflow is tested with --disable-extra-extensions first. | Do not attribute the result to core Forge yet. |
| Model inputs | Checkpoint/UNet, VAE, encoders and LoRAs are identical and load successfully. | Route to model-file diagnostics, not source rollback. |
| Generation settings | Preset, seed, dimensions, sampler, steps and memory controls match. | Restore the controlled baseline before comparing. |
| Expected behavior | The exact failed operation and its output are restored, not merely the home page. | Keep both states and capture a reproducible report. |
Answers before changing state.
These questions separate source, environment, extensions and user data so an “undo” does not hide a second change.
How do I update Stable Diffusion WebUI Forge safely?
Stop Forge, record the full current commit and sysinfo, confirm a clean working tree, back up user state, run one known-good baseline, then update only the source. Test the updated source with extra extensions disabled before changing anything else.
Should I run update.bat every time I start Forge?
No. run.bat starts the packaged application; update.bat deliberately changes its source state. Update only when you are ready to record, test and, if needed, return to the previous working state.
What should I save before updating Forge?
Save the full Git commit and status, Forge sysinfo, webui-user.bat, config.json, ui-config.json, styles.csv, user.css, extension identities, embeddings, and the locations of models and outputs. A working baseline result makes the backup testable.
How can I see my current Forge version or commit?
In a Git installation, run git rev-parse HEAD for the complete source hash. The Forge --dump-sysinfo route also records Commit, Version, Git status, environment packages, settings and extension revisions.
What if git status shows modified files before an update?
Stop. Use git diff and git diff --stat to identify every local source edit. Back up or document intentional changes and resolve them deliberately; do not use a hard reset just to make the update command pass.
Why does git pull --ff-only fail?
A fast-forward-only pull refuses to integrate a diverged history. Save git status, the current branch, origin URL and HEAD. Resolve the branch or local-change state explicitly instead of forcing a merge into an installation you depend on.
What should I do if a Forge update breaks extensions?
Launch the same updated source with --disable-extra-extensions. If the clean baseline works, the source can start and an extra extension is implicated. Re-enable extensions one at a time, recording each extension commit.
What should I do if a Forge update breaks FLUX?
First repeat the same FLUX files, preset and memory settings with extra extensions disabled. If the failure persists, compare the old and new Forge commit in separate clean environments. The official F0.0.17 previous package predates Forge FLUX support and is not the correct generic FLUX rollback.
How do I roll Forge back to a known working commit?
The safest diagnostic route is a second full clone. Switch that new checkout to the saved commit with git switch --detach, verify git rev-parse HEAD matches the complete saved hash, let it build a separate venv, and test with extra extensions disabled.
What does detached HEAD mean in a Forge rollback?
Git has checked out an exact commit instead of a moving branch. This is useful for a controlled test, but normal pulls are not the way to maintain that state. Keep the saved hash and switch back to main when you intend to resume updates.
Does switching to an old commit also roll back the venv?
No. Git changes tracked source files; it does not reliably restore installed Python packages in venv. A separate rollback checkout with its own newly created venv gives a cleaner comparison than switching an existing environment in place.
Should I delete venv after a failed update?
Not as the first response. First preserve sysinfo and the error, isolate extensions and determine whether the source or environment changed. If you need a clean environment, rename the verified Forge-local venv or use a separate checkout so the old state remains recoverable.
What is the official Forge previous version?
The official previous release currently contains one archive: webui_forge_cu121_torch21_f0017.7z, Forge F0.0.17. It was uploaded on 22 July 2024 and the maintainer described it as last tested on 21 July 2024.
Does the official previous Forge package support FLUX?
Do not use it as a FLUX rollback. The F0.0.17 snapshot was published before the original Forge FLUX update. Use a commit you personally verified with the required FLUX workflow instead.
Will rolling back Forge delete my models or outputs?
A Git switch does not normally manage ignored models and outputs, but destructive commands, in-place package replacement and mistaken folder deletion can. Confirm their exact locations and preserve valuable user data before changing the installation.
How do I return a detached rollback checkout to current main?
Stop Forge, preserve any test evidence, run git switch main, confirm the original origin and a clean status, then use git pull --ff-only. Rebuild or retest the environment if the dependency set differs.
Primary behavior and community symptoms stay separate.
Official code, releases and Git documentation define the procedure. Tutorials and reports expose failure intent but do not select a universal “stable” commit.
Dated tutorial and community research · 7 records
- V01 · Full install and run guide Transcript checked: package updating and first-run state.
- V02 · Sebastian Kamph install guide Transcript checked: package update and Git route context.
- V03 · Forge / FLUX install and rollback guide Transcript checked in full: commit explanation, update risk and custom rollback scripts; scripts not adopted as authority.
- V04 · PromptGeek long-form guide Transcript checked: extensions and clean baseline behavior.
- R07 · Forge announcement reaction Historical backup questions; community context only.
- R17 · Extension breakage reports Extension-isolation intent; anecdotal and not a product-wide result.
- R24 · “Latest Forge broke FLUX” report Update/reinstall search intent; anecdotal and not accepted as root cause.