---
title: "Helm chart components | Grafana Loki documentation"
description: "A short introduction to the components installed with the Loki Helm Chart."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Helm chart components

This section describes the components installed by the Helm Chart.

## 3 methods of deployment

The Loki chart supports three methods of deployment:

- [Monolithic](/docs/loki/latest/setup/install/helm/install-monolithic/)
- [Simple Scalable](/docs/loki/latest/setup/install/helm/install-scalable/)
- [Microservice](/docs/loki/latest/setup/install/helm/install-microservices/)

By default, the chart installs in [Monolithic](/docs/loki/latest/setup/install/helm/install-monolithic/) mode (`deploymentMode: Monolithic`). For production at scale, we recommend deploying Loki in *microservices* (`deploymentMode: Distributed`) mode. To understand the differences between deployment methods, see the [Loki deployment modes](/docs/loki/latest/get-started/deployment-modes/) documentation.

> Note
> 
> Simple Scalable Deployment (SSD) mode is being deprecated. The timeline for the deprecation is to be determined (TBD), but will happen before Loki 4.0 is released.

## Zone-aware replication

When deploying in [microservices](/docs/loki/latest/setup/install/helm/install-microservices/) mode, the chart enables **zone-aware replication** for ingesters by default (`ingester.zoneAwareReplication.enabled: true`). This creates three ingester StatefulSets (zone-a, zone-b, zone-c) and requires enabling the `rollout-operator` subchart (`rollout_operator.enabled: true`) for coordinated zone rollouts. Zone-aware replication allows multiple ingesters within a single zone to be shut down and restarted simultaneously during rollouts, while the remaining two zones guarantee at least one copy of the data.

To disable zone-aware replication (for example, in a development or test environment):

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
ingester:
  zoneAwareReplication:
    enabled: false
```

If you deploy Loki using the jsonnet ([ksonnet](https://github.com/grafana/loki/tree/main/production/ksonnet)) method instead of the Helm chart, refer to [Speed up ingester rollout using zone awareness](/docs/loki/latest/operations/zone-ingesters/), which describes the equivalent `multi_zone_ingester_*` jsonnet configuration.

## Pattern ingester

The chart includes an optional **pattern ingester** component (`patternIngester`) for detecting and extracting log patterns. It is disabled by default (`patternIngester.enabled: false`, `replicas: 0`). In Distributed mode (`deploymentMode: Distributed`), enable the standalone workload with:

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
deploymentMode: Distributed
patternIngester:
  enabled: true
  replicas: 1
loki:
  pattern_ingester:
    enabled: true
```

In Monolithic or SimpleScalable mode, enable it via Loki configuration only:

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
loki:
  pattern_ingester:
    enabled: true
```

## Overrides exporter

The **overrides exporter** (`overridesExporter`) is an optional component that exposes per-tenant configuration overrides as Prometheus metrics. It is disabled by default (`overridesExporter.enabled: false`). Enable it when you need visibility into tenancy-level limit settings.

## Bloom filters (experimental)

The chart includes experimental support for **bloom filters** through three components:

- `bloomGateway`: Serves bloom filter queries
- `bloomPlanner`: Plans bloom filter build jobs
- `bloomBuilder`: Builds bloom filters

All three are disabled by default (replicas set to 0). Enable bloom filters in the Loki configuration (`loki.bloom_build.enabled: true`, `loki.bloom_gateway.enabled: true`) and set non-zero replica counts for the corresponding components.

## Monitoring Loki

The Loki Helm chart includes built-in monitoring resources that can be enabled:

- **ServiceMonitor** (`monitoring.serviceMonitor.enabled`): Creates Prometheus Operator ServiceMonitor resources for scraping Loki metrics.
- **Recording rules** (`monitoring.rules.enabled`): Creates a PrometheusRule resource with loki-mixin recording rules.
- **Alert rules** (`monitoring.alerts.enabled`): Creates a PrometheusRule resource with alerts such as `LokiRequestErrors`, `LokiRequestPanics`, and `LokiRequestLatency`.
- **Dashboards** (`monitoring.dashboards.enabled`): Creates ConfigMaps containing Grafana dashboards for monitoring Loki.

These built-in monitoring resources are disabled by default. For comprehensive cluster-wide observability, use the [Kubernetes monitoring Helm chart](https://github.com/grafana/k8s-monitoring-helm). See [Monitoring](/docs/loki/latest/setup/install/helm/monitor-and-alert/) for details.

> Note
> 
> For comprehensive cluster-wide observability, Grafana Labs recommends the [Kubernetes monitoring Helm chart](https://github.com/grafana/k8s-monitoring-helm). The Loki chart still provides optional built-in Prometheus Operator resources under `monitoring.*`; only the former `monitoring.selfMonitoring` / Grafana Agent integration has been removed.

## Canary

This chart installs the [Loki Canary app](/docs/loki/latest/operations/loki-canary/) by default. This is another tool to verify the Loki deployment is in a healthy state. It can be disabled by setting `lokiCanary.enabled=false`.

## Gateway

By default and inspired by Grafana’s [Tanka setup](https://github.com/grafana/loki/blob/main/production/ksonnet/loki), the chart installs the gateway component which is an NGINX that exposes the Loki API and automatically proxies requests to the correct Loki components (read or write, or single instance in the case of filesystem storage). You can expose Loki either through `gateway.ingress` (with `gateway.enabled: true`) or through the top-level `ingress` key (with `gateway.enabled: false`), but not both. If the gateway is enabled, Grafana and log shipping agents, such as Grafana Alloy, should be configured to use the gateway. If NetworkPolicies are enabled, they are more restrictive if the gateway is enabled.

## Caching

By default, the chart deploys Memcached-based **chunks cache** (`chunksCache.enabled: true`) and **results cache** (`resultsCache.enabled: true`). To use an externally managed Memcached instead, disable the built-in caches and point `chunksCache.addresses` / `resultsCache.addresses` at your service. See [caching](/docs/loki/latest/operations/caching/) for tuning guidance.

## StatefulSet persistence

Several components in this chart run as Kubernetes StatefulSets, including `ingester`, `write`, `backend`, and `singleBinary`, which all use `kind: StatefulSet` by default. Some Helm values map to StatefulSet fields that Kubernetes treats as immutable after the StatefulSet is created, such as storage class, persistent volume claim (PVC) size, access modes, and `podManagementPolicy`. If you change one of these values and run `helm upgrade`, the upgrade can fail.

For a few of these values, including PVC size and `podManagementPolicy`, you can set `*.statefulSetRecreateJob.enabled` on a Loki component. This runs an experimental job before the upgrade that deletes the StatefulSet but keeps its pods and PVCs, so no data is lost. The job does not handle other changes, such as storage class or access modes. Those still require a manual migration.

For the full list of affected values, which components render StatefulSets in each deployment mode, and how the recreate job works, see the “StatefulSet immutability” section of the [chart’s README](https://github.com/grafana-community/helm-charts/tree/main/charts/loki#statefulset-immutability) on GitHub.