AUTOMATIC1111 stable-diffusion-webui: a Gradio front end for local Stable Diffusion

What AUTOMATIC1111 stable-diffusion-webui actually is

Stable Diffusion ships as a Python library and a set of model weights. Driving it directly means writing sampling loops, handling VRAM, decoding latents, and saving images with their parameters attached. This project puts a Gradio web interface in front of that work. The README describes it as "A web interface for Stable Diffusion, implemented using Gradio library," and the feature list is long: txt2img and img2img, inpainting, outpainting, upscaling, textual inversion training, LoRA and hypernetwork support, a checkpoint merger, an API, and a settings page that exposes sampling parameters.

The audience is people who want local generation with control over the pipeline. The README states 4GB video card support, with reports of 2GB working, and notes that embeddings can be trained on 8GB with reports of 6GB. Those are the project's own claims, not measured figures. The practical implication is that this is aimed at a workstation or a gaming PC with a discrete GPU, not at a laptop with integrated graphics and not at a phone.

It is a single-user tool. The Gradio server binds to a local port and there is no account system, no queue shared between users, and no isolation between sessions. If you want multi-tenant image generation, this is the wrong layer to build on.

How the Gradio front end talks to the diffusion pipeline

The repository layout shows the split. webui.py and launch.py are the entry points, modules/ holds the Python implementation, scripts/ holds the built-in UI scripts, extensions-builtin/ holds bundled extensions, and extensions/ is where user-installed ones land. The front end is Gradio 3.41.2, pinned exactly in requirements.txt, and the HTTP layer underneath is FastAPI, pinned at fastapi>=0.90.1. That combination is why the API exists at all: Gradio serves the UI and FastAPI serves the programmatic endpoints.

Generation parameters are persisted into the image itself. The README states that parameters are saved "in PNG chunks for PNG, in EXIF for JPEG," and that dragging such an image onto the PNG info tab restores the parameters into the UI. That is the mechanism behind reproducibility here: the seed, sampler, steps, prompt and model are recoverable from the file, not from a separate database. It can be disabled in settings.

Prompt handling is not a thin passthrough. The README documents attention syntax such as a man in a ((tuxedo)) and an alternative weighted form a man in a (tuxedo:1.21), prompt editing that changes the prompt mid-generation, and Composable-Diffusion, which uses uppercase AND to combine prompts, for example a cat :1.2 AND a dog AND a penguin :2.2. It also states there is no token limit for prompts, where the original Stable Diffusion allowed up to 75 tokens. Those are all parsed before the sampler runs.

Built-in scripts and extensions are loaded from disk at startup. That is the extension model: drop a directory into extensions/ and the UI gains tabs. The flip side is that extensions run with the same privileges as the server process. The README notes that running arbitrary Python from the UI requires the --allow-code flag, which implies the default posture is to keep that off.

Installing AUTOMATIC1111 stable-diffusion-webui and generating a first image

The README does not give inline install commands. It points to a Dependencies wiki page and then to per-vendor instructions for NVidia (marked recommended), AMD, and Intel CPUs and GPUs, with the Intel path hosted in a separate repository. The repository does ship launcher scripts, so the install is driven by those rather than by a package manager.

On Windows, the launcher is webui-user.bat. The README states you still must install Python and git yourself. A minimal first run looks like this:

# from the repository root, Windows
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui
webui-user.bat

The first launch creates a virtual environment and installs the pinned dependencies, which is why it takes a while. On Linux and macOS the equivalent entry point is webui.sh, and there is also a webui-macos-env.sh for environment defaults. The repository includes environment-wsl2.yaml for a WSL2 setup.

Once the server is up, the default address is http://127.0.0.1:7860. That port is not a guess: pyproject.toml sets base_url = "http://127.0.0.1:7860" for the test suite, so the test configuration assumes the same default the UI uses.

For a first real use, put a checkpoint in models/. The top-level models/ directory is where the project expects weights, and the README states that checkpoints in safetensors format can be loaded. After reloading the checkpoint from the UI, the txt2img tab takes a prompt and produces an image, and the generation parameters are written into the PNG unless you turn that off in settings.

If you want the API instead of the browser, it is served by the same process. The README lists an API as a feature but does not document its routes, so the endpoint shapes have to come from the running instance rather than from this page.

Where the project is thin, and where it is the wrong tool

The most concrete limitation is maintenance cadence. The last push to master was on 2025-02-09, which is also the date of the v1.10.1 release; v1.10.0 landed on 2024-07-27. The repository is not archived, but that gap is the reason not to describe it as actively developed. If your work depends on fixes for a newly released model architecture, you are waiting on a maintainer's schedule that the repository does not publish.

Dependency pinning is the second constraint. requirements.txt pins gradio==3.41.2, transformers==4.30.2, protobuf==3.20.0 and pillow-avif-plugin==1.4.3, while torch itself is unpinned. That combination is what makes the install reproducible, and it is also what makes it brittle: a newer torch that changes an internal API can break a pinned companion library, and the fix is to wait for an upstream bump or to pin torch yourself.

Third, the README's hardware claims are reports, not guarantees. "4GB video card support (also reports of 2GB working)" is the wording used, and the same hedge appears for embedding training at 6GB. Treat those as best-case anecdotes.

The wrong-tool cases are clear. If you need a hosted endpoint with an SLA, this is a local server. If you need multiple users with separate histories, there is no user model. If you need a stable public API contract, the README lists an API but does not specify it, so you cannot rely on route stability from the documentation alone. And if you need a project with a predictable release train, the dates above say otherwise.

Forge and the other forks, and what actually differs

The search terms around this project are dominated by forks, which is itself informative. The recurring alternative is Stable Diffusion WebUI Forge, which appears in the related searches both as "stable diffusion webui forge" and in several misspelled variants. The distinction that matters is not the feature list, which overlaps heavily, but the memory and performance strategy: Forge is a separate codebase that reworks how the pipeline allocates and offloads, aimed at running larger models on smaller cards.

This project's answer to the same problem is different. It offers --xformers as a command line argument, which the README describes as a "major speed increase for select cards," and it exposes VRAM-related settings through the UI rather than through a rewritten backend. It also supports running on 4GB cards by the project's own claim. So the two approaches are: swap in a different pipeline implementation, or tune the existing one with flags and settings.

The practical difference for an adopter is extension compatibility and drift. Extensions written against this project's script loading model are not guaranteed to work unchanged on a fork, and vice versa. If your workflow depends on a specific extension, the fork question is decided by where that extension is maintained, not by benchmark charts you find in a search result.

A second alternative is not running a UI at all: calling the diffusers library directly from Python. That removes the Gradio dependency and the pinned gradio==3.41.2 constraint entirely, at the cost of writing the sampling loop, the parameter persistence and the image viewer yourself. The README's PNG-chunk parameter saving is a good example of something you would have to reimplement.

Licence, upgrade cost and what to check before you commit

The project is AGPL-3.0, and the README notes it with the line "Now with a license!" The AGPL is the network-copyleft variant: if you modify the program and let users interact with it over a network, the licence's terms attach to that interaction in a way the plain GPL does not require. That matters for anyone planning to wrap this in a hosted product. This is a description of the licence family, not legal advice; the obligations you actually carry depend on your distribution model and belong with a lawyer.

Upgrade cost is driven by three things visible in the repository. First, the pinned dependencies in requirements.txt mean an upgrade is a coordinated bump, not a single version number. Second, extensions live in extensions/ and built-in ones in extensions-builtin/, so an upgrade can break third-party code that hooks the same internals. Third, the release history is sparse: v1.10.0 in July 2024, v1.10.0-RC before it, and v1.10.1 in February 2025. There is no evidence in the repository of a long-term support branch.

The repository does carry test scaffolding. test/ exists, requirements-test.txt exists, and pyproject.toml configures pytest with base_url pointing at port 7860, while package.json defines lint and fix scripts running eslint. That is a reasonable signal that changes are expected to pass something, though the README does not describe what the test suite covers.

What to verify first, concretely: run webui.sh or webui-user.bat and confirm the dependency resolution completes against your torch build; check that your GPU vendor is one the Dependencies wiki covers; and confirm which extensions you need are maintained for this codebase rather than a fork. Those three checks decide the adoption question faster than any feature comparison.

Editorial conclusion

Adopt it if you want a local, scriptable Stable Diffusion front end with a large extension surface and you are willing to pin your own Python and PyTorch versions, because the last push to master was on 2025-02-09 and nothing in the repository promises a support window. Do not adopt it if you need a hosted service, a mobile client, or a project that ships frequent upstream fixes; the release history shows v1.10.0 in July 2024 and v1.10.1 in February 2025, and there is no published schedule for what comes next. Before committing, verify three things on your own hardware: that your GPU vendor path is one the wiki covers, that the Gradio and transformers versions pinned in requirements.txt resolve against your installed torch, and that the AGPL-3.0 obligations are acceptable for how you intend to distribute anything you build on top of it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes