Loki removes its bundled MinIO on 31 October: a five‑minute check for archived dependencies

The community Loki Helm chart will remove its bundled MinIO subchart on 31 October 2026. The chart already enforces it: with minio.enabled=true, rendering fails unless you set an explicit escape hatch, ignoreMinioDeprecation=true. The error message carries the date.

If your Loki was installed with the built-in object store, nothing has broken yet. The pods run, logs arrive, dashboards load, and the cluster gives no sign that a dependency is due to disappear.

Why a running cluster hides it

With the default pull policy for a tagged image (IfNotPresent), a container that starts on a node which already has the image never asks the registry whether the image still exists.

The registry gets asked when a replacement pod lands on a node without the image: a node is replaced, a new node joins during scale-out, a pod is evicted and rescheduled elsewhere, or the kubelet removes unused images under disk pressure. If the image is gone at that moment, the pod ends in ErrImagePull and then ImagePullBackOff. That tends to happen during an incident, or as a side effect of routine maintenance such as a node pool upgrade, when nobody is watching that particular component. Pods with imagePullPolicy: Always, which is also the default for :latest and untagged images, find out sooner, on any container restart.

Helm-managed components have a second trigger: the next chart version upgrade. A chart version that blocks a dependency fails to render, and the change you were trying to make stops there.

A dependency can disappear upstream without any warning inside the cluster. The first signal is a failed pull on a new node or a failed render on the next chart upgrade.

What changed with MinIO

The 31 October date is the end of a chain that has been running for most of a year:

• December 2025: the MinIO community edition entered maintenance mode.
• April 2026: the minio/minio repository was archived and is now read-only. The community edition is distributed as source code only — no new binaries, no security fixes.
• Docker Hub: the minio/minio image repository returns 404. Charts and manifests that pull MinIO from Docker Hub can no longer pull it on a fresh node.
• Charts that bundle MinIO as a default object store are affected one by one. An open issue on the Milvus Helm chart (September 2026) reports that a default install fails on the image pull. The Grafana Enterprise Logs chart swapped its bundled image for a third-party fork. The community Loki chart chose removal, scheduled for 31 October.

Where your MinIO image comes from decides which trigger applies. The MinIO chart that Loki bundles pulls from a registry other than Docker Hub, by default a MinIO release tagged December 2024. For Loki the failure you can count on is the next chart upgrade. In the meantime the image receives no security fixes.

None of this is visible from inside a healthy cluster: a running MinIO pod shows no error, whether its image can still be pulled or not.

It can arrive as a subchart

MinIO in a cluster is not always a choice anyone made. It can arrive as a subchart: a default enabled: true inside a chart for something else, so the logging stack or the vector database has somewhere to write during setup. A default like that can survive into production unnoticed, because the system works and the storage it started with raises no alarm.

Asking the team whether you run MinIO is less reliable than reading the Helm values.

Bitnami images follow the same pattern. The docker.io/bitnami catalog was removed from Docker Hub on 29 September 2025. The versioned tags moved to docker.io/bitnamilegacy, which receives no updates. A workload still pointing at the old path has either already failed a pull or is running from cache or from an internal registry mirror.

The five-minute check

Two read-only commands. Neither changes anything in the cluster. You need read access to Helm release secrets and pods in all namespaces.

1. Helm releases with a bundled MinIO enabled — including MinIO nested inside an umbrella chart:

helm list -A --max 0 -o json | jq -r '.[] | "\(.namespace) \(.name)"' |
while read -r ns rel; do
  helm get values --all -n "$ns" "$rel" -o json |
    jq -e '[.. | objects | .minio?.enabled?] | any(. == true)' >/dev/null &&
    echo "$ns/$rel: bundled MinIO enabled"
done

2. Running containers that use images from these sources:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{range .spec.initContainers[*]}{.image}{" "}{end}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' |
  grep -E 'minio/(minio|mc)|bitnami(legacy)?/'

The second command lists pods that exist right now. CronJobs and workloads scaled to zero have no running pod; check their pod templates the same way.

An empty result from both is the result you want. Anything listed is a component without upstream maintenance. Images still pointing at docker.io/minio/minio or the old docker.io/bitnami path will not pull on a new node, unless an internal registry mirror still holds a copy.

For each hit the options are the same: move to a maintained image, or replace the component with an external object store. For Loki, the chart README describes the migration: a transition release that keeps old MinIO data readable while new data goes to the external store, with MinIO removed only after retention has elapsed. ignoreMinioDeprecation=true buys time for that transition. The subchart it keeps alive is scheduled to leave the chart on 31 October.

The Bottom Line

The Loki deadline is useful because it is explicit: a date, a failing render, a documented migration path. An archived project or a removed image gives no such signal on its own. Run the two checks across the whole cluster before 31 October, not only in the logging stack, and add them to the steps you run before every node pool upgrade.

Where We Apply This

Dependencies that no longer have an upstream are one of the items we check in a Kubernetes Health Check, alongside control plane recoverability and whether node, pod and volume health is visible and acted on. The same check is part of our Monitoring & Observability Assessment, because a monitoring stack that does not start after a node replacement is unavailable during the incident it is meant to cover.

Related reading: Kubernetes Health Check · Monitoring & Observability Assessment · Kubernetes & container platforms