Stable Diffusion WebUI in Docker: My Setup and the Errors I Hit

I wanted to generate images locally without turning my machine into a Python dependency mess. AUTOMATIC1111's WebUI normally installs into its own virtual environment with a pinned PyTorch, and that's exactly the kind of thing that breaks the next time you update something else. So I ran it in Docker using AbdBarho/stable-diffusion-webui-docker, which packages the popular UIs as Docker Compose profiles.

This post shows exactly what I ran in February 2025, what I got, and the three errors I had to fix along the way. If you hit one of those errors, skip straight to the troubleshooting section at the end.

What the project gives you

The repo has one Compose profile per UI, each with a GPU and a CPU variant:

Each profile is its own container, but they share the same data folder for models, so you only download a checkpoint once. Outputs go to output.

What you need

• An NVIDIA GPU with recent drivers. 8 GB of VRAM is a comfortable minimum for SD 1.5. You don't need to install CUDA on the host: the image is built on pytorch/pytorch:2.3.0-cuda12.1 and brings its own.
• On Linux: Docker Engine (not Docker Desktop, which doesn't pass NVIDIA GPUs through on Linux) plus the NVIDIA Container Toolkit. Without the toolkit you get the first error in the troubleshooting section.
• On Windows: Docker Desktop with the WSL 2 backend. GPU support goes through WSL 2.
• Git, and plenty of free disk space: the image, PyTorch and the model checkpoints add up to many gigabytes.

Installing and starting it

Copy git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.git
cd stable-diffusion-webui-docker

# one-off: download models
docker compose --profile download up --build

# start AUTOMATIC1111 (swap "auto" for auto-cpu, comfy or comfy-cpu)
docker compose --profile auto up --build

The first auto build pulls the PyTorch base image and clones the WebUI and its helper repos, so it takes a while. Rebuilds are mostly cached; mine finished in 28.5 seconds. The key lines from my run:

Copy $ docker compose --profile auto up --build
[+] Building 28.5s (27/27) FINISHED                              docker:default
 => [auto internal] load metadata for docker.io/pytorch/pytorch:2.3.0-cud  1.5s
 ...
 => => naming to docker.io/library/sd-auto:78                              0.0s
 ✔ Container webui-docker-auto-1  Recre...                                 0.1s
auto-1  | Calculating sha256 for /stable-diffusion-webui/models/Stable-diffusion/sd-v1-5-inpainting.ckpt: Running on local URL:  http://0.0.0.0:7860
auto-1  | Startup time: 3.9s (import torch: 1.6s, import gradio: 0.5s, setup paths: 0.6s, ...)
auto-1  | Loading weights [c6bbc15e32] from /stable-diffusion-webui/models/Stable-diffusion/sd-v1-5-inpainting.ckpt
auto-1  | Applying attention optimization: xformers... done.
auto-1  | Model loaded in 42.1s (calculate hash: 35.2s, load weights from disk: 1.3s, create model: 4.1s, ...)

Two things worth knowing from that log:

• The first model load is slow because of hashing, not loading. 35.2 of the 42.1 seconds was spent calculating the checkpoint's SHA-256. Actually reading the weights took 1.3 seconds. The hash is cached, so later starts are much faster.
• The UI is ready when you see Running on local URL: http://0.0.0.0:7860. Open http://localhost:7860 in your browser.

My first image

This is the WebUI as it first opened: AUTOMATIC1111 v1.9.4, Python 3.10.14, torch 2.3.0, xformers 0.0.26.post1.

I typed a deliberately simple prompt and changed a few settings from the defaults:

a black and white dog, 4k

And the result:

It honestly looks a lot like my dog Bryson.

Looking back at this run, I'd change two things:

• Use a regular checkpoint for text-to-image. The UI picked sd-v1-5-inpainting, which is meant for filling in parts of an existing image. It still produced a decent dog, but a standard SD 1.5 checkpoint, or an SDXL one, is the right tool for generating from scratch.
• Mind the resolution. SD 1.5 was trained at 512x512. Going straight to 1024x768 often gives duplicated subjects or stretched bodies. I got lucky here. Generating at 512 and then using Hires. fix to upscale is more reliable. And "4k" in the prompt nudges the style, not the output resolution.

The settings that matter most when you start experimenting:

• Prompt / negative prompt: what you want, and what you don't (I left the negative prompt empty here).
• Steps: more steps add detail, with diminishing returns. 20–40 is usually enough; my 69 was overkill.
• CFG scale: classifier-free guidance, meaning how strictly the image follows the prompt. 5–9 is typical; higher values get harsh.
• Seed: fix it to reproduce an image or to compare settings. Leave it at -1 for variety.

I go deeper into each of these in my Stable Diffusion parameter guide.

Every image is saved automatically under the output folder of the repo. If you also click Save, a copy goes to output/saved. The PNG keeps the full generation settings in its metadata, so you can drag it into the PNG Info tab later to recover the exact prompt and seed.

Troubleshooting

These are the three errors I hit, in the order I hit them.

Error response from daemon: could not select device driver "nvidia" with capabilities: [[gpu]]

Docker doesn't know how to give the container your GPU. On Linux, install the NVIDIA Container Toolkit and register it with Docker:

Copy curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Note that the package is nvidia-container-toolkit, not nvidia-cuda-toolkit. The latter is the CUDA compiler, won't fix this error, and is easy to install by mistake (an earlier version of this post had it wrong). Check it worked with:

Copy docker run --rm --gpus all ubuntu nvidia-smi

If that prints your GPU, the WebUI container will see it too.

ImportError: cannot import name 'TypeIs' from 'typing_extensions'

The full message was ImportError: cannot import name 'TypeIs' from 'typing_extensions' (/opt/conda/lib/python3.10/site-packages/typing_extensions.py). A dependency needs a newer typing_extensions than the one in the image. The fix, suggested by yasu-nxt in issue #719, is to pin a version that has TypeIs.

Open services/AUTOMATIC1111/Dockerfile and find the step that clones and installs the WebUI:

Copy RUN --mount=type=cache,target=/root/.cache/pip \
  git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git && \
  cd stable-diffusion-webui && \
  git reset --hard v1.9.4 && \
  pip install -r requirements_versions.txt

Add a new RUN step directly after it:

Copy RUN --mount=type=cache,target=/root/.cache/pip \
   pip uninstall -y typing_extensions && \
   pip install typing_extensions==4.11.0

Then rebuild with docker compose --profile auto up --build.

RuntimeError: CUDA error: unspecified launch failure

This one appeared mid-session, after the WebUI had been working:

Copy auto-1  |   File "/stable-diffusion-webui/modules/memmon.py", line 34, in cuda_mem_get_info
auto-1  |     return torch.cuda.mem_get_info(index)
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/torch/cuda/memory.py", line 655, in mem_get_info
auto-1  |     return torch.cuda.cudart().cudaMemGetInfo(device)
auto-1  | RuntimeError: CUDA error: unspecified launch failure
auto-1  | CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
auto-1  | For debugging consider passing CUDA_LAUNCH_BLOCKING=1.

Once this happens the GPU is in a bad state, and restarting the container isn't enough. What fixed it for me was rebooting the machine and then starting the WebUI again:

Copy docker compose --profile auto up --build

If it keeps coming back, it's usually a driver or hardware problem rather than the WebUI. Check sudo dmesg | grep -i xid for NVIDIA Xid errors after it happens. Updating the driver, or lowering the resolution or batch size to reduce GPU load, are the next things to try.

Was Docker worth it?

For me, yes. The WebUI's pinned PyTorch and xformers versions stay inside the container, the models live in one data folder I can reuse with ComfyUI, and starting over is one docker compose command. The cost is that you're one layer further from the code: the typing_extensions fix meant editing a Dockerfile instead of running a pip install.

If you want to go further from here, I used this same setup for creating celebrity look-alike images.