You can describe it like this:
Browser → WebUI → Ollama → Model → Response
Set up Summary
Getting Ollama running on Windows
– How to install Linux on Windows with WSL
I am creating a local AI machine that runs Ollama. Steps completed so far:
Getting Ollama running on Windows
Docker and Open WebUI deployment on Windows
Open WebIU is a critical design point in what you built, and understanding it properly will change how you think about deploying AI systems.
I’ll explain it clearly in the context of your setup — not generic theory.
You needed to run Open WebUI on the same machine as Ollama because:
The machine running Ollama is the one doing the actual AI processing, and Open WebUI must run close to it to reliably act as the interface.
Everything else should just connect to that machine via a browser, not try to run AI locally.
You now have three roles:
This is your AI server
It runs:
These are clients only
They:
The browser is the user interface, not the AI itself
Your system works like this:
Browser → WebUI → Ollama → Model → Response
Open WebUI does not run models.
It:
If you run WebUI on another machine:
When WebUI runs on the same machine:
http://localhost:11434
(internal, fast, reliable)
If WebUI runs on another machine:
http://<host-ip>:11434
You already saw issues like:
Running WebUI locally eliminates most of those.
AI workloads are:
If WebUI is remote:
While not huge, it adds:
Your goal was:
“Run AI from another machine”
That does NOT mean:
“Run AI on every machine”
One machine → does compute
Many machines → access it
You would either:
Which gives you:
When everything runs on the Ollama machine:
If WebUI is spread across multiple machines:
This was a key issue you hit:
You had to use:
host.docker.internal
This only works cleanly because:
If WebUI was on another machine:
What you built mirrors real-world architecture:
Client → Web App → API → Compute
In your case:
Browser → WebUI → Ollama → Model
This is the same pattern used by:
Running WebUI on the Ollama host allows you to:
If WebUI is remote:
Let’s be very direct.
If you ran WebUI on a different machine:
You would need to:
And still end up with:
You ran WebUI on the host machine because:
The AI models must run locally on one machine, and WebUI must sit as close as possible to that engine to provide a reliable interface.
Do not think:
“I am running WebUI on a machine”
Think:
“I am exposing an AI service from one machine to the rest of my network”
Running WebUI on the Ollama machine:
Once you’re comfortable, the next step is:
This turns your setup from a lab into a proper internal AI service.
I am creating a local AI machine that runs Ollama. Steps completed so far:
Getting Ollama running on Windows
Docker and Open WebUI deployment on Windows
In this case, Docker wasn’t just “nice to have”, it solved several very specific problems in your setup.
Open WebUI is built as a:
Without Docker, you would have needed to:
This is fragile and error-prone on Windows.
When you ran:
docker run ghcr.io/open-webui/open-webui:main
Docker:
So instead of building the environment, you consumed a known-good one
Your architecture now looks like:
Ollama (host)
Open WebUI (container)
Browser (client)
Without Docker:
Docker created an isolated runtime for WebUI:
This is especially important as you expand (RAG, APIs, agents)
One of the key issues you hit was:
host.docker.internalDocker introduces a controlled networking model
Instead of:
You get:
3000 → 8080
host.docker.internalThis makes multi-service communication predictable
You hit several issues:
Without Docker:
You would have had to:
You fixed everything with:
docker rm -f open-webui
docker run …
Full rebuild in seconds, with zero cleanup
This is one of Docker’s biggest practical advantages.
Right now, what you built can be:
You would need:
You only need:
docker run …
That’s a deployment standard, not just a setup
Your requirement was:
“Access Ollama from other machines”
Docker enabled:
You would:
Right now you have:
But next steps are:
Because it allows you to:
Example future stack:
WebUI → Ollama → Vector DB → API → Tools
This only scales cleanly with containerisation
This part is often missed.
You are running on Windows.
Many modern AI tools assume:
Docker gave you:
Without Docker + WSL:
In your exact setup, Docker was needed because:
You were running a modern, Linux-native, dependency-heavy application (Open WebUI) on a Windows machine and needed it to connect reliably to another local service (Ollama) while being accessible across the network.
Docker solved:
Let’s be blunt:
You likely would have spent hours:
And still ended up with:
Docker was not used here because it is “modern”.
It was used because it enabled:
In this scenario:
Docker transformed a complex, fragile, multi-component system into a predictable, repeatable, and easily recoverable deployment.
That is exactly why it exists.
This guide provides a complete step-by-step process to configure Ollama, Docker, WSL2, and Open WebUI for network access across multiple devices.
wsl --install wsl --set-default-version 2
Reboot the machine.
wsl -l -v
Expected:
docker-desktop Running Version 2 docker-desktop-data Running Version 2
winget install -e --id Docker.DockerDesktop
Open Docker Desktop and wait for “Docker is running”.
docker run hello-world
Add environment variable:
OLLAMA_HOST=0.0.0.0:11434
Restart Ollama.
curl http://localhost:11434/api/tags
ipconfig curl http://YOUR-IP:11434/api/tags
docker run -d ^ -p 3000:8080 ^ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 ^ -e WEBUI_AUTH=False ^ --name open-webui ^ ghcr.io/open-webui/open-webui:main
docker ps
http://localhost:3000
New-NetFirewallRule -DisplayName "Open WebUI" -Direction Inbound -Protocol TCP -LocalPort 3000 -Action Allow New-NetFirewallRule -DisplayName "Ollama API" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow
http://OLLAMA-PC-IP:3000
ollama pull llama3
Use WebUI to send a test prompt.
version: '3.8'
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://host.docker.internal:11434
- WEBUI_AUTH=False
volumes:
- open-webui-data:/app/backend/data
restart: always
volumes:
open-webui-data:
docker compose up -d
docker ps
wsl --shutdown
WEBUI_AUTH=False
I am launching into a new project to implement Ai ‘on premises’. The two major reasons for this are:
A. As the frontier cloud models become more expensive and small models become better I foresee much more demand to have AI solutions on premises
and
B. I want a local AI to integrate with mt IoT projects.
In the long run I will probably use Azure AI Foundry Local, however, this is going to require new hardware. Wanting to avoid that initially and get up to speed with other cheaper options I going to start with Ollama.
Think of Ollama as a model manager and runtime. It:
The official download page says Windows 10 or later. That’s technically correct and practically incomplete.
Your OS needs to be Windows 10 22H2 or newer — older builds turn progress indicators into rows of blank squares in the terminal. For NVIDIA cards, driver 531 or newer is required. Cards from the GTX 900 or 1000 era (compute capability 5.0–6.2) need driver 570 specifically — confirm your card’s compute level at nvidia.com/cuda-gpus before assuming you’re covered.
AMD is where people get caught. On Windows, Ollama supports Radeon RX 6000 and 7000 series only, via the ROCm v7 driver stack. If your card isn’t in that range, Ollama will silently fall back to CPU — no warning, no error. Check the supported hardware list before committing to the setup.
RAM: 16 GB is a working floor for 7B models; plan for 32 GB if you want breathing room. Storage tends to catch people off guard — the binary install is roughly 4 GB, but models range from 4 GB for smaller ones to well over 20 GB in the 14B range. NVMe for model storage is worth it. The installer runs under your user account — no admin rights needed.
OllamaSetup.exe from ollama.com and run it. Approve the Windows Defender prompt.ollama --version — confirm it’s on your PATH.curl http://localhost:11434/api/tags should return JSON.ollama pull llama3.2
ollama run llama3.2
ollama ps. Check the PROCESSOR column.That last step matters more than the rest combined.
The silent CPU fallback is the one that costs the most time. Ollama will run on CPU if it can’t access your GPU — no error, just responses ten to fifteen times slower than they should be. ollama ps shows what’s actually handling inference. Adding --verbose to your run command surfaces device information at startup as well.
Model storage defaults to your home directory. On a machine with a small system drive, this bites quickly. Set the OLLAMA_MODELS environment variable in your user account settings before pulling any models. The catch: if Ollama is already running as a background service, setting the variable in your current terminal won’t reach it — the service has the old environment. Quit from the system tray, save the variable, then relaunch.
When something breaks, start with the logs. Ollama writes to %LOCALAPPDATA%\Ollama\server.log — it’s significantly more informative than anything that surfaces on screen.
I’ll soon share my various builds with local AI here.
Nanoblock World Famous Buildings – Osaka Castle, Nanoblock – https://www.amazon.com.au/gp/product/B07HYRK6BJ
LEGO® Speed Champions Ferrari 812 Competizione 76914 Sports Car; Collectible Model Kit; Building Toy Set for Vehicle Fans and Kids Aged 9+; Includes Racing Car Driver Minifigure – https://www.amazon.com.au/Champions-Competizione-76914-Collectible-Minifigure/dp/B0BBRWGLY8/
Nanoblock – World Famous Buildings – Itsukushima Shrine, Nanoblock Sights to See Series – https://www.amazon.com.au/Nanoblock-Famous-Buildings-Itsukushima-Shrine/dp/B093DBWPDK/ref=sr_1_34?sr=8-34
After getting my new Snapmaker U1 and printing my first item I was looking for another project to print and found this:
https://galacticarmory.net/collections/3d-files/products/x-wing-vehicle-kit-card-3d-print-files
a cool Star Wars X-Wing fighter. You can see the result above.
The model was great but when I pulled it into the Snapmaker Orca slicer it wasn’t set up with the right colours. This meant that my first attempt was all in white. Once I had worked out the colour mapping I ended up with the desired result but I am still not happy with the process and need to spend more time with the Snapmaker Orca slicer to understand how it work and to make remapping colours easier.
However, I am super happy with the result and am now looking for my next project.
CIAOPS Labs 