Keep Ollama Models Warm with Scheduled Pulls

The first request against an unpulled Ollama model does not run inference, it downloads gigabytes. On a shared inference node or inside ephemeral task containers, that cold start lands on whoever asks first, usually a production pipeline at the worst time. This blueprint makes warmup an operational routine: a scheduled flow iterates over the team's model list with io.kestra.plugin.core.flow.ForEach and runs ollama pull for each one through io.kestra.plugin.ollama.cli.OllamaCLI, with model caching persisting the results between runs.

How it works

1. The models input holds the team's model list as a typed array, so adding a model to the warm set is a one-line change or an execution-time override.
2. warm_models (io.kestra.plugin.core.flow.ForEach) fans out over the list; inside it, pull_model runs ollama pull {{ taskrun.value }} for the current model.
3. enableModelCaching: true persists pulled models between runs, which is the property doing the real work: without it, each containerized execution starts from an empty model store and warmup would warm nothing.
4. Pulls of already current models are near-instant no-ops, so the nightly run costs seconds when nothing changed and only pays download time when a model was added or updated upstream.
5. notify posts the completed round to Discord; the errors block alerts when any pull fails.
6. A disabled-by-default Schedule trigger runs the warmup nightly at 05:00, before the workday.

What you get

• Zero cold-start latency for every flow that runs inference against the cached models.
• Per-model observability: each pull is its own task run with logs, timing, and retry behavior.
• A single source of truth for which models the team keeps warm, versioned with the flow.
• Early failure signals, since a renamed model or a full cache disk breaks the nightly warmup instead of a production inference run.

Who it's for

• Platform teams running shared Ollama nodes that other flows and users depend on.
• Teams whose inference tasks run in containers and rely on the plugin's model cache being current.
• Anyone who has watched a pipeline time out because its first step was silently downloading a model.

Why orchestrate this with Kestra

Warmup is classic day-2 work: it must run on schedule, cover a list that changes, fail loudly, and leave a record. Kestra gives each of those for free, the ForEach fans the list out into individual task runs, the schedule and history answer when the cache was last refreshed, and the same enableModelCaching mechanism is shared by every other Ollama blueprint, so warming here speeds up all of them.

Prerequisites

• The default containerImage runs Ollama inside Docker, so the Kestra worker needs access to a Docker daemon. On self-hosted workers that already have Ollama installed locally, set the task's taskRunner to Process to warm the local model store directly.
• Disk space for every model on the list; check sizes in the Ollama library before adding large models.
• A Discord incoming webhook.

Secrets

• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the DISCORD_WEBHOOK_URL secret to your Kestra namespace.
2. Execute the flow once manually; the first run downloads both default models, a second run completes in seconds.
3. Replace the default list with the models your flows actually use and set disabled: false on the nightly trigger.

How to extend

• Add a version-pinned tag per model (for example llama3.2:3b) so upstream releases never change behavior silently.
• Follow each pull with a one-token ollama run smoke test to verify the model loads, not just downloads.
• Post per-model timing to your metrics system by parsing task durations from the execution.
• Pair this flow with the Ollama text summarizer or batch classification blueprints, which reuse the same cache.

Links

• Ollama plugin documentation
• Ollama model library