Schedule local model updates as controlled change jobs that start, validate, and finish within website maintenance hours. Add a cutoff that prevents new work near the window's end, and honor freeze periods when no changes should run. A local model is a model file that runs on infrastructure you control, sometimes on the same host that serves a website. Treat its download, loading, and validation as production changes because they can consume bandwidth, storage, memory, and GPU capacity.
Table of Contents
- Separate update scheduling from model scheduling
- Choose the right maintenance window
- Build a bounded update runbook
- Protect websites that share the inference host
- Verify the artifact and preserve recovery time
Separate update scheduling from model scheduling
Ollama does not document a feature that schedules model downloads around website maintenance. Its September 2025 "model scheduling" update concerns measuring memory and placing models across GPUs before execution, not choosing when updates occur, according to Ollama's model-scheduling announcement. Use an external change scheduler instead.
This could be an existing deployment workflow, infrastructure automation system, or scheduled job that can enforce a start time, timeout, and success checks. Keep the responsibilities separate: the scheduler decides when an update may run, while Ollama handles the model pull and subsequent inference. This separation also lets website teams manage model changes alongside plugin updates, drupal deployments, database work, and cache operations.
Choose the right maintenance window
Base the window on website demand and staff availability, not only the model team's calendar. Atlassian describes maintenance windows as periods when changes should occur and freeze windows as periods when they should not; scheduling outside peak use can reduce disruption and keep monitoring staff available, according to Atlassian's change-window guidance.
Before scheduling the job, identify: For example, a 90-minute maintenance window should not permit downloads to begin during its final minutes. Set an earlier cutoff, leaving the remaining time for verification, cache warming, service recovery, or restoring the previous model reference.
- The site's low-traffic period
- Business-critical publishing, campaign, and sales periods
- A freeze calendar covering launches and peak demand
- The expected download and validation time
- A cutoff that preserves time for recovery
Build a bounded update runbook
Start by recording the current model state. Then unload the model if necessary, pull the intended model, run a small validation request, and compare the resulting metadata with the saved state. Ollama accepts model downloads through `POST /api/pull`.
The request requires a model name and streams progress by default, allowing an update job to monitor completion within its allotted window, as shown in Ollama's pull API documentation. A practical runbook is: Treat streamed download progress as operational data, not proof of success. The model must still load and produce an acceptable response under the configuration used by the website.
- Confirm that the maintenance window is open and no freeze applies.
- Record the current model name, digest, size, and modification time.
- Pause or drain website features that send inference requests.
- Unload the active model if memory must be freed.
- Call `POST /api/pull` for the approved model name.
Protect websites that share the inference host
A model update can affect a website even when the web server remains online. Download traffic may compete with normal requests, while model loading and validation can consume memory or GPU capacity. Ollama keeps models in memory for five minutes by default. Its documentation says `ollama stop` or an API `keep_alive` value of `0` unloads a model immediately, which can free resources before an update.
Resource pressure matters most when several website functions share one inference host. Ollama queues new requests when available memory cannot load another model, and concurrently loaded GPU models must fit completely in VRAM. During live traffic, that can turn an otherwise successful update into slower page features, delayed content tools, or failed background jobs. Reduce that risk by draining inference requests before the pull, limiting update concurrency, and validating on one node before updating others. If the website cannot tolerate queued requests, route the feature to another healthy node or temporarily disable it during the change.
Verify the artifact and preserve recovery time
After the pull, query `GET /api/tags` and compare the result with the pre-update record. Ollama returns locally available models with modification timestamps, sizes, digests, formats, parameter sizes, and quantization levels, according to Ollama's tags API documentation.
Do not rely on the model name alone. Confirm that the expected digest or other approved metadata changed, that the model loads, and that a representative website request succeeds before reopening traffic. If validation fails or the cutoff arrives, stop the rollout and use the reserved maintenance time to restore the previously recorded model reference.
