{/* banner prompt: Of course! Based on the blog post's core theme of Docker resolving the chaotic and frustrating .NET build hangs on Linux, here are three creative and engaging prompts for a 16:9 banner image.

---

### Prompt Option 1 (The Sanctuary)

**Prompt:**
A digital art illustration in a cinematic, futuristic style. In the chaotic background, a storm of tangled red wires, glitching code snippets, and faint error messages like `GLIBC_2.38` swirls around a distressed Linux penguin (Tux). In the foreground, a glowing, translucent blue Docker container acts as a perfect shield. Inside the container, the .NET logo is pristine and a set of gears are turning smoothly, representing a successful build. The scene is illuminated by the calm, cool light from the Docker container, pushing back the chaotic red darkness. Aspect ratio 16:9.

**Why it works:** This prompt visually captures the central conflict: the "dependency hell" of Linux (chaos, errors, frustration) versus the clean, isolated, and reliable environment provided by Docker (the sanctuary).

---

### Prompt Option 2 (The Assembly Line)

**Prompt:**
A dynamic vector illustration showing a transformation from left to right. On the left, the .NET logo is stuck in a complex, rusty, and jammed machine made of mismatched parts, with a progress bar frozen at 99%. A frustrated Linux penguin is looking at it with a wrench. On the right, the iconic Docker whale is calmly overseeing a sleek, modern, and efficient assembly line made of Docker containers. This assembly line is smoothly processing the .NET logo, which emerges on the far right as a polished, glowing, and complete application icon. The entire image has a clean, tech-focused aesthetic. Aspect ratio 16:9.

**Why it works:** This prompt visualizes the blog post's narrative of a broken process being fixed. It directly contrasts the "build hang" (jammed machine) with the "reproducible build" (streamlined assembly line), highlighting Docker's role as a workflow optimizer.

---

### Prompt Option 3 (The Breakthrough)

**Prompt:**
Conceptual digital art with dramatic lighting. The .NET logo is depicted as being trapped and frozen inside a complex, dark labyrinth made of glitching, fragmented code representing the Linux environment. A powerful and luminous Docker whale is breaking through the walls of the labyrinth, shattering the digital "ice" and untangling the code with streams of clean, blue data. The breakthrough creates a wave of light that illuminates the path forward. The scene conveys a powerful sense of resolution and freedom from a persistent problem. Aspect ratio 16:9.

**Why it works:** This prompt is more metaphorical and heroic. It portrays the build hang as a formidable obstacle (a labyrinth) and Docker as the powerful solution that provides a "breakthrough," which directly reflects the feeling of solving a long-standing, frustrating technical issue. */}

Microsoft's transformation from a proprietary software giant to an open-source advocate has been remarkable. The release of .NET Core for Linux marked a pivotal moment in cross-platform development. However, despite this progress, developers working with .NET on Linux have encountered persistent challenges that can significantly impact productivity.

## The Promise and Reality of .NET on Linux

When Microsoft announced .NET Core's availability on Linux, it opened doors for developers who had been yearning to use their favorite .NET technologies outside the Windows ecosystem. The framework itself is remarkably solid – applications run smoothly, performance is excellent, and the development experience is largely seamless.

But there's a catch that many developers have discovered the hard way: the build process.

## The Persistent Build Hang Problem

The `dotnet build` command on Linux has a notorious reputation for hanging unexpectedly. This isn't a minor inconvenience – it's a productivity killer that affects development workflows across teams and projects.

### Characteristics of the Problem

The hanging behavior exhibits several frustrating patterns:

- **Unpredictable occurrence**: It works perfectly on one machine but fails consistently on another with seemingly identical configurations
- **Intermittent failures**: The build might succeed several times, then suddenly hang without any code changes
- **Repository dependency**: Sometimes checking out a fresh clone of the same repository resolves the issue temporarily
- **No clear error messages**: The process simply stops responding, providing no actionable feedback

### The Library Dependency Nightmare

The build process is only half the battle. A common scenario unfolds like this: you successfully build your .NET application on your development machine (e.g., running the latest Ubuntu), and everything looks great. You then deploy the compiled artifacts to a production server, which might be running an older but more stable distribution like Debian or CentOS.

When you try to run the application on the target machine, it crashes with errors like these:

```bash
Nov 12 10:47:53 workstation run.sh[290219]: ./[YOUR_APP]: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./[YOUR_APP])
Nov 12 10:47:53 workstation run.sh[290219]: ./[YOUR_APP]: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./[YOUR_APP])
```

These errors indicate version mismatches between the system's installed libraries and what the .NET runtime expects – a classic Linux dependency hell scenario.

## Why These Issues Persist

A simple Google search for "dotnet build linux hung" reveals the scope of this problem. Results span back at least four years, with countless developers reporting similar experiences across different Linux distributions, .NET versions, and hardware configurations.

The persistence of these issues a couple of underlying factors. The .NET build system performs numerous operations under the hood – package restoration, compilation, linking, and asset generation. Any step in this pipeline can encounter environment-specific issues that cause hanging. Also Linux systems handle process scheduling and resource allocation differently than Windows. The .NET build process might encounter unexpected contention or deadlock scenarios specific to Linux environments. The exact root cause remains elusive. Despite numerous bug reports and community discussions, a definitive, universal solution from the Microsoft .NET team has not materialized. The problem's intermittent and environment-specific nature makes it incredibly difficult to diagnose. Rather than getting stuck trying to solve a mystery that has stumped even the core development team, this guide focuses on a pragmatic and reliable workaround that bypasses the problem entirely.

## Docker as the Solution

While the root causes remain complex, Docker provides a practical workaround that many development teams have adopted successfully.

### Why Docker Works

Docker containers offer several advantages for .NET builds on Linux:

**Consistent Environment**: Every build runs in an identical, controlled environment regardless of the host system's configuration.

**Isolated Dependencies**: Container images include all necessary runtime dependencies at known versions, eliminating library mismatch issues.

**Reproducible Builds**: The same container image produces identical results across different machines and CI/CD environments.

### Setting Up Dockerized .NET Builds

Here's a practical implementation for containerizing your .NET builds:

#### Basic Dockerfile

```dockerfile
# Simple single-stage Dockerfile for building [YOUR_APP] on Ubuntu 22.04
FROM ubuntu:22.04

# Prevent interactive prompts
ENV DEBIAN_FRONTEND=noninteractive

# Install .NET SDK 8.0 for Ubuntu 22.04
RUN apt-get update && apt-get install -y wget ca-certificates \
    && wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb \
    && dpkg -i packages-microsoft-prod.deb \
    && rm packages-microsoft-prod.deb \
    && apt-get update \
    && apt-get install -y dotnet-sdk-8.0 \
    && rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Configure environment
ENV DOTNET_CLI_TELEMETRY_OPTOUT=1 \
    DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1 \
    MSBUILDDISABLENODEREUSE=1

# Copy all project files
COPY . .

# Fix NuGet.Config
RUN printf '%s\n' \
    '<?xml version="1.0" encoding="utf-8"?>' \
    '<configuration>' \
    '  <packageSources>' \
    '    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />' \
    '  </packageSources>' \
    '</configuration>' > NuGet.Config

# Remove global.json to allow any .NET 8 SDK
RUN rm -f global.json

# Restore, build, and publish with runtime identifier
RUN echo "=== RESTORE (with RID) ===" \
    && dotnet restore [YOUR_APP].csproj -r linux-x64 2>&1 | tee restore.log \
    && echo "=== BUILD ===" \
    && dotnet build [YOUR_APP].csproj -c Release --no-restore -r linux-x64 2>&1 | tee build.log \
    && echo "=== PUBLISH ===" \
    && dotnet publish [YOUR_APP].csproj -c Release --no-restore --no-build \
       -o /app/publish \
       -r linux-x64 \
       --self-contained false \
       2>&1 | tee publish.log \
    && echo "=== BUILD COMPLETE ===" \
    && ls -lh /app/publish/

# Set entrypoint
WORKDIR /app/publish
CMD ["/bin/bash"]

```

Remember to replace [YOUR_APP] in the above Dockerfile to your actual project name.


#### Build Script

Create a shell script to streamline the Docker build process:

```bash
#!/bin/bash
#
# Simple Docker build script with better error handling
#

set -e

PROJECT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
cd "$PROJECT_DIR"

echo "=========================================="
echo "Building [YOUR_APP] in Docker "
echo "Target: Ubuntu 22.04"
echo "=========================================="
echo

# Configuration
IMAGE_NAME="[YOUR_APP]-docker"
CONTAINER_NAME="[YOUR_APP]-extract"
OUTPUT_DIR="./bin/Release/net8.0/publish"

# Clean up
echo "Cleaning up previous containers..."
docker rm -f "$CONTAINER_NAME" 2>/dev/null || true

# Build the Docker image
echo
echo "Building Docker image..."
if ! docker build -f Dockerfile -t "$IMAGE_NAME:latest" . 2>&1 | tee docker-build.log; then
    echo
    echo "=========================================="
    echo "BUILD FAILED!"
    echo "Check docker-build.log for details"
    echo "=========================================="
    exit 1
fi

echo
echo "Creating container to extract build..."
docker create --name "$CONTAINER_NAME" "$IMAGE_NAME:latest"

# Create output directory
mkdir -p "$OUTPUT_DIR"

# Copy published files
echo "Extracting build artifacts..."
if docker cp "$CONTAINER_NAME:/app/publish/." "$OUTPUT_DIR/"; then
    echo "Build artifacts extracted successfully"
else
    echo "Warning: Could not extract all artifacts, checking what\'s available..."
    docker run --rm "$IMAGE_NAME:latest" ls -la /app/publish/ || true
fi

# Clean up container
docker rm "$CONTAINER_NAME"

echo
echo "=========================================="
echo "Build process completed!"
echo "=========================================="
echo
if [ -d "$OUTPUT_DIR" ] && [ "$(ls -A $OUTPUT_DIR)" ]; then
    echo "Output directory: $OUTPUT_DIR"
    echo "Files:"
    ls -lh "$OUTPUT_DIR" | head -20
    echo
    echo "Binary file check:"
    file "$OUTPUT_DIR/[YOUR_APP]" 2>/dev/null || echo "[YOUR_APP] binary not found"
    echo
    echo "To test on target workstation:"
    echo "  scp -r $OUTPUT_DIR/* workstation:/apps/[YOUR_APP]/current/"
else
    echo "ERROR: No files in output directory!"
    echo "Check docker-build.log for errors"
    exit 1
fi

```

Again, remember to replace [YOUR_APP] in the above Dockerfile to your actual app name.

{/* ```bash
#!/bin/bash
# build.sh

set -e

echo "Starting Docker build..."

docker build -t your-app:latest .

echo "Extracting build artifacts..."

# Create output directory
mkdir -p ./dist

# Copy build output from container
docker create --name temp-container your-app:latest
docker cp temp-container:/app/publish ./dist/
docker rm temp-container

echo "Build completed successfully!"
```

#### Docker Compose for Development

For more complex scenarios, use Docker Compose:

```yaml
version: '3.8'

services:
  build:
    build: .
    volumes:
      - ./dist:/app/publish
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    
  runtime:
    image: mcr.microsoft.com/dotnet/aspnet:8.0
    ports:
      - "5000:80"
    volumes:
      - ./dist:/app
    working_dir: /app
    command: dotnet YourProject.dll
    depends_on:
      - build
```

## Implementation Best Practices

### 1. **Multi-Stage Builds**

Use multi-stage Docker builds to optimize image size and build performance:

```dockerfile
# Build stage
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o out

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /src/out .
ENTRYPOINT ["dotnet", "YourProject.dll"]
```

### 2. **Layer Optimization**

Structure your Dockerfile to maximize Docker layer caching:

```dockerfile
# Copy and restore dependencies first (changes less frequently)
COPY *.csproj ./
RUN dotnet restore

# Copy source code (changes more frequently)
COPY . .
RUN dotnet build
```

### 3. **Build Arguments for Flexibility**

Use build arguments to customize builds for different environments:

```dockerfile
ARG BUILD_CONFIGURATION=Release
ARG DOTNET_VERSION=8.0

FROM mcr.microsoft.com/dotnet/sdk:${DOTNET_VERSION} AS build
RUN dotnet build -c ${BUILD_CONFIGURATION}
```

## Measuring the Impact

Teams implementing Docker-based builds typically report:

- **Eliminated hanging**: Complete resolution of build hang issues
- **Improved consistency**: Identical builds across development, staging, and production environments
- **Reduced debugging time**: Less time spent troubleshooting environment-specific issues
- **Better CI/CD reliability**: More predictable automated build processes

## Potential Drawbacks and Considerations

While Docker solves the immediate problems, it introduces some complexity:

### **Increased Resource Usage**

Docker containers consume additional memory and disk space. Ensure your development machines have adequate resources.

### **Learning Curve**

Team members unfamiliar with Docker need time to adapt to containerized workflows.

### **Build Time Overhead**

Initial Docker builds can be slower than native builds, though layer caching mitigates this over time.

### **Debugging Challenges**

Debugging applications running inside containers requires additional setup and tooling.

## Alternative Approaches

Before committing to Docker, consider these alternatives:

### **Using Different .NET Versions**

Sometimes switching between LTS and current .NET versions resolves hanging issues:

```bash
# Try different SDK versions
sudo apt install dotnet-sdk-6.0
sudo apt install dotnet-sdk-7.0
```

### **Environment Variables**

Some developers report success with specific environment settings:

```bash
export DOTNET_CLI_TELEMETRY_OPTOUT=1
export DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
export NUGET_XMLDOC_MODE=skip
```

### **Build Isolation**

Running builds in isolated directories or using different user accounts sometimes helps:

```bash
# Build in temporary directory
mkdir /tmp/build-$(date +%s)
cd /tmp/build-$(date +%s)
git clone your-repo.git
cd your-repo
dotnet build
``` */}

## Looking Forward

The .NET build hanging issue on Linux remains an active concern in the .NET community. Microsoft continues working on improvements, but the complexity of supporting diverse Linux environments means progress is incremental.

Docker provides a pragmatic solution that works today. While it adds complexity to your development workflow, the trade-off between operational overhead and build reliability often favors containerization.

As the .NET ecosystem matures on Linux, we can expect better native support and fewer environment-specific issues. Until then, Docker remains a reliable path forward for teams serious about .NET development on Linux.

## Conclusion

Microsoft's embrace of open source and cross-platform development has created exciting opportunities for .NET developers. However, the reality of cross-platform development includes challenges that require practical solutions.

The persistent build hanging issues on Linux demonstrate that even mature frameworks can struggle with platform-specific complexities. Docker offers a proven workaround that many teams have adopted successfully, trading some additional complexity for significantly improved reliability.

Whether this Docker-based approach will remain necessary long-term remains to be seen. For now, it provides a stable foundation for .NET development on Linux, allowing teams to focus on building great applications rather than fighting build system issues.

If you're experiencing similar challenges with .NET builds on Linux, consider implementing a Docker-based workflow. While it may seem like overkill initially, the improved consistency and reliability often justify the additional setup complexity.

---

Do you have similar experience? Share your comments below.

320e7b744ccc39f7c0ff72a382e896737ceb0b5cd8969c9b0974d2ae0fff33f0

Comprehensive guide to resolving .NET Core build hangs and library dependency errors on Linux using Docker containerization for consistent builds.

Learn how Docker containers solve persistent .NET build hanging issues on Linux distributions.

Solving the .NET Build Hang on Linux with Docker



# Using Stable Diffusion WebUI Docker for Image Generation – A Newbie's Guide 

## Introduction  

Stable Diffusion is a powerful open-source AI model designed to generate high-quality images from text prompts. However, setting up a local environment with different UI options can be complex. **Stable Diffusion WebUI Docker** simplifies this process by offering a containerized solution that integrates multiple user interfaces for seamless image generation.

While it’s possible to generate images directly via the command line, this method is less intuitive and requires technical expertise. To make Stable Diffusion more accessible, various user interfaces (UIs) for stable diffusion have been developed, providing a more user-friendly experience.

**Stable Diffusion WebUI Docker** brings these UIs together in a single container, making installation and usage more convenient. This article will guide you through installing, configuring, and using Stable Diffusion WebUI Docker to streamline your image generation workflow.

## How UIs Work with Stable Diffusion

A UI acts as a frontend that communicates with Stable Diffusion's backend model. The backend performs image generation using deep learning, while the UI provides an easy way to input text prompts, adjust settings, and view results.

### Popular Stable Diffusion UIs


{/** create a table with the information below
 * 
 UI Name	Features	Best For
Automatic1111 WebUI	Most popular, extensive features, customizable	Advanced users, power users, deep customization
InvokeAI	Simplified UI, lightweight, workflow-oriented	Artists, beginners, streamlined workflow
ComfyUI	Node-based system for modular control	Developers, advanced workflow automation
Fooocus	Automatic settings optimization, user-friendly	Beginners, quick high-quality results
StableSwarmUI	Multi-user support, collaborative workflows	Teams, cloud-based solution

 * ***/}

 <Table data={
    {
        headers: ["UI Name", "Features", "Best For"],
        rows: [
            ["Automatic1111 WebUI", "Most popular, extensive features, customizable", "Advanced users, power users, deep customization"],
            ["InvokeAI", "Simplified UI, lightweight, workflow-oriented", "Artists, beginners, streamlined workflow"],
            ["ComfyUI", "Node-based system for modular control", "Developers, advanced workflow automation"],
            ["Fooocus", "Automatic settings optimization, user-friendly", "Beginners, quick high-quality results"],
            ["StableSwarmUI", "Multi-user support, collaborative workflows", "Teams, cloud-based solution"],
        ]
    }
 } />

\
&nbsp;
 Each UI provides different levels of control, automation, and accessibility depending on the user's needs.

## Prerequisites  

Now it is time to get started. Before you can use Stable Diffusion WebUI Docker, you will need to install Docker, set up a Docker environment and install other necessary dependencies.

If you are on Windows, ensure you have the following:  
- **Docker Desktop** (Check [Docker Desktop Installation Guide](https://docs.docker.com/docker-for-windows/install/))  
- **NVIDIA drivers & CUDA (for GPU acceleration)**  
- **At least 8GB VRAM (Recommended)**  
- **Basic familiarity with Docker commands**  
- **Git installed** (Check [Git Installation Guide](https://git-scm.com/download/win))

If you are on Linux, ensure you have the following:

- **Docker installed** (Check [Docker Installation Guide](https://docs.docker.com/desktop/setup/install/linux/))  
- **NVIDIA drivers & CUDA (for GPU acceleration)**  
- **At least 8GB VRAM (Recommended)**  
- **Basic familiarity with Docker commands**  
- **Git installed** (Use the system package manager to install Git, for example, `sudo apt install git`)

## Installation 

Open a command prompt (`cmd` on Windows, `Terminal` on Linux) and navigate to the directory where you want to clone the repository. If you are on Windows, use `cd` to navigate, for example, `cd C:\Users\yourname\ai`. If you are on Linux, use `cd` to navigate, for example, `cd /home/yourname/ai`.

To get started, clone the repository and build the Docker container:  

```bash
git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.git
docker compose --profile download up --build
# then
docker compose --profile auto up --build
# you can replace `auto` with `auto-cpu`, `comfy`, or `comfy-cpu`
```

When it is done, you should see something like the following message:
```bash
$ docker compose --profile auto up --build
[+] Building 28.5s (27/27) FINISHED                              docker:default
 => [auto internal] load build definition from Dockerfile                  0.0s
 => => transferring dockerfile: 3.09kB                                     0.0s
 => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (li  0.0s
 => [auto internal] load metadata for docker.io/pytorch/pytorch:2.3.0-cud  1.5s
 => [auto internal] load metadata for docker.io/alpine/git:2.36.2          1.5s
 => [auto internal] load .dockerignore                                     0.0s
 => => transferring context: 2B                                            0.0s
 => [auto internal] load build context                                     0.0s
 => => transferring context: 3.18kB                                        0.0s
 => [auto download 1/9] FROM docker.io/alpine/git:2.36.2@sha256:ec491c893  0.0s
 => [auto stage-1  1/12] FROM docker.io/pytorch/pytorch:2.3.0-cuda12.1-cu  0.0s
 => CACHED [auto stage-1  2/12] RUN --mount=type=cache,target=/var/cache/  0.0s
 => CACHED [auto stage-1  3/12] RUN --mount=type=cache,target=/root/.cach  0.0s
 => [auto stage-1  4/12] RUN --mount=type=cache,target=/root/.cache/pip    1.8s
 => CACHED [auto download 2/9] COPY clone.sh /clone.sh                     0.0s
 => CACHED [auto download 3/9] RUN . /clone.sh stable-diffusion-webui-ass  0.0s
 => CACHED [auto download 4/9] RUN . /clone.sh stable-diffusion-stability  0.0s
 => CACHED [auto download 5/9] RUN . /clone.sh BLIP https://github.com/sa  0.0s
 => CACHED [auto download 6/9] RUN . /clone.sh k-diffusion https://github  0.0s
 => CACHED [auto download 7/9] RUN . /clone.sh clip-interrogator https://  0.0s
 => CACHED [auto download 8/9] RUN . /clone.sh generative-models https://  0.0s
 => CACHED [auto download 9/9] RUN . /clone.sh stable-diffusion-webui-ass  0.0s
 => [auto stage-1  5/12] COPY --from=download /repositories/ /stable-diff  0.1s
 => [auto stage-1  6/12] RUN mkdir /stable-diffusion-webui/interrogate &&  0.1s
 => [auto stage-1  7/12] RUN --mount=type=cache,target=/root/.cache/pip   19.4s
 => [auto stage-1  8/12] RUN apt-get -y install libgoogle-perftools-dev &  4.3s
 => [auto stage-1  9/12] COPY . /docker                                    0.0s
 => [auto stage-1 10/12] RUN   sed -i 's/in_app_dir = .*/in_app_dir = Tru  0.1s
 => [auto stage-1 11/12] WORKDIR /stable-diffusion-webui                   0.1s
 => [auto] exporting to image                                              0.9s
 => => exporting layers                                                    0.9s
 => => writing image sha256:9fb2e1b4b8fd548ed75dd3bc9834470e0836c986a97e9  0.0s
 => => naming to docker.io/library/sd-auto:78                              0.0s
 => [auto] resolving provenance for metadata file                          0.0s
[+] Running 2/2
 ✔ auto                           Built                                    0.0s 
 ✔ Container webui-docker-auto-1  Recre...                                 0.1s 
Attaching to auto-1
auto-1  | /stable-diffusion-webui
auto-1  | total 772K
auto-1  | drwxr-xr-x  1 root root 4.0K Feb  5 01:44 .
auto-1  | drwxr-xr-x  1 root root 4.0K Feb  5 01:44 ..
auto-1  | -rw-r--r--  1 root root   48 Feb  5 01:27 .eslintignore
auto-1  | -rw-r--r--  1 root root 3.4K Feb  5 01:27 .eslintrc.js
auto-1  | drwxr-xr-x  8 root root 4.0K Feb  5 01:27 .git
auto-1  | -rw-r--r--  1 root root   55 Feb  5 01:27 .git-blame-ignore-revs
auto-1  | drwxr-xr-x  4 root root 4.0K Feb  5 01:27 .github
auto-1  | -rw-r--r--  1 root root  521 Feb  5 01:27 .gitignore
auto-1  | -rw-r--r--  1 root root  119 Feb  5 01:27 .pylintrc
auto-1  | -rw-r--r--  1 root root  84K Feb  5 01:27 CHANGELOG.md
auto-1  | -rw-r--r--  1 root root  243 Feb  5 01:27 CITATION.cff
auto-1  | -rw-r--r--  1 root root  657 Feb  5 01:27 CODEOWNERS
auto-1  | -rw-r--r--  1 root root  35K Feb  5 01:27 LICENSE.txt
auto-1  | -rw-r--r--  1 root root  13K Feb  5 01:27 README.md
auto-1  | -rw-r--r--  1 root root  146 Feb  5 01:27 _typos.toml
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 configs
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 embeddings
auto-1  | -rw-r--r--  1 root root  167 Feb  5 01:27 environment-wsl2.yaml
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 extensions
auto-1  | drwxr-xr-x 13 root root 4.0K Feb  5 01:27 extensions-builtin
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 html
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:44 interrogate
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 javascript
auto-1  | -rw-r--r--  1 root root 1.3K Feb  5 01:27 launch.py
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 localizations
auto-1  | drwxr-xr-x  7 root root 4.0K Feb  5 01:27 models
auto-1  | drwxr-xr-x  7 root root 4.0K Feb  5 01:27 modules
auto-1  | -rw-r--r--  1 root root  185 Feb  5 01:27 package.json
auto-1  | -rw-r--r--  1 root root  841 Feb  5 01:27 pyproject.toml
auto-1  | drwxr-xr-x  8 root root 4.0K Feb  5 01:20 repositories
auto-1  | -rw-r--r--  1 root root   49 Feb  5 01:27 requirements-test.txt
auto-1  | -rw-r--r--  1 root root  371 Feb  5 01:27 requirements.txt
auto-1  | -rw-r--r--  1 root root   42 Feb  5 01:27 requirements_npu.txt
auto-1  | -rw-r--r--  1 root root  645 Feb  5 01:27 requirements_versions.txt
auto-1  | -rw-r--r--  1 root root 411K Feb  5 01:27 screenshot.png
auto-1  | -rw-r--r--  1 root root 6.1K Feb  5 01:27 script.js
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 scripts
auto-1  | -rw-r--r--  1 root root  43K Feb  5 01:27 style.css
auto-1  | drwxr-xr-x  4 root root 4.0K Feb  5 01:27 test
auto-1  | drwxr-xr-x  2 root root 4.0K Feb  5 01:27 textual_inversion_templates
auto-1  | -rw-r--r--  1 root root  670 Feb  5 01:27 webui-macos-env.sh
auto-1  | -rw-r--r--  1 root root   84 Feb  5 01:27 webui-user.bat
auto-1  | -rw-r--r--  1 root root 1.4K Feb  5 01:27 webui-user.sh
auto-1  | -rw-r--r--  1 root root 2.3K Feb  5 01:27 webui.bat
auto-1  | -rw-r--r--  1 root root 5.3K Feb  5 01:27 webui.py
auto-1  | -rwxr-xr-x  1 root root  11K Feb  5 01:27 webui.sh
auto-1  | Mounted .cache
auto-1  | Mounted config_states
auto-1  | mkdir: created directory '/stable-diffusion-webui/repositories/CodeFormer'
auto-1  | mkdir: created directory '/stable-diffusion-webui/repositories/CodeFormer/weights'
auto-1  | Mounted .cache
auto-1  | Mounted embeddings
auto-1  | Mounted config.json
auto-1  | Mounted models
auto-1  | Mounted styles.csv
auto-1  | Mounted ui-config.json
auto-1  | Mounted extensions
auto-1  | Installing extension dependencies (if any)
auto-1  | /opt/conda/lib/python3.10/site-packages/timm/models/layers/__init__.py:48: FutureWarning: Importing from timm.models.layers is deprecated, please import via timm.layers
auto-1  |   warnings.warn(f"Importing from {__name__} is deprecated, please import via timm.layers", FutureWarning)
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  | 
auto-1  | To create a public link, set `share=True` in `launch()`.
auto-1  | Startup time: 3.9s (import torch: 1.6s, import gradio: 0.5s, setup paths: 0.6s, initialize shared: 0.1s, other imports: 0.2s, load scripts: 0.2s, create ui: 0.3s).
auto-1  | c6bbc15e3224e6973459ba78de4998b80b50112b0ae5b5c67113d56b4e366b19
auto-1  | Loading weights [c6bbc15e32] from /stable-diffusion-webui/models/Stable-diffusion/sd-v1-5-inpainting.ckpt
auto-1  | Creating model from config: /stable-diffusion-webui/configs/v1-inpainting-inference.yaml
auto-1  | /opt/conda/lib/python3.10/site-packages/huggingface_hub/file_download.py:795: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
auto-1  |   warnings.warn(
vocab.json: 100% 961k/961k [00:00<00:00, 1.45MB/s]
merges.txt: 100% 525k/525k [00:00<00:00, 2.55MB/s]
special_tokens_map.json: 100% 389/389 [00:00<00:00, 3.79MB/s]
tokenizer_config.json: 100% 905/905 [00:00<00:00, 3.61MB/s]
config.json: 100% 4.52k/4.52k [00:00<00:00, 14.4MB/s]
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, apply weights to model: 1.0s, apply half(): 0.4s, calculate empty prompt: 0.1s).
```

Then start the app on [http://localhost:7860/](http://localhost:7860/).

![2025-02-05-14-28-16.png](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)

Now time to generate images! Type in the prompt:
>a black and white dog, 4k

![2025-02-05-14-31-52.png](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)

The parameters used to generate this image are:
> Steps: 69  
> Sampler: DPM++ SDE  
> Schedule type: Karras  
> CFG scale: 12  
> Seed: 55  
> Size: 1024x768  
> Model hash: c6bbc15e32  
> Model: sd-v1-5-inpainting  
> Conditional mask weight: 1.0  
> Version: v1.9.4  


Here is the saved image:
![](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)

She actully really looks like my dog **Bryson**!

You can tweak the parameters and find out what works best for you. The common parameters are:
- `prompt`: The text prompt for the image
- `negative_prompt`: The negative text prompt for the image
- `steps`: The number of steps for the diffusion process
- `cfg_scale`: The configuration scale for the image
- `seed`: The seed for the image generation

For more details about tweaking the parameters, please see this [article](/blog/2025/02-05-stable-diffusion-parameter-guide/).

Please note after you click on the "Save" button, the images will be saved in the `output|saved` folder of the **Stable Diffusion WebUI Docker** directory.

## Troubleshooting

### Error response from daemon: could not select device driver "nvidia" with capabilities:

The solution is to install the  nvidia container toolkit, please see [this link](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html):

```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-cuda-toolkit
```

### ImportError: cannot import name 'TypeIs' from 'typing_extensions' (/opt/conda/lib/python3.10/site-packages/typing_extensions.py)

As this issue reported [here](https://github.com/AbdBarho/stable-diffusion-webui-docker/issues/719), the solution is to downgrade `typing_extensions` as sugged by a github user [yasu-nxt](https://github.com/yasu-nxt):

- Locate the Dockerfile of  WebUI by AUTOMAIC1111 `./services/AUTOMATIC1111/Dockerfile`
- Find the line like below:
```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
```

Update this line and insert the following content:

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

### RuntimeError: CUDA error: unspecified launch failure

```bash
auto-1  | Traceback (most recent call last):
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/gradio/routes.py", line 488, in run_predict
auto-1  |     output = await app.get_blocks().process_api(
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/gradio/blocks.py", line 1431, in process_api
auto-1  |     result = await self.call_function(
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/gradio/blocks.py", line 1103, in call_function
auto-1  |     prediction = await anyio.to_thread.run_sync(
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/anyio/to_thread.py", line 33, in run_sync
auto-1  |     return await get_asynclib().run_sync_in_worker_thread(
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 877, in run_sync_in_worker_thread
auto-1  |     return await future
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 807, in run
auto-1  |     result = context.run(func, *args)
auto-1  |   File "/opt/conda/lib/python3.10/site-packages/gradio/utils.py", line 707, in wrapper
auto-1  |     response = f(*args, **kwargs)
auto-1  |   File "/stable-diffusion-webui/modules/call_queue.py", line 95, in f
auto-1  |     mem_stats = {k: -(v//-(1024*1024)) for k, v in shared.mem_mon.stop().items()}
auto-1  |   File "/stable-diffusion-webui/modules/memmon.py", line 92, in stop
auto-1  |     return self.read()
auto-1  |   File "/stable-diffusion-webui/modules/memmon.py", line 77, in read
auto-1  |     free, total = self.cuda_mem_get_info()
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.
auto-1  | Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.
```

A simple restart of the computer should fix it.

Afterwards, just re-run the command to start the app again.

```bash
docker compose --profile auto up --build
```


<ContactFooter />



404b788cae57d38d15961ecf4c6a3fe44cb182ed06aa856f6d932414c1e4864d

In this article, I will guide you through installing, configuring, and using Stable Diffusion WebUI Docker to streamline your image generation workflow.

Tag: Docker

Tag: Docker

Solving the .NET Build Hang on Linux with Docker

Using Stable Diffusion WebUI Docker for Image Generation – A Newbie's Guide