Skip to main content

Helm deployment

Install Loki-VL-proxy with Helm and pick the right topology on day one

The chart already covers the practical topologies most teams need: a basic Deployment, a StatefulSet with persistent disk cache, a multi-replica peer-cache fleet, and collector-first OTLP export.

Deployment first
Start with the smallest topology that proves the path
Do not overbuild before traffic exists.
Stateful cache when needed
Persistent disk cache is the first real scaling lever for larger hotsets
Useful for repeated metadata and query reads.
Peer cache fleet
Multiple replicas can reuse results instead of refetching them independently
Good for overlapping dashboard traffic.
Scrape or OTLP
The chart supports both metrics operating models
Dashboards stay aligned across both.

Basic Deployment

Start here when you want a single replica proving the Loki read path into VictoriaLogs and you do not need persistent cache yet.

helm upgrade --install loki-vl-proxy oci://ghcr.io/reliablyobserve/charts/loki-vl-proxy \
  --version <release> \
  --set extraArgs.backend=http://victorialogs:9428

StatefulSet with persistent disk cache

Use this when repeated reads are too large for memory-only cache and you want useful cache survival across pod restarts.

helm upgrade --install loki-vl-proxy oci://ghcr.io/reliablyobserve/charts/loki-vl-proxy \
  --version <release> \
  --set workload.kind=StatefulSet \
  --set persistence.enabled=true \
  --set persistence.size=20Gi \
  --set extraArgs.backend=http://victorialogs:9428 \
  --set extraArgs.disk-cache-max-bytes=20Gi

Multi-replica fleet with peer cache

Use this when several replicas will receive similar traffic and you want the fleet to reuse results through the peer-cache ring.

helm upgrade --install loki-vl-proxy oci://ghcr.io/reliablyobserve/charts/loki-vl-proxy \
  --version <release> \
  --set replicaCount=3 \
  --set peerCache.enabled=true \
  --set extraArgs.backend=http://victorialogs:9428

Collector-first OTLP metrics export

Use this when your environment standardizes on OTLP push rather than Prometheus scrape for application telemetry.

helm upgrade --install loki-vl-proxy oci://ghcr.io/reliablyobserve/charts/loki-vl-proxy \
  --version <release> \
  --set extraArgs.backend=http://victorialogs:9428 \
  --set-string extraArgs.otlp-endpoint=http://otel-collector.monitoring.svc.cluster.local:4318/v1/metrics \
  --set-string extraArgs.server\.register-instrumentation=false

Pick Deployment when

  • You are still validating translation and datasource behavior.
  • Cache persistence is not yet part of the runtime requirement.
  • You want the simplest rollout and rollback story.

Pick StatefulSet when

  • Repeated query and metadata traffic benefits from larger retained cache.
  • You need predictable disk-backed cache sizing with `disk-cache-max-bytes`.
  • You want the proxy to come back warm instead of rebuilding cache only from memory.

Add peer cache when

  • Several replicas serve overlapping dashboard or Explore traffic.
  • You want one warm pod to reduce repeated VictoriaLogs work for the fleet.
  • You are already operating 2+ replicas with PDB and sane scaling rules.

Keep the chart opinionated, not magical

  • You still need to choose label translation and metadata modes deliberately.
  • You still need to validate Grafana Explore, Drilldown, and hot dashboards.
  • You should watch route-aware cache and latency signals before aggressive cutover.