Documentationbreadcrumb arrow Grafana Enterprise Logsbreadcrumb arrow Set upbreadcrumb arrow Installbreadcrumb arrow Install using Helmbreadcrumb arrow Install scalable Loki
Enterprise

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.

  1. Add the Grafana Community chart repository to Helm:

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

  2. Update the chart repository:

    Bash 
    helm repo update

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

    YAML 
      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

  4. Install or upgrade the Loki deployment.

  • To install:

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

  • To upgrade:

    Bash 
    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.

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

Gateway API

As an alternative to traditional Kubernetes Ingress, the Loki Helm chart supports Gateway API routes. There are two independent options depending on whether you want to keep the nginx gateway or bypass it entirely.

Option 1: Expose the nginx gateway via Gateway API

Use gateway.route to replace gateway.ingress with a Gateway API route that points to the nginx gateway. This keeps nginx as the proxy but exposes it through a Gateway API resource instead of a traditional Ingress.

YAML 
gateway:
  ingress:
    enabled: false  # disable traditional Ingress
  route:
    main:
      enabled: true
      kind: HTTPRoute
      parentRefs:
        - name: my-gateway
          namespace: gateway-namespace
      hostnames:
        - loki.example.com

Option 2: Bypass nginx and route directly to Loki services

Use the top-level route: key (mutually exclusive with the top-level ingress:) to route Gateway API traffic directly to Loki services, bypassing nginx. The chart auto-generates path-based rules that route write traffic to the write component and read traffic to the read component.

YAML 
route:
  main:
    enabled: true
    kind: HTTPRoute
    parentRefs:
      - name: my-gateway
        namespace: gateway-namespace
    hostnames:
      - loki.example.com

For both options, if apiVersion is not set, the chart auto-detects the latest available Gateway API version installed in the cluster. Supported route kinds include HTTPRoute, GRPCRoute, TCPRoute, TLSRoute, and UDPRoute.

Next Steps