Difference between helm charts loki and loki-stack

Grafana Loki
1

Hi there,

Can someone explain what are the difference(s) between the helm chart loki and the one called loki-stack ?

Looking at the values of the former, the values cover a complete loki configuration where the latter is quite empy

# values for loki in loki-stack
loki:
  enabled: true
  isDefault: true
  url: http://{{(include "loki.serviceName" .)}}:{{ .Values.loki.service.port }}
  readinessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  livenessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  datasource:
    jsonData: "{}"
    uid: ""

I can’t find documentation explaining why choosing one over the other, and how use loki-stack if this the correct to use (yes I’m a helm newbie)

Best

2 Likes
2

Hi @bmm_alc - loki-stack is no longer maintained and shouldn’t be used. The differece. is just how they’re put together, and that loki-stack depended on a different helm chart that has aged out.

The right way to go is the loki helmchart if you want SSD mode or loki-distributed if you’re interested on microservices mode.

More information on the modes (SSD vs. microservices) is here:

1 Like
3

Thanks for the clarification @davidallen5

I would suggest to add the information loki-stack is deprecated on the page loki-stack 2.9.10 · grafana/grafana.

4 Likes
4

a couple of sugestions

1 Like
5

@davidallen5 Repeating the request above, loki-stack should be marked as deprecated or at least have a warning in the description here. Seeing updates pushed to it regularly made me think it might be revived, but I had seen the source on GitHub previously saying it was deprecated.

6

hi @davidallen5 , while I am trying to setup loki-helm chart, I am unable to add any service as datasource in grafana. I remember sometime back we had a setup where we used to add service named query or something to add as data source in grafana if all of them exist in same cluster.
Really need some help as I am stuck with it.
I Try to explain this with example. If we go with loki-distributed, then we add “http://loki-loki-distributed-query-frontend.loki:3100” as url in loki datasource.

7

For everyone in this thread there’s also this education video about all of the loki deployment options – this is up to date as of May 2024

1 Like
8

UPDATE: March 2025

The official helm chart for Loki is called: loki. We would suggest not using the following other helm charts:

  • loki-stack
  • loki-distributed (built by the community but hasn’t been worked on since 2.9.0)

The loki helm chart supports all deployment modes of Loki.

If you plan to deploy Loki in a cloud environment checkout our current cloud deployment guides

If you are deploying locally with helm, check out this guide.

Please note that we recommend running Loki either in Single Binary (Monolithic mode) for small to medium workloads or Distributed (Microservice mode) for production use cases.

Make sure to check our new sizing guide to appropriately size your production cluster.

SSD (Simple Scalable Deployment): is still available, but we do not recommend start with this deployment.

If you are using LLMs to build your Loki values files make sure to check that parameters it creates are available in either the Loki Helm values reference or the Loki configuration reference. Most of the time LLMs will generate you a loki-stack or loki-distributed example, which can cause frustration.

9

I would like to know SSD is not recommend anymore OR just not for starter. I thought depends on log size and throughput, you can swtich between Single Binary, SSD and Distributed.

10

I’m mostly talking about new users; we’re looking at putting together a migration guide right now for SSD. The issue is one of complexity tradeoff. From my perspective when people want “simple kick the tires” you want monolithic mode, and if you need a flexible scalable deployment you want microservices. The SSD was sort of like a tradeoff point in the middle, which could be argued to be “too complex for the flexibility it offered, and not simple enough to be easy for starters”. I would think of the architectural flexibility you get with microservices mode as a kind of superset of SSD (i.e. microservices mode can do everything SSD can do and more, simply “more degrees of freedom for those who can tolerate the complexity”). As with most software, if you want to do really powerful scalable things, there’s a certain amount of complexity one needs to tolerate.

For anyone else following this thread, if you don’t know what I mean by scalability, components, microservices, etc. etc. etc. – you can get a lot more great information here: