Vector

Last reviewed Aug 26, 2026 · 804 words

Vector is the piece that moves logs from your containers to wherever you store them, and it does that in roughly 64 MB of RAM from a single static binary. It stores nothing. If you came here looking for a place to put logs, you want Loki, VictoriaLogs, or OpenSearch; if you already have one of those and are feeding it with Promtail, Fluent Bit, or a shell script, Vector is the upgrade. Grafana has deprecated Promtail in favour of Alloy, so a lot of homelabs are picking a shipper right now, and Vector is the one I'd pick.

It replaces Promtail and Fluent Bit, not Loki

Every Vector config is three lists: sources (where events come from), transforms (what you do to them), and sinks (where they go). Sources include Docker logs, journald, files, syslog, and a Prometheus scraper; sinks include Loki, VictoriaLogs, Elasticsearch and OpenSearch, ClickHouse, Kafka, S3, and Prometheus remote write. That breadth is the reason to choose it over Fluent Bit, which is equally light but whose configuration format punishes anything beyond forwarding. Vector also carries metrics and traces through the same pipeline, so one agent per host covers everything.

A Docker-logs-to-Loki pipeline is about 25 lines

sources:
  docker:
    type: docker_logs
  host:
    type: journald

transforms:
  parse:
    type: remap
    inputs: [docker]
    source: |
      .container = .container_name
      del(.container_name)
      parsed, err = parse_json(.message)
      if err == null { . = merge(., parsed) }

sinks:
  loki:
    type: loki
    inputs: [parse, host]
    endpoint: http://loki:3100
    encoding:
      codec: json
    labels:
      host: "{{ host }}"
      container: "{{ container }}"

Run it with the socket mounted:

services:
  vector:
    image: timberio/vector:latest-debian
    volumes:
      - ./vector.yaml:/etc/vector/vector.yaml:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /var/log/journal:/var/log/journal:ro
    restart: unless-stopped

Use the Debian image rather than Alpine if you want the journald source: it shells out to journalctl, which the Alpine image doesn't carry. Before restarting anything, vector validate vector.yaml catches typos, and vector tap parse shows you live events leaving a component, which is the fastest way I know to debug a pipeline.

VRL is the learning curve, and it earns its keep

The remap transform uses Vector Remap Language, a small typed language built for exactly this job. The learning curve the catalogue warns about is real, but it's a two-hour curve, not a two-week one. The design choice that matters: VRL is fallible by construction. parse_json(.message) can fail, so the compiler makes you handle the error, which is why the config above captures err. Once you've internalised that, a parser that would be 40 lines of Logstash grok is 5 lines of VRL, and it runs at native speed because the whole thing is compiled at startup. The vector vrl REPL lets you test expressions against sample events without touching the config, and the function reference on vector.dev is short enough to read in one sitting.

64 MB is the agent number; aggregators need more

As a per-host agent shipping a few hundred lines a second, Vector sits well under 100 MB and barely registers on CPU. Where it gets bigger is the aggregator role: one central Vector receiving from many agents, buffering, and fanning out to sinks. Buffers default to memory; switch the busy sinks to buffer: type: disk with a cap of a few GB so an outage on the Loki side doesn't cost you the events or the RAM. Plan on 256 MB to 512 MB for that role, plus the disk you gave the buffers. Vector's throughput claims are a strong point, but for a homelab the practical benefit is simpler: it never becomes the thing you notice in docker stats, which is more than I can say for a JVM-based shipper.

Datadog owns it; the licence is MPL-2.0

Datadog acquired the company behind Vector in 2021. The project is still developed in the open, the licence is MPL-2.0, and the Datadog sink is one of 50-odd rather than a funnel. I mention it because the question comes up, not because it has changed anything in practice. If it ever does, the config format is plain enough to migrate.

What I'd do

One Vector container per Docker host with the config above, shipping to a single Loki (or VictoriaLogs, if you'd rather skip Loki's label discipline) that Grafana reads from. Add a journald source so host-level events end up in the same place as container output, put disk buffers on the sink, and stop there. That covers the whole monitoring log story for a homelab in under 100 MB of RAM, and it will still be the right shipper if the storage end changes later.