otwld/ollama-helm: the Helm chart for running Ollama on Kubernetes

What the otwld/ollama-helm chart actually deploys

Ollama ships as a single binary that serves an HTTP API and pulls model weights on demand. On a laptop that is fine. On a cluster it is not, because someone has to decide which node has the GPU, where the model files are stored, and how a new pod gets its weights without a human running ollama pull by hand. This chart answers those three questions with Kubernetes primitives.

The intended audience is platform or infrastructure engineers who already operate Kubernetes and want Ollama to behave like any other workload: a Deployment, a Service, optionally an Ingress, optionally a PersistentVolumeClaim. The chart is published as a community chart on Artifact Hub, not as an official Ollama project. That distinction matters when you are deciding how much process you need around upgrades.

The README frames the scope narrowly. It is for deploying Ollama, and it points elsewhere for the API, the client libraries and the LangChain tutorials. So the chart is an operational wrapper, not a serving framework. If you want batching, autoscaling on queue depth or multi-model routing, the chart does not claim to provide it.

How GPU selection, model bootstrap and Knative mode work

The mechanism is ordinary Helm templating over values.yaml. Three value groups carry most of the behaviour.

The first is ollama.gpu. Setting ollama.gpu.enabled to true, choosing ollama.gpu.type as either 'nvidia' or 'amd', and setting ollama.gpu.number controls how many GPUs the pod requests. The README warns that not all GPUs are currently supported, especially with AMD, so the type field is a scheduling hint rather than a guarantee that the container will start successfully.

The second is model bootstrap. ollama.models.pull takes a list of model names that the container pulls at startup. ollama.models.create defines a model from a template, and ollama.models.run names a model to run. The create example in the README builds a variant of llama3.1 with a larger context window by setting PARAMETER num_ctx 32768. This is the part that replaces manual work: the pod comes up with weights already present, assuming the pull succeeds.

The third is Knative mode. With knative.enabled=true the chart renders a Knative Service instead of a Deployment and Service. Model bootstrap then becomes a separate Job. The README states that this Job is non-blocking, meaning helm install and helm upgrade return before model preload finishes, and that its name includes a hash of ollama.models.pull, ollama.models.run, ollama.models.create and ollama.models.clean, so changing any of those creates a new Job and reruns bootstrap. Completed Jobs are cleaned up according to knative.modelBootstrap.ttlSecondsAfterFinished. Knative bootstrap also requires persistentVolume.enabled=true so the Job and the Service share model data.

Installing otwld/ollama-helm and pulling two models on first start

The README is explicit that the registry is moving. It says the chart is migrating from https://otwld.github.io/ollama-helm/ to the OTWLD central registry at https://helm.otwld.com/, and asks users to update their Helm registry accordingly. Use the new URL.

Add the repository, refresh the index, and install into a namespace created on the fly:

helm repo add otwld https://helm.otwld.com/
helm repo update
helm install ollama otwld/ollama --namespace ollama --create-namespace

What you should see is a release named ollama in the ollama namespace, running the chart's default values. To make the first deployment useful, write a values file that turns on GPU integration and pulls two models at container startup. This is the README's basic GPU example:

ollama:
  gpu:
    enabled: true
    type: 'nvidia'
    number: 1
  models:
    pull:
      - mistral
      - llama2

Install or upgrade with that file, which is the documented upgrade path:

helm upgrade ollama otwld/ollama --namespace ollama --values values.yaml

The README recommends reading the Ollama release notes before upgrading, to check for backwards incompatible changes in Ollama itself. If you want the API reachable from outside the cluster, the chart has an ingress block. The README's example sets ingress.enabled to true, adds a host such as ollama.domain.lan and a path of / with pathType Prefix, and notes that the API then becomes reachable at that host.

The 0.X.X to 1.X.X values break and other upgrade costs

The most concrete limitation is documented in the README itself. Version 1.X.X introduced loading models into memory at startup and changed the values shape. If your values file still has ollama.models as a flat list, the chart will error, and the README tells you to move it under ollama.models.pull before upgrading.

That is a one-time migration, but it signals how this chart evolves: values keys are restructured when new capabilities arrive. Pinning a chart version and reading the values diff before each upgrade is cheaper than discovering a renamed key during a production rollback.

A second constraint is hardware. The README states Kubernetes 1.16.0-0 for CPU only and 1.26.0-0 for stable GPU support on NVIDIA and AMD. Running GPU workloads on an older cluster is outside what the chart claims to support, and the README repeats that an updated Kubernetes version is highly recommended for GPU deployments.

A third is that model bootstrap is startup work, not lifecycle management. The pull happens when the container starts. The README does not document rollback, does not describe what happens to a partially downloaded model if the pod is evicted mid-pull, and does not describe a retry policy for failed pulls beyond whatever the container does. If a model pull fails, you are looking at container logs, not a chart-level remediation.

Knative mode requires cluster feature flags you may not control

Knative support is the most opinionated part of the chart, and the README is unusually direct about the prerequisite. If you want to mount a PVC in Knative mode, the Knative Serving cluster must enable three feature flags: kubernetes.podspec-persistent-volume-claim, kubernetes.podspec-persistent-volume-write and kubernetes.podspec-tolerations. Without them, Knative rejects the rendered Service with webhook validation errors.

The README gives a way to inspect the current state:

kubectl get configmap/config-features -n knative-serving -o yaml

On a standard Knative Serving installation it shows a patch command against that ConfigMap. It also notes that if Knative is managed by the Knative Operator, you configure the flags on the KnativeServing resource instead of patching the ConfigMap directly. That is the correct guidance, and it is also the point where adopting this chart stops being a Helm decision and becomes a cluster-platform decision. If you do not administer Knative Serving, you cannot enable Knative mode on your own.

The non-blocking bootstrap Job is a trade-off worth naming. helm install returns before models are loaded, which is good for CI pipelines and bad if your first request arrives before the weights exist. Nothing in the README says the chart gates traffic on bootstrap completion.

otwld/ollama-helm compared with vLLM or a plain Deployment

The nearest alternative in the related searches is a vLLM Helm chart. The difference is architectural, not cosmetic. vLLM is a serving engine built around throughput techniques such as continuous batching and paged attention, and it exposes an OpenAI-compatible server. Ollama is a runner that manages model files and a simpler API. Choosing between them is choosing between a serving system you tune and a model runner you deploy. If your workload is many concurrent requests against one model, the vLLM path is the one designed for that. If your workload is a handful of models behind an internal API and you want the model files handled for you, this chart is the shorter path.

The other alternative is not a different product but a different level of abstraction: write your own Deployment, Service and PVC manifests, or run the official Ollama container directly. You would then own the GPU node selector, the volume wiring and the model pull step yourself. The chart's value is that those are already templated and the model pull list is a values key. The cost is that you inherit the chart's opinions, including the Knative feature-flag requirement and the values restructuring that came with 1.X.X.

Open WebUI appears in the related searches as a companion rather than a competitor. It is a front end; the chart is the backend that serves the models. The README does not document an integration between them, so treat any combined setup as something you assemble yourself.

Licence, maintenance and what an upgrade actually costs

The repository is MIT licensed. In practical terms that permits reuse and modification with attribution and without a copyleft obligation on your own code. This is not legal advice, and if you redistribute the chart inside a commercial product, read the LICENSE file in the repository rather than relying on a summary.

The repository is not archived, and the last push was on 2026-09-13. Releases in the days before that were ollama-1.81.0 on 2026-09-13, ollama-1.80.0 on 2026-09-09 and ollama-1.79.0 on 2026-09-02. That cadence means chart versions track Ollama releases closely, which is useful when you want a newer Ollama and awkward when you want to stay still. A chart version bump can carry a values change, as the 0.X.X to 1.X.X migration shows.

The upgrade procedure in the README is two steps: read the Ollama release notes for backwards incompatible changes, adjust your values, then run helm repo update followed by helm upgrade with your values file. Budget for the values review, not just the command. If you run Knative mode, remember that changing the model lists produces a new bootstrap Job, so an upgrade that only touches models still triggers work on the cluster.

Editorial conclusion

Adopt otwld/ollama-helm if your models already live behind Kubernetes, you need GPU scheduling through the chart, and you can accept a community chart whose values schema changed between 0.X.X and 1.X.X. Do not adopt it if you only want a single Ollama process on one machine, or if you expect the chart to manage model lifecycle beyond startup bootstrap. Before installing, verify two things: that your cluster meets the stated Kubernetes version for your hardware path (1.16.0-0 for CPU only, 1.26.0-0 for stable NVIDIA and AMD GPU support), and that your Helm registry points at https://helm.otwld.com/ rather than the older https://otwld.github.io/ollama-helm/ URL, which the README says is being migrated away from.

Frequently asked questions

Official sources

1. License: MIT
2. otwld/ollama-helm on GitHub
3. Project website
4. README
5. Releases