
# 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.

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


# Generate AI Images Locally with Python and diffusers: Stable Diffusion and Flux on Linux

**Short version:** on Linux with an NVIDIA GPU, you need a Python virtual environment, PyTorch with CUDA, and Hugging Face's `diffusers` library. Ten lines of Python then turn a prompt into a PNG. Start with a small model to prove the setup works. Big models like Flux.1-dev are a different story: about 34 GB to download and far more VRAM than a typical card has unless you offload to system RAM or use a quantised version.

When I first wrote this in January 2025, the small model ran fine on my machine and produced the pig further down. The Flux-based portrait model did not, because my GPU didn't have enough VRAM. This version keeps those results, fixes some mistakes in my original commands, and adds what actually gets Flux running on a 12 GB card.

If you'd rather use a web UI than write Python, see my [Stable Diffusion WebUI in Docker](/blog/2025/02-05-using-stable-diffusion-webui-docker-for-image-generation-a-newbies-guide/) post instead.

## What you need

<Table data={{
  "headers": ["Model", "Download (what diffusers needs)", "GPU memory", "Notes"],
  "rows": [
    ["OFA-Sys/small-stable-diffusion-v0", "About 4.4 GB (whole repo)", "Modest. Most NVIDIA cards with 4 GB or more", "Good first test. Quality is basic"],
    ["black-forest-labs/FLUX.1-dev", "About 34 GB (diffusers folders only)", "About 34 GB to keep everything on the GPU. A 24 GB card with CPU offload", "Gated. You must accept the licence on Hugging Face"],
    ["Shakker-Labs/AWPortrait-FL (LoRA file)", "0.6 GB, plus FLUX.1-dev", "Same as FLUX.1-dev", "Portrait fine-tune of Flux.1-dev"],
    ["Flux.1-dev NF4 in Forge (not diffusers)", "About 12 GB (one file)", "About 7 GB on my RTX 3060", "The practical route on a 12 GB card"]
  ]
}} />

Other things to have in place:

- **An NVIDIA GPU with a working driver.** `nvidia-smi` should list your card. On Ubuntu, `sudo ubuntu-drivers install` and a reboot usually sorts it out. AMD (ROCm) and Apple Silicon (`mps`) can work with diffusers too, but this guide only covers NVIDIA on Linux.
- **System RAM.** 16 GB is fine for the small model. For Flux with CPU offload, the parts that aren't on the GPU sit in system RAM, so 32 GB is a bare minimum and 64 GB is more comfortable.
- **Disk.** Fast SSD space for the sizes above, plus room for the Python packages (PyTorch with CUDA alone is several GB).

If you're deciding what hardware to buy for local AI, I cover RAM and VRAM in [Building Your Own AI Rig](/blog/2025/03/03-building-your-own-ai-rig-more-memory-more-power/).

## Step 1: Python environment and packages

On Ubuntu or Debian:

```bash
sudo apt install python3 python3-venv python3-pip git

python3 -m venv ~/ai-env
source ~/ai-env/bin/activate

pip install --upgrade pip
pip install torch
pip install diffusers transformers accelerate sentencepiece protobuf peft
pip install -U huggingface_hub
```

Notes on the packages:

- **`torch`**: on Linux, the default PyTorch wheel from pip includes CUDA support. You don't need to install the CUDA toolkit separately, only the NVIDIA driver. You don't need `torchvision` or `torchaudio` for this. For very new GPUs, use the install command from the selector on pytorch.org so you get a CUDA build that supports your card.
- **`accelerate`**: needed for the CPU offload functions used with Flux.
- **`sentencepiece`** and **`protobuf`**: needed by the T5 text encoder that Flux uses.
- **`peft`**: needed for `load_lora_weights()`. My original version of this post left it out, and without it diffusers refuses to load a LoRA.

Check that PyTorch can see the GPU before you download anything big:

```bash
python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"
```

If that prints `False`, fix the driver first. Nothing below will work until it prints `True`.

## Step 2: download models

You have two options.

**Option A: let diffusers download on first use.** Pass the repo ID (for example `"OFA-Sys/small-stable-diffusion-v0"`) to `from_pretrained()` and it downloads into `~/.cache/huggingface/hub`. Set `HF_HOME` if you want that cache on a bigger disk.

**Option B: download into a folder you choose.** This is what I prefer, because you can see exactly what's on disk:

```bash
mkdir -p ~/ai-models && cd ~/ai-models

hf download OFA-Sys/small-stable-diffusion-v0 --local-dir OFA-Sys/small-stable-diffusion-v0
```

`hf` is the Hugging Face CLI that comes with `huggingface_hub`. Older versions call it `huggingface-cli`, with the same `download` and `login` commands. If a download drops out, run the same command again and it carries on from where it stopped. That matters when you're pulling tens of gigabytes over a typical Australian home connection.

An earlier version of this post used `git-lfs clone`. That command is deprecated in Git LFS, and cloning with git also pulls every file in the repo, which for Flux means files you don't need (next section).

### Flux.1-dev is gated

Before you can download it:

1. Sign in at huggingface.co (create an account at [huggingface.co/join](https://huggingface.co/join) if needed).
2. Open [black-forest-labs/FLUX.1-dev](https://huggingface.co/black-forest-labs/FLUX.1-dev) and accept the licence.
3. Create an access token at [huggingface.co/settings/tokens](https://huggingface.co/settings/tokens). A read token is enough.
4. Log in on your machine and paste the token when asked:

```bash
hf auth login        # older versions: huggingface-cli login
```

Then download only what diffusers needs:

```bash
cd ~/ai-models

# skip the 23.8 GB single-file checkpoint; diffusers uses the transformer/ folder instead
hf download black-forest-labs/FLUX.1-dev --local-dir black-forest-labs/FLUX.1-dev \
  --exclude "flux1-dev.safetensors" "dev_grid.jpg"

# only the LoRA file from AWPortrait-FL
hf download Shakker-Labs/AWPortrait-FL AWPortrait-FL-lora.safetensors \
  --local-dir Shakker-Labs/AWPortrait-FL
```

This is the biggest correction to my original post. The FLUX.1-dev repo holds the model twice: once as a single 23.8 GB `flux1-dev.safetensors` (for UIs like ComfyUI and Forge) and once split into diffusers folders. Cloning everything is about 58 GB. The AWPortrait-FL repo is similar: a full fine-tuned copy of Flux in diffusers format, a 23.8 GB single file, an 11.9 GB fp8 file and the 0.6 GB LoRA, about 70 GB in total. With the LoRA approach used below, you need the FLUX.1-dev folders and one 0.6 GB file, not both repos in full.

## Step 3: a first image with the small model

Save this as `test-small-sd.py`:

```python
import torch
from diffusers import StableDiffusionPipeline

# local folder from Step 2, or the repo ID "OFA-Sys/small-stable-diffusion-v0"
model_path = "/home/YOUR_USER/ai-models/OFA-Sys/small-stable-diffusion-v0"

pipe = StableDiffusionPipeline.from_pretrained(model_path, torch_dtype=torch.float16)
pipe = pipe.to("cuda")

prompt = "a pig, 4k"
image = pipe(prompt).images[0]
image.save("pig.png")
```

Run it:

```bash
python test-small-sd.py
```

This is what I got from `a pig, 4k`:

![A 512 by 512 image of a smooth pink pig figure generated by small-stable-diffusion-v0 from the prompt "a pig, 4k"](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/how-to-generate-images-with-ai-models-on-your-own-computer/pig.png)

It's 512 by 512, the default size for this model. It's recognisably a pig, but it looks more like a rubber toy than an animal. That's what you get from a small, distilled model and a two-word prompt. It's useful for proving the setup works, not for real work.

Things to try next in the same script:

- A more descriptive prompt (subject, setting, lighting, style).
- `num_inference_steps=30` and `guidance_scale=7.5` as arguments to `pipe(...)`. My [Stable Diffusion settings guide](/blog/2025/02-05-stable-diffusion-parameter-guide/) explains what these do.
- `generator=torch.Generator("cuda").manual_seed(42)` to get the same image each time you run it, so you can compare settings fairly.

## Step 4: Flux.1-dev with the AWPortrait-FL LoRA

[AWPortrait-FL](https://huggingface.co/Shakker-Labs/AWPortrait-FL) is a portrait fine-tune of Flux.1-dev. Here's the model author's sample sheet from its model card:

![AWPortrait-FL model card showing the author's sample portraits](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/how-to-generate-images-with-ai-models-on-your-own-computer/2025-01-31-14-39-00.png)

These are the author's images, not mine. When I first tried this model, it wouldn't run on my computer because the GPU didn't have enough VRAM. That was predictable. The script I used came from the model card and moved the whole pipeline to the GPU with `pipe.to("cuda")`. In bf16, the Flux transformer alone is about 24 GB and the T5 text encoder another 9.5 GB, so that line needs roughly 34 GB of VRAM before you generate anything. Even a 24 GB RTX 3090 or 4090 can't do it that way.

The fix is CPU offload. Save this as `test-awportrait-fl.py`:

```python
import torch
from diffusers import FluxPipeline

base = "/home/YOUR_USER/ai-models/black-forest-labs/FLUX.1-dev"
lora_dir = "/home/YOUR_USER/ai-models/Shakker-Labs/AWPortrait-FL"

pipe = FluxPipeline.from_pretrained(base, torch_dtype=torch.bfloat16)
pipe.load_lora_weights(lora_dir, weight_name="AWPortrait-FL-lora.safetensors")
pipe.fuse_lora(lora_scale=0.9)

# instead of pipe.to("cuda"): keep each part in system RAM and move it
# to the GPU only while it's in use
pipe.enable_model_cpu_offload()
# on cards with less than 24 GB, use this instead (much slower):
# pipe.enable_sequential_cpu_offload()

prompt = (
    "close up portrait, a soft spotlight in a photography studio, "
    "a model in a sleek black turtleneck, understated makeup, "
    "pale gray textured backdrop, black, gray and skin tones"
)

image = pipe(
    prompt,
    num_inference_steps=24,
    guidance_scale=3.5,
    width=768,
    height=1024,
).images[0]
image.save("portrait.png")
```

The steps, guidance and size are the model card's values. A few notes:

- **`enable_model_cpu_offload()`** moves whole components (text encoders, transformer, VAE) on and off the GPU in turn. Peak VRAM is then roughly the size of the largest component, the 24 GB transformer, which is why this suits 24 GB cards.
- **`enable_sequential_cpu_offload()`** moves smaller pieces at a time. It fits in much less VRAM but is very slow, and it needs plenty of system RAM.
- **`guidance_scale` here is not classic CFG.** Flux.1-dev is guidance-distilled, so 3.5 is a normal value. Don't copy SD 1.5 values like 7 to 12.
- **Licence:** FLUX.1-dev uses a non-commercial licence, and the AWPortrait-FL model card says images generated with it are non-commercial too. Read both before using the output for business.

## The practical route on a 12 GB card: a quantised Flux in a UI

These days my image box is an RTX 3060 with 12 GB of VRAM and 64 GB of RAM. I don't run the bf16 diffusers pipeline on it. It runs [SD WebUI Forge](https://github.com/lllyasviel/stable-diffusion-webui-forge) with `flux1-dev-bnb-nf4-v2`, a 4-bit Flux.1-dev checkpoint with the text encoders and VAE built in. That uses about 7 GB of VRAM, and a 1344 by 768 image at 30 steps takes a minute or two. The AWPortrait-FL fp8 file (11.9 GB) is also one of the checkpoints on that box.

Two things I learned running it:

- **Very short prompts can come out as pure noise** (a flat green or yellow field) with the NF4 checkpoint. Detailed prompts of 40 words or more render fine. If you get noise, lengthen the prompt rather than retrying seeds.
- **Flux and a local LLM can't share a 12 GB card.** If Ollama has a model loaded, stop it before generating images, and stop the image UI before going back to the LLM. `nvidia-smi` shows who is holding the VRAM.

If you want to stay in Python, diffusers can also load quantised Flux (bitsandbytes NF4 or GGUF). Check the quantisation section of the diffusers docs, as the exact API has changed between versions.

## Common errors and fixes

<Table data={{
  "headers": ["Error or symptom", "Likely cause", "Fix"],
  "rows": [
    ["torch.OutOfMemoryError: CUDA out of memory", "The model plus working memory doesn't fit in VRAM, or another program is using the GPU", "Check nvidia-smi for other processes (Ollama, a web UI). Use enable_model_cpu_offload() or enable_sequential_cpu_offload(). Lower width and height. Try pipe.vae.enable_tiling() for large images"],
    ["torch.cuda.is_available() is False", "No working NVIDIA driver, or a CPU-only PyTorch build", "Run nvidia-smi. Fix the driver, then reinstall torch in the venv"],
    ["401 or 'gated repo' error for FLUX.1-dev", "Licence not accepted, or not logged in", "Accept the licence on the model page, then hf auth login"],
    ["'PEFT backend is required' on load_lora_weights", "peft isn't installed", "pip install peft"],
    ["The image is completely black", "The Stable Diffusion safety checker flagged it (it logs a 'Potential NSFW content' warning)", "Change the prompt or seed. False positives are common with small models"],
    ["Python is 'Killed' while loading Flux", "System RAM ran out, and Linux killed the process", "Close other programs, add RAM or swap, or use a quantised model"],
    ["Download stops part-way", "Network drop", "Run the same hf download command again. It resumes"]
  ]
}} />

An earlier version of this post said that lowering the guidance scale helps with out-of-memory errors. It doesn't in any useful way. Memory use depends on the model size, the image size and the batch size. Offloading, quantisation and smaller images are what help.

## Where to find other models

- **[Hugging Face](https://huggingface.co/models?pipeline_tag=text-to-image&library=diffusers)**: filter by text-to-image and the diffusers library to get models that load with the scripts above.
- **[Civitai](https://civitai.com)**: a big community library of checkpoints and LoRAs, mostly as single `.safetensors` files aimed at UIs like AUTOMATIC1111, Forge and ComfyUI. Diffusers can load many of them with `from_single_file()`, but a UI is usually easier.

Check each model's licence, and prefer `.safetensors` files over `.ckpt` or `.bin`. The older formats use Python pickle, which can run code when you load the file.

## Related posts

- [Stable Diffusion WebUI in Docker](/blog/2025/02-05-using-stable-diffusion-webui-docker-for-image-generation-a-newbies-guide/): the same idea with a web UI, and the errors I hit setting it up.
- [Realistic portraits in Stable Diffusion 1.5](/blog/2025/02-06-mastering-human-portraits-with-stable-diffusion-ai/): prompts and settings for faces.
- [Blending two famous faces in Stable Diffusion](/blog/2025/02-08-creating-celebrity-look-alike-images-with-stable-diffusion/): prompt editing and weights with real settings.
- [Install Ollama on Ubuntu or Debian](/blog/2025/01-23-running-ai-on-your-own-computer-with-ollama/): the same "run it on your own machine" approach for text models.

<ContactFooter />


4e5af276b2473fcd7ef84402e1d2859deb4a692fdb0a30d5989d3262422980c9

Run Stable Diffusion and Flux.1-dev locally with Python diffusers on Linux: setup, download sizes, VRAM needs, working scripts and CUDA out of memory fixes.

A minimal Python setup for text-to-image on your own Linux machine with Hugging Face diffusers: a small Stable Diffusion model that runs on almost any NVIDIA card, then Flux.1-dev with the AWPortrait-FL LoRA, how much VRAM and disk each needs, and fixes for the errors you'll hit.

Tag: Stable-diffusion

Tag: Stable-diffusion

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

Generate AI Images Locally with Python and diffusers: Stable Diffusion and Flux on Linux