
# 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](https://github.com/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:

<Table data={{
  "headers": ["Profile", "UI", "Notes"],
  "rows": [
    ["download", "(none)", "Run once first. Downloads the base models into ./data"],
    ["auto", "AUTOMATIC1111 WebUI", "The classic form-based UI. This is what I used"],
    ["auto-cpu", "AUTOMATIC1111 WebUI", "No GPU needed, but very slow"],
    ["comfy", "ComfyUI", "Node-based workflows"],
    ["comfy-cpu", "ComfyUI", "No GPU needed, but very slow"]
  ]
}} />

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

```bash
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:

```bash
$ 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](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.

![AUTOMATIC1111 WebUI v1.9.4 txt2img tab with default settings](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/using-stable-diffusion-webui-docker-for-image-generation--a-newbies-guide/2025-02-05-14-28-16.png)

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

> a black and white dog, 4k

![The WebUI after generating a black and white dog with DPM++ SDE, 69 steps, CFG 12, seed 55](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/using-stable-diffusion-webui-docker-for-image-generation--a-newbies-guide/2025-02-05-14-31-52.png)

<Table data={{
  "headers": ["Setting", "Default", "What I used"],
  "rows": [
    ["Sampler", "DPM++ 2M", "DPM++ SDE (Karras schedule)"],
    ["Steps", "20", "69"],
    ["CFG scale", "7", "12"],
    ["Seed", "-1 (random)", "55"],
    ["Size", "512x512", "1024x768"],
    ["Checkpoint", "sd-v1-5-inpainting", "sd-v1-5-inpainting"]
  ]
}} />

And the result:

![A black and white dog generated by Stable Diffusion 1.5](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/using-stable-diffusion-webui-docker-for-image-generation--a-newbies-guide/00001-55.png)

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](/blog/2025/02-05-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](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html) and register it with Docker:

```bash
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:

```bash
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](https://github.com/AbdBarho/stable-diffusion-webui-docker/issues/719), is to pin a version that has `TypeIs`.

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

```Dockerfile
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:

```Dockerfile
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:

```bash
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:

```bash
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](/blog/2025/02-08-creating-celebrity-look-alike-images-with-stable-diffusion/).

<ContactFooter />


48d74ae273b7e4ad8c1d60b836787f669185b4c1f5a181b8137c82b2a2140beb

Run AUTOMATIC1111 Stable Diffusion WebUI in Docker step by step: install, first image with real settings, and fixes for the nvidia device driver, typing_extensions TypeIs and CUDA launch failure errors.

How I ran AUTOMATIC1111's Stable Diffusion WebUI in Docker with the stable-diffusion-webui-docker project: the exact commands, my first image, and fixes for the three errors that stopped me.

Tag: Webui

Tag: Webui

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