Local AI Stack with Docker Compose: Ollama, Open WebUI and Qdrant

Published on September 29, 2026 by Muhammad Raza Bangi

A Local AI Stack, Generated and Config-Validated

Our own Docker Compose Generator ships a "Local RAG Starter" recipe: Ollama for running local models, Open WebUI for a ChatGPT-style interface, and Qdrantfor vector storage. This post shows the exact file that recipe produces, the exact command we used to validate it, and exactly what that validation does and doesn't prove.

Everything below — the YAML, the settings, the validation output — is real output from our shipped tool, not hand-written for this post.

What Was Actually Tested (and What Wasn't)

We're explicit about this distinction because "the config is valid" and "the stack works" are different claims, and conflating them is exactly the kind of overstatement we're trying to avoid in our own content.

Exact Generator Settings Used

To reproduce this file yourself in the Docker Compose Generator:

• Open the AI & Automation group of Quick Stack Recipes
• Select Local RAG Starter
• Choose the "With PostgreSQL + Redis" variant (the "Minimal" variant produces the same three AI services without the database and cache)
• Leave every other setting at its default — Environment: Development, healthchecks enabled, named volumes and network enabled
• Download compose.yaml and .env.example

The Generated compose.yaml

This is the unedited output of that recipe:

# Generated with the 92 Nodes Docker Compose Generator
# https://92nodes.com/resources/docker-compose-generator
# Review before use: check credentials, resource limits, backups, and deployment-specific requirements.
services:
  ollama:
    image: ollama/ollama:0.34.2
    ports:
      - 11434:11434
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped
    networks:
      - app-network
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - 3000:8080
    environment:
      OLLAMA_BASE_URL: http://ollama:11434
    volumes:
      - open_webui_data:/app/backend/data
    restart: unless-stopped
    depends_on:
      ollama:
        condition: service_started
    networks:
      - app-network
  qdrant:
    image: qdrant/qdrant:v1.19.1
    ports:
      - 6333:6333
    volumes:
      - qdrant_data:/qdrant/storage
    restart: unless-stopped
    networks:
      - app-network
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_DATABASE}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped
    healthcheck:
      test:
        - CMD-SHELL
        - pg_isready -U ${DB_USERNAME} -d ${DB_DATABASE}
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s
    networks:
      - app-network
  redis:
    image: redis:7
    volumes:
      - redis_data:/data
    restart: unless-stopped
    healthcheck:
      test:
        - CMD
        - redis-cli
        - ping
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - app-network
name: local-rag-starter
volumes:
  ollama_data: {}
  open_webui_data: {}
  postgres_data: {}
  qdrant_data: {}
  redis_data: {}
networks:
  app-network: {}

The matching .env file we used for validation (placeholder values, not real credentials):

DB_USERNAME=ragapp
DB_PASSWORD=devpassword
DB_DATABASE=ragdb

Validating the Configuration

With the two files above in the same directory, we ran:

docker compose config

It exited successfully and printed the fully resolved configuration. An excerpt showing the environment variables resolving and the depends_on condition between open-webui and ollama:

db:
  environment:
    POSTGRES_DB: ragdb
    POSTGRES_PASSWORD: devpassword
    POSTGRES_USER: ragapp
  healthcheck:
    test:
      - CMD-SHELL
      - pg_isready -U ragapp -d ragdb
    ...
ollama:
  image: ollama/ollama:0.34.2
  ports:
    - mode: ingress
      target: 11434
      published: "11434"
      protocol: tcp
  ...
open-webui:
  depends_on:
    ollama:
      condition: service_started
      required: true
  environment:
    OLLAMA_BASE_URL: http://ollama:11434
  ...

This confirms the file is well-formed Compose Specification YAML that a real Docker Compose parser accepts — nothing more.

Required vs. Optional Services

Ollama, Open WebUI and Qdrant are the core trio — together they give you a working local chat interface backed by open models, plus a vector database you can query directly. These three are wired together: Open WebUI depends on Ollama and is configured with its address.

Postgres and Redis are optional, and it's worth being precise about what "optional" means here: in the generated file, neither is connected to anything. There's no environment variable pointing an AI service at the database, and no depends_onlinking them to Ollama, Open WebUI or Qdrant. They exist as ready-to-use infrastructure for when you build a real application layer on top of this stack — storing document metadata, tracking ingestion job state, or caching — which this recipe deliberately doesn't attempt to do for you. If you don't have that layer planned yet, the "Minimal" variant (just the three AI services) is the more honest starting point.

Hardware and Model Requirements

This configuration runs Ollama in CPU-only mode— that's the generator's default, and it's what we validated. No GPU reservation is present in the file above.

• Start with a small model (roughly 1-3B parameters) to confirm the stack works before trying anything larger — CPU inference on bigger models is noticeably slower.
• As a rule of thumb, keep free RAM comfortably above the model file's size; larger models need proportionally more.
• Disk space adds up quickly once you pull more than one model — check available space before pulling several.
• If you need faster inference, the generator can produce NVIDIA or AMD GPU passthrough configuration instead — that's a different generator option we did not select or validate for this post.

Setup Steps

1. Generate compose.yaml and .env.example as described above, or copy the file from this post.
2. Copy .env.example to .env and fill in real values for the database credentials (skip this if you used the Minimal variant).
3. Run docker compose up -d to start every service in the background.
4. Run docker compose ps and confirm every container reaches a running (and, where a healthcheck exists, healthy) state.
5. Pull a small model: docker exec -it ollama ollama pull llama3.2:1b (swap in whichever model you prefer).
6. Open http://localhost:3000 for Open WebUI, select the model you pulled, and send a test message.
7. Open http://localhost:6333/dashboard to confirm Qdrant's own dashboard is reachable.

What to Test Yourself After Startup

Since we validated the configuration but didn't run it, here's exactly what we'd check if we were verifying this stack ourselves:

• All five containers show as running in docker compose ps, and Postgres/Redis reach a "healthy" state, not just "starting".
• Open WebUI loads without errors and lists the model you pulled.
• A chat message in Open WebUI gets an actual response from the model, not a connection error.
• Qdrant's dashboard loads and you can create a test collection through it.
• If you're using the with-db variant, Postgres and Redis start cleanly — but don't expect them to do anything yet, since nothing in this stack uses them.

Troubleshooting

• Port already in use (3000, 6333, 11434, 5432, or 6379): another process or a previous stack is already bound to it — stop that process or change the host-side port mapping in the file.
• Open WebUI shows no models: you haven't pulled one yet — run the ollama pull command above, then refresh.
• First response is slow: Ollama is likely still loading the model into memory, or you're running a larger model on CPU than your hardware comfortably handles — this is expected, not a bug.
• Postgres or Redis show "unhealthy" briefly after startup: normal during the healthcheck's start_period — give it the interval shown in the file before treating it as a real failure.
• open-webui can't reach Ollama: confirm both containers are on the same Compose network (they are, by default, in the generated file) and that you didn't rename the ollama service without updating OLLAMA_BASE_URL.

Scope and Limitations

Our generator states this directly in its own recipe description, and it's worth repeating here: this stack provides infrastructure only. It does not implement document ingestion, chunking, embedding generation, retrieval logic, or prompt orchestration. Building an actual retrieval-augmented chatbot on top of it — one that answers questions grounded in a document you upload — is separate work this post does not cover and this configuration does not attempt.

What we can honestly claim: the file is syntactically valid, internally consistent Compose Specification YAML, generated by a real, shipped tool, and confirmed with a real Docker Compose parser. What we can't yet claim: that the three AI services function together at runtime, or that this is a working RAG chatbot. That gap is exactly what the setup and testing steps above are for.

Frequently Asked Questions

Conclusion

A generator that produces valid, reviewable infrastructure is a genuinely useful starting point — but it's not the same thing as a finished, tested application, and we'd rather say that plainly than let a validated config file get mistaken for a running product.

Want to generate your own variant of this stack — with a GPU, without Postgres/Redis, or combined with one of our other AI & Automation recipes? Try the Docker Compose Generator yourself, or if you need this built into a real, working AI application, that's what our AI solutions team does.

Further reading: Docker's official documentation for docker compose config, Ollama's GitHub repository, and Qdrant's documentation.