Install (single-binary)

VL_VER=v1.10.0
curl -L "https://github.com/VictoriaMetrics/VictoriaLogs/releases/download/${VL_VER}/victoria-logs-linux-amd64-${VL_VER}.tar.gz" \
    | tar -xz
sudo install victoria-logs-prod /usr/local/bin/victoria-logs

# Run
sudo mkdir /var/lib/victoria-logs
sudo /usr/local/bin/victoria-logs \
    -storageDataPath=/var/lib/victoria-logs \
    -retentionPeriod=180d \
    -httpListenAddr=:9428

Or via Docker:

docker run -d --name vlogs \
    -p 127.0.0.1:9428:9428 \
    -v vlogs-data:/victoria-logs-data \
    victoriametrics/victoria-logs:latest \
    -storageDataPath=/victoria-logs-data \
    -retentionPeriod=90d

The ingestion protocols (lots of them)

VictoriaLogs accepts logs via many protocols:

  • Loki protocol — clients that push to Loki (Promtail, Grafana Alloy) work unchanged at /insert/loki/api/v1/push
  • OpenTelemetry OTLP — /insert/opentelemetry/v1/logs for OTLP HTTP, plus gRPC on a separate port
  • Elasticsearch bulk — /insert/elasticsearch/_bulk; ship from Filebeat / Logstash / Vector with the Elasticsearch sink unchanged
  • JSON Lines — raw /insert/jsonline
  • syslog — -syslog.listenAddr for RFC5424 / RFC3164
  • journald — via Fluent Bit or Vector's journald source

Practical: keep your existing log shipper; redirect to VictoriaLogs; query the new way.

The first ingest

# Drop a JSON line directly via curl
echo '{"_msg":"hello world","level":"info","app":"demo","_time":"2026-05-22T15:00:00Z"}' \
    | curl -X POST -H 'Content-Type: application/stream+json' \
        --data-binary @- \
        "http://localhost:9428/insert/jsonline?_stream_fields=app,level"

The _stream_fields query param tells VictoriaLogs which fields define a stream (think label cardinality from Loki). All other fields are indexed but not stream-cardinality.

Query with LogsQL

# Free-text
curl 'http://localhost:9428/select/logsql/query' --data-urlencode 'query=error'

# Filter by stream label
curl 'http://localhost:9428/select/logsql/query' --data-urlencode 'query={app="nginx"}'

# Combine: nginx logs with status 500 in the last hour
curl 'http://localhost:9428/select/logsql/query' \
    --data-urlencode 'query={app="nginx"} status:500' \
    --data-urlencode 'start=1h'

# Extract structured fields from unstructured logs
curl 'http://localhost:9428/select/logsql/query' \
    --data-urlencode 'query={app="api"} | extract "level=<level> path=<path>"'

# Stats
curl 'http://localhost:9428/select/logsql/query' \
    --data-urlencode 'query={app="nginx"} | stats by(status) count()'

LogsQL is more expressive than LogQL (Loki's query language) for free-form structured logs — the | extract + | stats + | top pipeline operators feel like a real query language, not "grep with extras."

Grafana integration

In Grafana → Data Sources → "VictoriaLogs" (the Grafana plugin). URL http://victorialogs:9428. Now Explore + dashboards can query LogsQL alongside Prometheus / Loki / Tempo.

For Loki-API compatibility: VictoriaLogs also serves the Loki API endpoints, so existing Loki dashboards in Grafana keep working if you redirect them to http://victorialogs:9428 as a Loki data source.

The shipping pattern with Vector

# vector.toml
[sources.journald]
  type = "journald"

[sources.docker]
  type = "docker_logs"

[transforms.parse]
  type = "remap"
  inputs = ["journald", "docker"]
  source = '''
  .level = .PRIORITY
  .container = .container_name
  '''

[sinks.victorialogs]
  type = "elasticsearch"
  inputs = ["parse"]
  endpoints = ["http://victorialogs:9428/insert/elasticsearch/"]
  bulk.index = "%Y-%m-%d"
  mode = "bulk"

Vector reads journald + Docker logs; tags them; ships to VictoriaLogs over the Elasticsearch bulk protocol.

Performance compared to alternatives

Per the VictoriaLogs benchmarks (published independently; verify yours):

  • ~10x smaller disk usage vs Elasticsearch on the same data
  • ~3-5x smaller vs Loki
  • ~10x faster query on full-text search vs Loki at moderate cardinality
  • Lower memory ceiling than Elasticsearch on the same retention period

The trade-off: smaller community + ecosystem than Loki + Elasticsearch in 2026. Tooling like Grafana works; less third-party integration than Elasticsearch.

Cluster mode

Like VictoriaMetrics, VictoriaLogs has a cluster mode for petabyte-scale (separate vlinsert / vlselect / vlstorage components). For most homelab + mid-fleet, single-binary mode is plenty.

What VictoriaLogs isn't

  • Not a full-text search engine like Elasticsearch is for non-log data — for ecommerce / docs search, MeiliSearch (see that tutorial) is purpose-built.
  • Not a metrics database — for time-series, use VictoriaMetrics or Prometheus.
  • Not a complete observability stack alone — pair with VictoriaMetrics + Grafana + (optionally) Tempo (see that tutorial) for metrics + logs + traces.

When VictoriaLogs is the right pick

  • Self-hosted observability where disk usage matters (single-host, small clusters, edge).
  • You already use VictoriaMetrics and want the same operational shape for logs.
  • You like LogsQL's structured-query approach over Loki's regex-and-streams model.

When Loki is still the right pick

  • You're already in the Grafana ecosystem deeply; Loki is the canonical fit.
  • You need the largest community + first-party Grafana integration.
  • You're committed to Loki's labels-and-streams pattern.