# minikube image load: Use Local Images

> minikube image load makes a locally built image available to the cluster without a registry. Reference for image load/build and the ImagePullBackOff fix in CI.

Source: https://latchkey.dev/learn/command-reference/minikube-image-load  
Updated: 2026-06-30

minikube image load <image> copies a host-built Docker image into the minikube node so pods run it with no registry push.

Like kind, minikube cannot see host images by default. minikube image load bridges docker build and kubectl apply for local integration tests.

## What it does

minikube image load copies an image from the host Docker daemon into the cluster's container runtime. `minikube image build` builds directly inside the node, and `minikube image ls` lists what is loaded. With the image present, set `imagePullPolicy: IfNotPresent`.

## Common usage

```Terminal
docker build -t myapp:test .
minikube image load myapp:test
minikube image ls | grep myapp
# build straight into the node
minikube image build -t myapp:test .
```

## Options

| Form | What it does |
| --- | --- |
| image load <name> | Copy a host image into the node |
| image build -t <name> . | Build an image inside the node |
| image ls | List images present in the node |
| image rm <name> | Remove an image from the node |

## In CI

Build, `minikube image load`, then apply. Tag with the commit SHA rather than `:latest` so the kubelet does not reuse a stale image of the same tag. An alternative is `eval $(minikube docker-env)` so docker build targets the node directly, skipping the load step.

## Common errors in CI

`ImagePullBackOff` with `:latest` is the default-pull-policy trap; tag a real version and set `imagePullPolicy: IfNotPresent`. `Failed to load image: ... no such image` means the build tag and the load name differ. With the containerd runtime, an image loaded into Docker but not containerd is not visible; use `minikube image load`, which targets the active runtime.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### minikube image load: Use Local Images?

Like kind, minikube cannot see host images by default. minikube image load bridges docker build and kubectl apply for local integration tests.

### What it does?

minikube image load copies an image from the host Docker daemon into the cluster's container runtime. minikube image build builds directly inside the node, and minikube image ls lists what is loaded. With the image present, set imagePullPolicy: IfNotPresent.

### In CI?

Build, minikube image load, then apply. Tag with the commit SHA rather than :latest so the kubelet does not reuse a stale image of the same tag. An alternative is eval $(minikube docker-env) so docker build targets the node directly, skipping the load step.

### Common errors in CI?

ImagePullBackOff with :latest is the default-pull-policy trap; tag a real version and set imagePullPolicy: IfNotPresent. Failed to load image: ... no such image means the build tag and the load name differ.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt