Ollama update: change one layer and verify the workload
Update Ollama with a platform-aware checklist, distinguish runtime and model changes, preserve configuration and verify a representative task afterward.
Updating Ollama and downloading a newer model are different operations. Updating a chat interface is a third operation, and changing a GPU driver is a fourth. If you change all four at once and a workflow breaks, the cause becomes difficult to isolate. Start by identifying the layer that needs changing, preserve its relevant settings, then verify the same small workload before and after.
The right objective is not simply “the installer completed.” It is “the intended runtime is active, the expected model is available, and the application still completes its task.” This guide gives a platform-aware sequence and an original before-and-after ledger. It does not recommend updating a production machine in the middle of active requests. If an update changes hosted-model usage, revisit the budget calculator with measured consumption rather than assuming the bill stayed constant.
Identify which update you actually need
| Layer | What changes | Useful acceptance evidence |
|---|---|---|
| Ollama runtime | Serving software and supported behavior | Active version and a completed API or CLI task |
| Model artifact | Downloaded weights, template or packaged settings | Exact model identity and expected output behavior |
| Client integration | Interface, coding agent or provider configuration | End-to-end request using the expected route |
| Driver or operating system | Hardware support and system dependencies | Device recognition and representative resource behavior |
A request for a newly supported model may justify a runtime update. A broken interface setting may not. Read the relevant release notes and the error first. If the issue appeared immediately after a client configuration change, investigate that boundary before replacing the entire serving stack. Updating can be appropriate maintenance, but it is not a substitute for understanding an authentication, networking or permissions problem.
Before changing anything, make a small baseline
Record the installed version, the running service or app, the model identifier, the installation method and the client that depends on it. Use the official CLI reference for supported inspection commands: ollama ls lists available models and ollama ps lists running models. Save only the fields needed for diagnosis, not a dump of unrelated environment variables that could contain credentials.
Choose one short non-sensitive prompt and one representative application task. For each, record completion status, approximate elapsed time and any relevant resource observations. Also save intentional configuration changes through your normal backup process, including a custom model directory or service override. A list of downloaded models is useful inventory, but it is not a backup of every custom artifact, chat history or interface database.
Windows and macOS: restart the updated application deliberately
The Ollama FAQ describes automatic update downloads for macOS and Windows and the application's “Restart to update” action. It also points to manual downloads. Allow active work to finish before restarting. Afterward verify the running application rather than assuming that a downloaded installer changed the process already serving requests.
If the visible app and a terminal appear to disagree, check which executable and server the client is actually using. An old terminal session, alternate installation or separate environment can explain the mismatch. Do not delete model directories as a first troubleshooting step. On Windows, the platform documentation identifies application, server and upgrade logs; use the log matching the failed stage and redact private content before sharing it.
Linux: preserve the installation method and service settings
The official Linux instructions describe updating through the installer or a fresh distribution download and document systemd customization. Follow the method appropriate to your existing installation and architecture. Read the installer and privilege requirements before execution. This guide intentionally links the upstream instructions instead of encouraging you to paste an unreviewed remote script into a shell.
A service-managed deployment needs a maintenance window if other applications use it. Preserve relevant overrides, arrange a controlled restart, and inspect service status afterward. A process being active is only a readiness checkpoint; run the baseline request as well. If you maintain a containerized installation instead, update through that deployment's documented image and persistence process rather than installing a second host runtime and accidentally testing the wrong server.
Model refreshes deserve their own comparison
The CLI reference documents ollama pull as a model-download operation. A model name alone is not a complete scientific record of what changed over time. Save the identifier and available artifact metadata before intentionally refreshing a model, particularly if a workflow depends on a custom template or a particular behavior. Do not claim that a runtime update automatically refreshes every installed model.
When evaluating a model refresh, keep the runtime and test prompts fixed where practical. Compare correctness, instruction following and resource needs, not just the visible fluency of a single answer. A model that produces a longer response can consume more output tokens even if its advertised rate is unchanged. A model that needs extra retries may raise completed-task cost while appearing faster on the first response.
An original acceptance ledger
For an illustrative maintenance run, suppose your short baseline finishes in 8 seconds before and 9 seconds after, while the application task finishes in 70 seconds before and 48 seconds after. These invented times show why one metric is insufficient: the short prompt regressed slightly, but the representative workflow improved. Repeat enough runs to understand normal variation before deciding the update caused either difference.
Add a correctness column, a memory-pressure observation and a note about warm versus freshly loaded models. A warm model and a cold start are not equivalent tests. Do not divide visible output length by total wall time and call it a standardized token-generation benchmark. If the API exposes timing and token fields, preserve their units and definitions from the usage documentation.
If something breaks, isolate before rolling back
First repeat the smallest baseline directly against the intended server. If that works, test the dependent client without optional tools or long history. If the direct test fails, inspect the matching runtime logs and model identity. Check whether the failure is deterministic and whether a restart left two competing instances. Do not erase the installation, configuration and models together; that removes evidence and makes recovery more expensive.
A rollback plan should use a known supported prior artifact and your preserved settings, not a guessed version or a destructive cleanup command. Decide whether a rollback is actually necessary before interrupting other users. Where a security fix motivated the update, account for the risk of reverting it. Document the final state and any remaining failed acceptance checks instead of recording “updated successfully” solely because a version number changed.
Frequently asked questions
Does updating Ollama update Open WebUI?
No single runtime update should be treated as proof that a separate interface changed. Check each component's installation and version independently. The WebUI connection guide maps the interface and server boundaries.
Should I update all models at the same time?
Not when you need an interpretable comparison. Start with the model relevant to the change, preserve the baseline and verify it. Large downloads also need adequate storage and an appropriate network window.
Can an update change my monthly cost?
It can change workload behavior, defaults or integration routing, so verify those assumptions. A successful upgrade does not itself establish a price change. Compare measured hosted consumption and accepted outcomes before changing a subscription.
This checklist draws operational facts from the linked official platform, CLI and usage references. Its ledger and acceptance sequence are original guidance, not a claim that an update was performed or benchmarked here.