Inside Ollama on Windows: A Practical Guide to Its App, API, Files, and Logs

After a standard Windows installation, Ollama is more than a terminal command. It is a native application that runs in the background, serves a local HTTP API, provides the ollama command-line interface, and stores binaries, models, configuration, updates, and logs in several locations (Windows documentation).

Those responsibilities create a useful troubleshooting map:

• Installation and command problems point to the binaries and user PATH.
• Integration problems point to the local server and the API interface expected by the client.
• Model-storage questions point to .ollama or the OLLAMA_MODELS setting.
• Application, server, and update problems have separate logs.

This is a documentation-based explanation. No hands-on process inspection or connectivity testing was performed.

The components at a glance

Ollama describes the standard installation as a native Windows application that runs in the background. It also makes the ollama command available in Command Prompt, PowerShell, and other terminals (Windows documentation).

“Runs in the background” does not necessarily mean “installed as a Windows system service.” The documentation does not identify a service name, process name, startup mechanism, or internal process layout.

Ollama separately offers a standalone CLI package that can be run as a system service using ollama serve and a tool such as NSSM. That is an optional deployment method, not a description of the standard installation (Windows documentation).

What the standard installer adds

The default installation is per-user and does not require Administrator rights. Its documented binary directory is:

%LOCALAPPDATA%\Programs\Ollama

The installer adds that directory to the user’s PATH. It also supports another installation directory through its /DIR option (Windows documentation).

If Windows reports that ollama is not recognized, the binary directory and user PATH are reasonable places to start. That is a command-discovery question, distinct from whether the local server is responding or a model has been downloaded.

Ollama says the binary installation requires at least 4 GB of space. Downloaded models need additional storage and can occupy tens to hundreds of gigabytes, depending on the models selected (Windows documentation). These figures are documentation guidance, not measurements from a tested computer.

How local applications reach Ollama

The standard Windows application serves the local API at:

http://localhost:11434

The correct base path depends on the interface supported by the client:

Anthropic clients append /v1/messages to their base URL (API introduction). The native chat endpoint, for example, is:

http://localhost:11434/api/chat

These distinctions help separate server reachability from an interface mismatch. A client could fail because it cannot contact port 11434, but it could also be using the wrong base path or request format. Ollama’s OpenAI and Anthropic compatibility layers each cover a subset of the corresponding API, so client-specific features should be checked against the relevant compatibility documentation (quickstart).

Local API requests do not require an API key, while direct requests to Ollama’s cloud API do (API introduction). The absence of a local API-key requirement is not evidence of network isolation, privacy, firewall behavior, or other security properties.

Where the CLI fits

The CLI provides commands for common model operations (CLI reference):

ollama pull gemma4
ollama run gemma4
ollama ls
ollama ps
ollama stop gemma4
ollama rm gemma4

These commands download, run, list, inspect running, stop, and remove models. The documented command for starting Ollama directly is:

ollama serve

Users of the standard Windows application should not assume they must run ollama serve after every launch. Ollama separately documents the installed application as running in the background and serving the API (Windows documentation).

Windows files and paths

The default documented locations are:

These locations come from Ollama’s Windows troubleshooting documentation. A custom installation directory or model-storage setting can change the first two paths.

You can open a location with Explorer:

explorer %LOCALAPPDATA%\Ollama

The documentation does not specify the names, lifetime, or cleanup behavior of temporary executable files under %TEMP%.

Changing model storage

By default, models and configuration are stored under:

%HOMEPATH%\.ollama

To redirect downloaded model storage, set the user-level OLLAMA_MODELS environment variable. If the tray application is already running, quit it and relaunch it from the Start menu so it receives the new setting. Open a new terminal after saving the variable so that terminal session also receives the updated environment (Windows documentation).

The documentation does not say that changing OLLAMA_MODELS migrates existing models. Treat it as a storage-location setting, not confirmation that existing data has moved.

Which log answers which question?

Under %LOCALAPPDATA%\Ollama, Ollama documents three logs (Windows documentation):

• app.log — recent output from the GUI application
• server.log — recent server output
• upgrade.log — upgrade output

These responsibilities provide a sensible starting point: application behavior maps to app.log, API-serving problems to server.log, and update problems to upgrade.log. Ollama does not document the logs’ retention, rotation, size limits, or completeness.

Symptom-to-component reference

This is a first-look map rather than an exhaustive diagnostic procedure, but it identifies which documented component, interface, path, or log answers each basic Windows troubleshooting question.

Sources and further reading

• https://docs.ollama.com/windows
• https://docs.ollama.com/api/introduction
• https://docs.ollama.com/quickstart
• https://docs.ollama.com/cli