Install Grafana Loki with Helm on Grafana Labs

Helm chart components

Thu, 09 Apr 2026 02:28:18 +0000

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:

By default, the chart installs in Simple Scalable mode. For the best possible experience in production, we now recommend deploying Loki in microservices mode. To understand the differences between deployment methods, see the Loki 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 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 the rollout-operator subchart. 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):

ingester:
  zoneAwareReplication:
    enabled: false

Pattern ingester

The chart includes an optional pattern ingester component (patternIngester) for detecting and extracting log patterns. It is disabled by default (patternIngester.replicas: 0). To enable it as a standalone component in microservices mode, set patternIngester.replicas to a non-zero value. In other modes, enable it in the Loki configuration:

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 and alerts (monitoring.rules.enabled): Creates PrometheusRule resources with pre-configured recording rules and alerts (for example, LokiRequestErrors, LokiRequestPanics, LokiRequestLatency).
Dashboards (monitoring.dashboards.enabled): Creates ConfigMaps containing Grafana dashboards for monitoring Loki.

These built-in monitoring resources are disabled by default. For a more comprehensive monitoring setup, Loki clusters can also be monitored using the meta-monitoring stack, which monitors the logs, metrics, and traces of the Loki cluster. There are two deployment options for this stack, see the installation instructions within Monitoring.

Note
The Kubernetes Monitoring Helm chart replaces the monitoring section of the Loki Helm chart which is now DEPRECATED. Refer to the Monitoring section for more information.

Canary

This chart installs the Loki Canary app 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, 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). The gateway must be enabled if an Ingress is required, since the Ingress exposes the gateway only. 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, this chart configures in-memory caching. If that caching does not work for your deployment, you should setup memcache.

Install the monolithic Helm chart

Thu, 09 Apr 2026 02:28:18 +0000

Install the monolithic Helm chart

This Helm Chart installation deploys Grafana Loki in monolithic mode within a Kubernetes cluster.

Note
As of March 16, 2026, the Loki Helm Chart is being maintained by Grafana Champions and the Grafana Community in the Grafana-community/helm-charts repository. Please open issues and pull requests for the chart against the Grafana-community repo.

Tip
With the move to the Grafana-community repository, the chart numbering has changed. Major version updates signal breaking changes in the chart. For more information, refer to the README.

Prerequisites

Helm 3 or above. See Installing Helm.
A running Kubernetes cluster.

Single Replica or Multiple Replicas

There are two ways to deploy Loki in monolithic mode:

Single Replica: Run Loki with a single replica. This mode is useful for testing and development or if you are planning to run Loki as a meta-monitoring system.
Multiple Replicas: Run Loki with multiple replicas. This mode is useful for high availability. This mode is less economical than microservice mode, but it is simpler to operate. We recommend running at least three replicas for high availability.

Once you have selected how many replicas you would like to deploy, choose the appropriate values.yaml configuration file below and then continue with the deployment steps.

Single Replica

Deploying the Helm chart with a single replica deploys the following components:

Loki (1 replica)
Loki Canary (1 DaemonSet)
Loki Gateway (1 NGINX replica)
Chunks cache (1 StatefulSet)
Results cache (1 StatefulSet)
Minio (optional, if minio.enabled=true)

Create the configuration file values.yaml:

Note
You must specify commonConfig.replication_factor: 1 if you are only using 1 replica, otherwise requests will fail.

loki:
  commonConfig:
    replication_factor: 1
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
  ruler:
    enable_api: true

minio:
  enabled: true
      
deploymentMode: SingleBinary

singleBinary:
  replicas: 1

# Zero out replica counts of other deployment modes
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

ingester:
  replicas: 0
querier:
  replicas: 0
queryFrontend:
  replicas: 0
queryScheduler:
  replicas: 0
distributor:
  replicas: 0
compactor:
  replicas: 0
indexGateway:
  replicas: 0
bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

In this configuration, we are deploying Loki with MinIO as the object storage. We recommend configuring object storage via cloud provider or pointing Loki at a MinIO cluster for production deployments.

Multiple Replicas

Deploying the Helm chart with multiple replicas deploys the following components:

Loki (3 replicas)
Loki Canary (1 DaemonSet)
Loki Gateway (1 NGINX replica)
Chunks cache (1 StatefulSet)
Results cache (1 StatefulSet)
Minio (optional, if minio.enabled=true)

Create the configuration file values.yaml:

Note
If you set the singleBinary.replicas value to 2 or more, this chart configures Loki to run a single binary in a replicated, highly available mode. When running replicas of a single binary, you must configure object storage.

loki:
  commonConfig:
    replication_factor: 3
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
  ruler:
    enable_api: true

minio:
  enabled: true
      
deploymentMode: SingleBinary

singleBinary:
  replicas: 3

# Zero out replica counts of other deployment modes
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

ingester:
  replicas: 0
querier:
  replicas: 0
queryFrontend:
  replicas: 0
queryScheduler:
  replicas: 0
distributor:
  replicas: 0
compactor:
  replicas: 0
indexGateway:
  replicas: 0
bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

In this configuration, we need to make sure to update the commonConfig.replication_factor and singleBinary.replicas to the desired number of replicas. We are deploying Loki with MinIO as the object storage. We recommend configuring object storage via cloud provider or pointing Loki at a MinIO cluster for production deployments.

Deploying the Helm chart for development and testing

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```
Deploy Loki using the configuration file values.yaml:
Bash
```
 helm install loki grafana-community/loki -f values.yaml
```

Install or upgrade the Loki deployment.

To install:

helm install --values values.yaml loki grafana-community/loki

To upgrade:

helm upgrade --values values.yaml loki grafana-community/loki

Verify that Loki is running:
Bash
```
kubectl get pods -n loki
```

Object Storage Configuration

After testing Loki with MinIO, we recommend configuring Loki with an object storage provider. The following examples shows how to configure Loki with different object storage providers:

Caution
When deploying Loki using S3 Storage DO NOT use the default bucket names; chunk, ruler and admin. Choose a unique name for each bucket. For more information see the following security update. This caution does not apply when you are using MinIO. When using MinIO we recommend using the default bucket names.

loki:
  commonConfig:
    replication_factor: 3
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: <AWS region your bucket is in, for example, `eu-west-2`>
      bucketnames: <Your AWS bucket for chunk, for exaxmple,  `aws-loki-dev-chunk`>
      s3forcepathstyle: false
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention

  storage:
    type: s3
    bucketNames:
      chunks: <Your AWS bucket for chunk, for example, `aws-loki-dev-chunk`>
      ruler: <Your AWS bucket for ruler, for example, `aws-loki-dev-ruler`>
      admin: <Your AWS bucket for admin, for example, `aws-loki-dev-admin`>
    s3:
      # s3 URL can be used to specify the endpoint, access key, secret key, and bucket name this works well for S3 compatible storages or are hosting Loki on-premises and want to use S3 as the storage backend. Either use the s3 URL or the individual fields below (AWS endpoint, region, secret).
      s3: s3://access_key:secret_access_key@custom_endpoint/bucket_name
      # AWS endpoint URL
      endpoint: <your-endpoint>
      # AWS region where the S3 bucket is located
      region: <your-region>
      # AWS secret access key
      secretAccessKey: <your-secret-access-key>
      # AWS access key ID
      accessKeyId: <your-access-key-id>
      # AWS signature version (e.g., v2 or v4)
      signatureVersion: <your-signature-version>
      # Forces the path style for S3 (true/false)
      s3ForcePathStyle: false
      # Allows insecure (HTTP) connections (true/false)
      insecure: false
      # HTTP configuration settings
      http_config: {}

# Disable minio storage
minio:
  enabled: false

deploymentMode: SingleBinary

singleBinary:
  replicas: 3
  persistence:
    storageClass: gp2
    accessModes:
      - ReadWriteOnce
    size: 30Gi

# Zero out replica counts of other deployment modes
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

ingester:
  replicas: 0
querier:
  replicas: 0
queryFrontend:
  replicas: 0
queryScheduler:
  replicas: 0
distributor:
  replicas: 0
compactor:
  replicas: 0
indexGateway:
  replicas: 0
bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: azure
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  ingester:
    chunk_encoding: snappy

  storage:
    type: azure
    azure:
      # Name of the Azure Blob Storage account
      accountName: <your-account-name>
      # Key associated with the Azure Blob Storage account
      accountKey: <your-account-key>
      # Comprehensive connection string for Azure Blob Storage account (Can be used to replace endpoint, accountName, and accountKey)
      connectionString: <your-connection-string>
      # Flag indicating whether to use Azure Managed Identity for authentication
      useManagedIdentity: false
      # Flag indicating whether to use a federated token for authentication
      useFederatedToken: false
      # Client ID of the user-assigned managed identity (if applicable)
      userAssignedId: <your-user-assigned-id>
      # Timeout duration for requests made to the Azure Blob Storage account (in seconds)
      requestTimeout: <your-request-timeout>
      # Domain suffix of the Azure Blob Storage service endpoint (e.g., core.windows.net)
      endpointSuffix: <your-endpoint-suffix>
    bucketNames:
      chunks: "chunks"
      ruler: "ruler"
      admin: "admin"

# Disable minio storage
minio:
  enabled: false

deploymentMode: SingleBinary

singleBinary:
  replicas: 3
  persistence:
    storageClass: gp2
    accessModes:
      - ReadWriteOnce
    size: 30Gi

# Zero out replica counts of other deployment modes
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

ingester:
  replicas: 0
querier:
  replicas: 0
queryFrontend:
  replicas: 0
queryScheduler:
  replicas: 0
distributor:
  replicas: 0
compactor:
  replicas: 0
indexGateway:
  replicas: 0
bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

To configure other storage providers, refer to the Helm Chart Reference.

Deploying the Loki Helm chart to a Production Environment

Note
We are actively working on providing more guides for deploying Loki in production.

We recommend running Loki at scale within a cloud environment like AWS, Azure, or GCP. The below guides will show you how to deploy a minimally viable production environment.

Deploy Loki on AWS

Next Steps

Configure an agent to send log data to Loki.
Monitor the Loki deployment using the Meta Monitoring Helm chart

Install the microservice Helm chart

Thu, 09 Apr 2026 02:28:18 +0000

Install the microservice Helm chart

This Helm Chart deploys Grafana Loki on Kubernetes.

Note
As of March 16, 2026, the Loki Helm Chart is being maintained by Grafana Champions and the Grafana Community in the Grafana-community/helm-charts repository. Please open issues and pull requests for the chart against the Grafana-community repo.

Tip
With the move to the Grafana-community repository, the chart numbering has changed. Major version updates signal breaking changes in the chart. For more information, refer to the README.

This Helm chart deploys Loki to run Loki in microservice mode within a Kubernetes cluster. The microservices deployment is also referred to as a Distributed deployment. The microservices deployment mode runs components of Loki as distinct processes.

The default Helm chart deploys the following components:

Compactor component (1 replica): Compacts and processes stored data.
Distributor component (3 replicas, maxUnavailable: 2): Distributes incoming requests. Up to 2 replicas can be unavailable during updates.
IndexGateway component (2 replicas, maxUnavailable: 1): Handles indexing. Up to 1 replica can be unavailable during updates.
Ingester component (3 replicas per zone): Handles ingestion of data. By default, zone-aware replication is enabled, creating three StatefulSets (zone-a, zone-b, zone-c) with one replica each.
Querier component (3 replicas, maxUnavailable: 2): Processes queries. Up to 2 replicas can be unavailable during updates.
QueryFrontend component (2 replicas, maxUnavailable: 1): Manages frontend queries. Up to 1 replica can be unavailable during updates.
QueryScheduler component (2 replicas): Schedules queries.
Gateway (1 NGINX replica): Exposes the Loki API and proxies requests to the correct Loki components.
Loki Canary (1 DaemonSet): Verifies the Loki deployment is in a healthy state.
Chunks cache (1 replica): Caches chunks data using memcached.
Results cache (1 replica): Caches query results using memcached.

Note
Zone-aware replication is enabled by default for ingesters. This creates three ingester StatefulSets (one per zone) and requires the rollout-operator subchart. To disable zone-aware replication (for example, in development), set ingester.zoneAwareReplication.enabled: false in your values.yaml.

Note
We do not recommend running in microservices mode with filesystem storage. For the purpose of this guide, we will use MinIO as the object storage to provide a complete example.

Prerequisites

Helm 3 or above. See Installing Helm.
A running Kubernetes cluster (must have at least 3 nodes).

Deploying the Helm chart for development and testing

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```

Create the configuration file values.yaml. The example below illustrates how to deploy Loki in test mode using MinIO as storage:

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  ingester:
    chunk_encoding: snappy
  querier:
    # Default is 4, if you have enough memory and CPU you can increase, reduce if OOMing
    max_concurrent: 4
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true


deploymentMode: Distributed

ingester:
  replicas: 3 # To ensure data durability with replication
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 3 # Improve query performance via parallelism
  maxUnavailable: 2
queryFrontend:
  replicas: 2
  maxUnavailable: 1
queryScheduler:
  replicas: 2
distributor:
  replicas: 3 
  maxUnavailable: 2
compactor:
  replicas: 1
indexGateway:
  replicas: 2
  maxUnavailable: 1

bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

# This exposes the Loki gateway so it can be written to and queried externaly
gateway:
  service:
    type: LoadBalancer


# Enable minio for storage
minio:
  enabled: true

Install or upgrade the Loki deployment.

To install:

helm install --values values.yaml loki grafana-community/loki

To upgrade:

helm upgrade --values values.yaml loki grafana-community/loki

Verify that Loki is running:

kubectl get pods -n loki

The output should an output similar to the following:

  loki-canary-8thrx                      1/1     Running   0          167m
  loki-canary-h965l                      1/1     Running   0          167m
  loki-canary-th8kb                      1/1     Running   0          167m
  loki-chunks-cache-0                    2/2     Running   0          167m
  loki-compactor-0                       1/1     Running   0          167m
  loki-compactor-1                       1/1     Running   0          167m
  loki-distributor-7c9bb8f4dd-bcwc5      1/1     Running   0          167m
  loki-distributor-7c9bb8f4dd-jh9h8      1/1     Running   0          167m
  loki-distributor-7c9bb8f4dd-np5dw      1/1     Running   0          167m
  loki-gateway-77bc447887-qgc56          1/1     Running   0          167m
  loki-index-gateway-0                   1/1     Running   0          167m
  loki-index-gateway-1                   1/1     Running   0          166m
  loki-ingester-zone-a-0                 1/1     Running   0          167m
  loki-ingester-zone-b-0                 1/1     Running   0          167m
  loki-ingester-zone-c-0                 1/1     Running   0          167m
  loki-minio-0                           1/1     Running   0          167m
  loki-querier-bb8695c6d-bv9x2           1/1     Running   0          167m
  loki-querier-bb8695c6d-bz2rw           1/1     Running   0          167m
  loki-querier-bb8695c6d-z9qf8           1/1     Running   0          167m
  loki-query-frontend-6659566b49-528j5   1/1     Running   0          167m
  loki-query-frontend-6659566b49-84jtx   1/1     Running   0          167m
  loki-query-frontend-6659566b49-9wfr7   1/1     Running   0          167m
  loki-query-scheduler-f6dc4b949-fknfk   1/1     Running   0          167m
  loki-query-scheduler-f6dc4b949-h4nwh   1/1     Running   0          167m
  loki-query-scheduler-f6dc4b949-scfwp   1/1     Running   0          167m
  loki-results-cache-0                   2/2     Running   0          167m

Object Storage Configuration

After testing Loki with MinIO, we recommend configuring Loki with an object storage provider. The following examples shows how to configure Loki with different object storage providers:

Caution
When deploying Loki using S3 Storage DO NOT use the default bucket names; chunk, ruler and admin. Choose a unique name for each bucket. For more information see the following security update. This caution does not apply when you are using MinIO. When using MinIO we recommend using the default bucket names.

# Example configuration for Loki with S3 storage

loki:
  schemaConfig:
    configs:
      - from: 2024-04-01
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: <AWS region your bucket is in, for example, `eu-west-2`>
      bucketnames: <Your AWS bucket for chunk, for example, `aws-loki-dev-chunk`>
      s3forcepathstyle: false
  ingester:
    chunk_encoding: snappy
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention
  querier:
    max_concurrent: 4

  storage:
    type: s3
    bucketNames:
      chunks: <Your AWS bucket for chunk, for example, `aws-loki-dev-chunk`>
      ruler: <Your AWS bucket for ruler, for example,  `aws-loki-dev-ruler`>
      admin: <Your AWS bucket for admin, for example,  `aws-loki-dev-admin`>
    s3:
      # s3 URL can be used to specify the endpoint, access key, secret key, and bucket name this works well for S3 compatible storage or if you are hosting Loki on-premises and want to use S3 as the storage backend. Either use the s3 URL or the individual fields below (AWS endpoint, region, secret).
      s3: s3://access_key:secret_access_key@custom_endpoint/bucket_name
      # AWS endpoint URL
      endpoint: <your-endpoint>
      # AWS region where the S3 bucket is located
      region: <your-region>
      # AWS secret access key
      secretAccessKey: <your-secret-access-key>
      # AWS access key ID
      accessKeyId: <your-access-key-id>
      # AWS signature version (e.g., v2 or v4)
      signatureVersion: <your-signature-version>
      # Forces the path style for S3 (true/false)
      s3ForcePathStyle: false
      # Allows insecure (HTTP) connections (true/false)
      insecure: false
      # HTTP configuration settings
      http_config: {}

deploymentMode: Distributed

# Disable minio storage
minio:
  enabled: false

ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 3
  maxUnavailable: 2
queryFrontend:
  replicas: 2
  maxUnavailable: 1
queryScheduler:
  replicas: 2
distributor:
  replicas: 3
  maxUnavailable: 2
compactor:
  replicas: 1
indexGateway:
  replicas: 2
  maxUnavailable: 1

bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

# Example configuration for Loki with Azure Blob Storage

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: azure
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  ingester:
    chunk_encoding: snappy
  tracing:
    enabled: true
  querier:
    max_concurrent: 4

  storage:
    type: azure
    azure:
      # Name of the Azure Blob Storage account
      accountName: <your-account-name>
      # Key associated with the Azure Blob Storage account
      accountKey: <your-account-key>
      # Comprehensive connection string for Azure Blob Storage account (Can be used to replace endpoint, accountName, and accountKey)
      connectionString: <your-connection-string>
      # Flag indicating whether to use Azure Managed Identity for authentication
      useManagedIdentity: false
      # Flag indicating whether to use a federated token for authentication
      useFederatedToken: false
      # Client ID of the user-assigned managed identity (if applicable)
      userAssignedId: <your-user-assigned-id>
      # Timeout duration for requests made to the Azure Blob Storage account (in seconds)
      requestTimeout: <your-request-timeout>
      # Domain suffix of the Azure Blob Storage service endpoint (e.g., core.windows.net)
      endpointSuffix: <your-endpoint-suffix>
    bucketNames:
      chunks: "chunks"
      ruler: "ruler"
      admin: "admin"
deploymentMode: Distributed

ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 3
  maxUnavailable: 2
queryFrontend:
  replicas: 2
  maxUnavailable: 1
queryScheduler:
  replicas: 2
distributor:
  replicas: 3
  maxUnavailable: 2
compactor:
  replicas: 1
indexGateway:
  replicas: 2
  maxUnavailable: 1

bloomPlanner:
  replicas: 0
bloomBuilder:
  replicas: 0
bloomGateway:
  replicas: 0

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

To configure other storage providers, refer to the Helm Chart Reference.

Deploying the Loki Helm chart to a Production Environment

Note
We are actively working on providing more guides for deploying Loki in production.

We recommend running Loki at scale within a cloud environment like AWS, Azure, or GCP. The below guides will show you how to deploy a minimally viable production environment.

Next Steps

Configure an agent to send log data to Loki.
Monitor the Loki deployment using the Meta Monitoring Helm chart

Install the simple scalable Helm chart

Thu, 09 Apr 2026 02:28:18 +0000

Install the simple scalable Helm chart

This Helm Chart deploys Grafana Loki in simple scalable mode within a Kubernetes cluster.

Note
As of March 16, 2026, the Loki Helm Chart is being maintained by Grafana Champions and the Grafana Community in the Grafana-community/helm-charts repository. Please open issues and pull requests for the chart against the Grafana-community repo. 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.

Tip
With the move to the Grafana-community repository, the chart numbering has changed. Major version updates signal breaking changes in the chart. For more information, refer to the README.

This chart configures Loki to run read, write, and backend targets in a scalable mode. Loki’s simple scalable deployment mode separates execution paths into read, write, and backend targets.

The default Helm chart deploys the following components:

Read component (3 replicas)
Write component (3 replicas)
Backend component (3 replicas)
Loki Canary (1 DaemonSet)
Gateway (1 NGINX replica)
Minio (optional, if minio.enabled=true)
Chunks cache (1 replica)
Results cache (1 replica)

Note
We do not recommended running scalable mode with filesystem storage. For the purpose of this guide, we will use MinIO as the object storage to provide a complete example.

Prerequisites

Helm 3 or above. See Installing Helm.
A running Kubernetes cluster (must have at least 3 nodes).

Deploying the Helm chart for development and testing

The following steps show how to deploy the Loki Helm chart in simple scalable mode using the included MinIO as the storage backend. Our recommendation is to start here for development and testing purposes. Then configure Loki with an object storage provider when moving to production.

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```

Create the configuration file values.yaml. The example below illustrates how to deploy Loki in test mode using MinIO as storage:

  loki:
    schemaConfig:
      configs:
        - from: "2024-04-01"
          store: tsdb
          object_store: s3
          schema: v13
          index:
            prefix: loki_index_
            period: 24h
    ingester:
      chunk_encoding: snappy
    querier:
      # Default is 4, if you have enough memory and CPU you can increase, reduce if OOMing
      max_concurrent: 4
    pattern_ingester:
      enabled: true
    limits_config:
      allow_structured_metadata: true
      volume_enabled: true

  deploymentMode: SimpleScalable

  backend:
    replicas: 2
  read:
    replicas: 2
  write:
    replicas: 3 # To ensure data durability with replication

  # Enable minio for storage
  minio:
    enabled: true

  gateway:
    service:
      type: LoadBalancer

Install or upgrade the Loki deployment.

To install:

helm install --values values.yaml loki grafana-community/loki

To upgrade:

helm upgrade --values values.yaml loki grafana-community/loki

Object Storage Configuration

After testing Loki with MinIO, we recommend configuring Loki with an object storage provider. The following examples shows how to configure Loki with different object storage providers:

Caution
When deploying Loki using S3 Storage DO NOT use the default bucket names; chunk, ruler and admin. Choose a unique name for each bucket. For more information see the following security update. This caution does not apply when you are using MinIO. When using MinIO we recommend using the default bucket names.

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: <AWS region your bucket is in, for example, `eu-west-2`>
      bucketnames: <Your AWS bucket for chunk, for example, `aws-loki-dev-chunk`>
      s3forcepathstyle: false
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention
  querier:
    max_concurrent: 4

  storage:
    type: s3
    bucketNames:
      chunks: <Your AWS bucket for chunk, for example, `aws-loki-dev-chunk`>
      ruler: <Your AWS bucket for ruler, for example,  `aws-loki-dev-ruler`>
      admin: <Your AWS bucket for admin, for example,  `aws-loki-dev-admin`>
    s3:
      # s3 URL can be used to specify the endpoint, access key, secret key, and bucket name this works well for S3 compatible storages or if you are hosting Loki on-premises and want to use S3 as the storage backend. Either use the s3 URL or the individual fields below (AWS endpoint, region, secret).
      s3: s3://access_key:secret_access_key@custom_endpoint/bucket_name
      # AWS endpoint URL
      endpoint: <YOUR_ENDPOINT>
      # AWS region where the S3 bucket is located
      region: <YOUR_REGION>
      # AWS secret access key
      secretAccessKey: <YOUR_SECRET_ACCESS_KEY>
      # AWS access key ID
      accessKeyId: <YOUR_ACCESS_KEY_ID>
      # AWS signature version (e.g., v2 or v4)
      signatureVersion: <YOUR_SIGNATURE_VERSION>
      # Forces the path style for S3 (true/false)
      s3ForcePathStyle: false
      # Allows insecure (HTTP) connections (true/false)
      insecure: false
      # HTTP configuration settings
      http_config: {}

deploymentMode: SimpleScalable

backend:
  replicas: 3
read:
  replicas: 3
write:
  replicas: 3

# Disable minio storage
minio:
  enabled: false


loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: azure
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  ingester:
    chunk_encoding: snappy
  tracing:
    enabled: true
  querier:
    max_concurrent: 4

  storage:
    type: azure
    azure:
      # Name of the Azure Blob Storage account
      accountName: <YOUR_ACCOUNT_NAME>
      # Key associated with the Azure Blob Storage account
      accountKey: <YOUR_ACCOUNT_KEY>
      # Comprehensive connection string for Azure Blob Storage account (Can be used to replace endpoint, accountName, and accountKey)
      connectionString: <YOUR_CONNECTION_STRING>
      # Flag indicating whether to use Azure Managed Identity for authentication
      useManagedIdentity: false
      # Flag indicating whether to use a federated token for authentication
      useFederatedToken: false
      # Client ID of the user-assigned managed identity (if applicable)
      userAssignedId: <YOUR_USER_ASSIGNED_ID>
      # Timeout duration for requests made to the Azure Blob Storage account (in seconds)
      requestTimeout: <YOUR_REQUEST_TIMEOUT>
      # Domain suffix of the Azure Blob Storage service endpoint (e.g., core.windows.net)
      endpointSuffix: <YOUR_ENDPOINT_SUFFIX>
    bucketNames:
      chunks: "chunks"
      ruler: "ruler"
      admin: "admin"

deploymentMode: SimpleScalable

backend:
  replicas: 3
read:
  replicas: 3
write:
  replicas: 3

# Disable minio storage
minio:
  enabled: false

To configure other storage providers, refer to the Helm Chart Reference.

Next Steps

Configure an agent to send log data to Loki.
Monitor the Loki deployment using the Meta Monitoring Helm chart

Cloud Deployment Guides

Thu, 09 Apr 2026 02:28:18 +0000

Cloud Deployment Guides

The following guides provide step-by-step instructions for deploying Loki on cloud providers:

Configure storage

Thu, 09 Apr 2026 02:28:18 +0000

Configure storage

The scalable installation requires a managed object store such as AWS S3 or Google Cloud Storage or a self-hosted store such as Minio. The single binary installation can use the filesystem for storage, but we recommend configuring object storage via cloud provider or pointing Loki at a MinIO cluster for production deployments.

This guide assumes Loki will be installed in one of the modes above and that a values.yaml has been created.

To use a managed object store:

In the values.yaml file, set the value for storage.type to azure, gcs, or s3.
Configure the storage client under loki.storage.azure, loki.storage.gcs, or loki.storage.s3.

To install Minio alongside Loki:

Change the configuration in values.yaml:
- Enable Minio
YAML
```
minio:
  enabled: true
```

To use Thanos object store clients (experimental):

Loki supports using Thanos-compatible storage clients as an alternative to the built-in storage clients. This is configured via loki.storage.use_thanos_objstore and will become the default in a future release.

Enable Thanos object store in values.yaml:

loki:
  storage:
    use_thanos_objstore: true
    object_store:
      type: s3  # Valid options: s3, gcs, azure
      s3:
        endpoint: <YOUR_ENDPOINT>
        region: <YOUR_REGION>

Configure the storage client under loki.storage.object_store.s3, loki.storage.object_store.gcs, or loki.storage.object_store.azure.

To grant access to S3 via an IAM role without providing credentials:

Provision an IAM role, policy and S3 bucket as described in Storage.
- If the Terraform module was used note the annotation emitted by terraform output -raw annotation.

Add the IAM role annotation to the service account in values.yaml:

serviceAccount:
  annotations:
    "eks.amazonaws.com/role-arn": "arn:aws:iam::<account id>:role/<role name>"

Configure the storage:

loki:
  storage:
    type: "s3"
    s3:
      region: eu-central-1
    bucketNames:
      chunks: <bucket name>
      ruler: <bucket name>
      admin: <bucket name>

Note that endpoint, secretAccessKey and accessKeyId have been omitted.

Monitoring

Thu, 09 Apr 2026 02:28:18 +0000

Monitoring

Warning
We no longer recommend using the meta-monitoring Helm chart to monitor Loki. To consolidate monitoring efforts into one Helm chart, Grafana Labs recommends using the Kubernetes monitoring Helm chart. Instructions for setting up the Kubernetes monitoring Helm chart can be found under Manage.