How to Install Ollama on Windows 11 & Windows 10 (WSL2 & Native Setup)

Updated 27 October 2026 · Sources & corrections

This guide covers the standard Windows application first. A manually packaged CLI, custom Windows service or WSL server has a different lifecycle. Establish which instance you intend to use before changing settings or stopping processes.

1. Check current requirements and model capacity

The current Windows reference lists Windows 10 22H2 or newer and documents native NVIDIA and AMD acceleration requirements. This describes Ollama compatibility, not your operating system’s support lifecycle. Check the exact GPU and driver stack against the hardware support page; an old generic driver minimum is not a reliable requirement for every current device.

Plan separately for application files, model downloads and runtime memory. Weights, context, concurrency and other applications all affect whether a workload fits. The previous fixed context-cache allowance and universal VRAM table were too broad. Use the model-sizing guide and the selected checkpoint’s current card rather than a single minimum for every model.

2. Install the native app and locate the command

Use the official Windows download page and its current installer. The standard application installs for your account; a separately configured system service is a different setup. Launch the app, then open a new PowerShell session to pick up any updated user PATH.

Get-Command ollama -All | Select-Object CommandType, Source
ollama --version

If the command is not found, confirm the application actually installed and inspect the configured install location before editing PATH. The documented default binaries folder is %LOCALAPPDATA%\Programs\Ollama, but a custom installation may differ. Multiple command paths warrant inspection; they do not prove which server is receiving requests.

If Windows blocks an installer or its publisher cannot be verified, stop and check the official download and your device’s policy. Do not treat a warning as proof of a harmless false alarm or disable protection to complete this tutorial.

3. Check the API without downloading a model

Query the native installed-model endpoint from the Windows session where you expect the app to be running:

$modelList = Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/tags' -TimeoutSec 15
$modelList.models | Select-Object name, size

A successful response establishes that the requested endpoint responds. An empty list can be normal before installing a model. It does not establish inference capacity, GPU offload or which process owns the endpoint. If you receive a proxy-related error, inspect the client’s proxy settings separately from the local server.

4. Identify the port owner before restarting

A busy port can belong to the expected running server. Use these read-only checks rather than terminating every process with the same name:

$listeners = Get-NetTCPConnection -LocalPort 11434 -State Listen
$listeners | Select-Object LocalAddress, LocalPort, OwningProcess
$listeners.OwningProcess | Sort-Object -Unique | ForEach-Object {
    Get-Process -Id $_ | Select-Object Id, ProcessName, Path
}

Microsoft documents these filters in Get-NetTCPConnection. No matching listener can produce an error; it is useful evidence, not a reason to kill a process. Permissions can limit process details. Compare the PID and path in Task Manager with your chosen installation.

If you intentionally restart the standard app, finish active work and use its own quit/relaunch controls. A custom service must be managed through that service’s controls. A restart can interrupt requests; do not start another ollama serve while an expected server already owns the port.

5. Download deliberately and verify one model request

The following example downloads a local checkpoint and performs inference. Review its current licence, disk and memory needs first; it is an example tag, not a universal recommendation:

ollama pull llama3.2:3b
ollama run llama3.2:3b "Reply with one short greeting."
ollama ps

The CLI reference documents pull, run and loaded-model inspection. Check any shell OLLAMA_HOST setting: a command pointed at a remote server is not testing this PC. Inspect ollama ps while the model remains loaded; an empty result after unloading can be normal.

The official processor-column explanation distinguishes CPU, GPU and split loading. A GPU label is not a benchmark and does not identify a specific adapter by itself. Correlate the request with logs and your actual supported hardware. For NVIDIA, nvidia-smi checks the driver-facing device view; it does not prove Ollama used the device.

Native AMD support is not equivalent to a blanket recommendation to switch to WSL. Verify the current ROCm/HIP or Vulkan path for the exact card. Do not copy a device index, architecture override or laptop graphics-setting change without evidence it applies. Memory pressure may justify a smaller model or context; use our context override checks.

6. Inspect logs and change storage reversibly

Get-Content -LiteralPath (Join-Path $env:LOCALAPPDATA 'Ollama\server.log') -Tail 80

The standard application documents server logs under %LOCALAPPDATA%\Ollama. A custom service account or packaging may use another path. Remove credentials, private prompts and sensitive paths before sharing log excerpts.

For a model-location change, prepare the destination and retain the old copy until verification is complete. The Windows environment instructions require quitting the running app, changing the user variable and reopening the application. Setting a variable only in PowerShell does not automatically reconfigure an app that was already running.

Use our storage migration guide to verify the active library and preserve the model-store structure. Changing OLLAMA_MODELS does not move files. An empty library after a move may indicate the wrong active path, rather than deleted weights.

7. Keep Windows and WSL deployment boundaries clear

Choose WSL2 when you need a Linux workflow and can administer that environment. Use the Linux installation guide inside the distribution and verify that environment’s service and model store. Native Windows installation does not require also installing a WSL server.

Windows-to-WSL connectivity depends on direction, NAT or mirrored mode, and firewall configuration. Microsoft’s WSL networking guide explains these differences. Do not assume the two environments always share localhost identically or always need different ports. Record the server environment and test from the actual client environment.

For a container frontend, loopback refers to that container. Follow our frontend topology guide before changing browser CORS settings. This setup does not require publishing an unauthenticated API port to the internet.

Next step: keep the command path, client version, listening PID, API result and one model-request result as separate evidence. If any stage fails, follow our troubleshooting guide with the exact status and relevant logs.