Graylog vs Grafana Loki for Homelab Logs: Full-Text Search or Cheap Labels
Jesse Cole
October 17, 2026
Logs are the part of a homelab that everyone ignores until something breaks. Then you are SSHing into three machines, running docker logs on a dozen containers, and scrolling through router syslog in a web page that only keeps the last hundred lines. A central log system fixes that: every machine, container and network device sends its logs to one place you can search.
Graylog and Grafana Loki are the two most common self-hosted choices beyond the simplest live-tail tools. They make opposite bets. Graylog indexes every word of every log line so searches are fast and flexible, at the cost of memory and disk. Loki indexes only a few labels and stores the text compressed, so it is cheap to run, but searching through text is slower. I ran both for months on the same set of home servers, and the bet you want depends on how you actually use logs.
Index everything, or index labels
Graylog is a log management platform. Logs arrive through inputs, such as syslog, GELF from Docker, or Beats agents, are processed through rules and pipelines that can parse fields, and are stored in a search engine, OpenSearch or Graylog’s own data node, alongside MongoDB for configuration. Every field is searchable, and full-text searches across large volumes return quickly. It has its own web interface with search, dashboards, streams and alerts. Graylog Open is the free edition.
Grafana Loki is a log store designed to be cheap. Instead of indexing log contents, it indexes a small set of labels, such as host, container, job or level, and stores the log lines compressed in chunks on disk or in object storage. Queries pick a set of streams by label and time range, then scan the text with filters. You query and view logs in Grafana using LogQL, a query language modelled on Prometheus’s.
| Graylog | Grafana Loki | |
|---|---|---|
| What is indexed | Every field and word | Labels only |
| Full-text search | Fast, across everything | Scans text within selected streams and time |
| Memory needs | Several GB, mostly the search engine | Hundreds of MB for a homelab |
| Disk use | Higher; indexes add size | Low; compressed chunks |
| Parsing and enrichment | Pipelines and extractors on ingest | Mostly at query time, plus collector processing |
| Interface | Graylog’s own web UI | Grafana |
| Parts to run | Graylog, MongoDB, search engine | Loki plus a collector; Grafana for viewing |
Sending logs in
Graylog accepts logs in many forms. Network devices and firewalls send syslog directly to a Graylog input. Docker can send container logs with the GELF logging driver, and servers can run Filebeat, Fluent Bit or a similar collector. Graylog’s pipelines then parse messages, for example splitting a firewall log into source, destination, port and action fields, so you can search and chart by them.
Loki receives logs from a collector. Grafana’s own collector, Grafana Alloy, has replaced the older Promtail as the recommended agent; Fluent Bit, Vector and a Docker logging driver also work. The collector attaches labels and ships lines to Loki. For network devices, a collector configured as a syslog receiver forwards their logs. Keep labels few and low in variety, such as host and service. Putting things like user IDs or request paths into labels creates huge numbers of streams and hurts performance.

Searching when something breaks
This is the heart of the trade-off. In Graylog, you type a search, such as an IP address, an error phrase or a username, across all logs for the last month, and results come back quickly with a histogram of when it occurred. You can filter by any parsed field, pivot to related messages, and save searches. For investigating “what happened around 3 a.m. and where did this IP appear?”, Graylog is excellent.
In Loki, you start by choosing streams with labels, such as {host="nas"} or {container="jellyfin"}, then add text filters. Narrow queries over hours or days are fast. Broad queries, like searching every log for one IP over a month, scan a lot of data and can be slow on modest hardware. LogQL is powerful once learned: you can parse lines at query time, extract fields, count matches and turn logs into metrics for graphs and alerts.
In practice, most homelab investigations are narrow: one service, one host, one evening. That is why Loki works well for so many people despite its limits on broad search.
What each one costs to run
Graylog’s search engine wants memory. A small single-node setup typically needs several gigabytes of RAM for the search engine heap and Graylog itself, plus MongoDB, and benefits from SSD storage. For a homelab sending a few hundred megabytes of logs a day, it runs well on a dedicated virtual machine with 8 GB of memory, but it is one of the heavier things you can self-host.
Loki is much lighter: a single-binary deployment for a homelab often uses a few hundred megabytes of memory, and compressed chunks keep disk use low. Grafana adds a little more, though many homelabs already run it for metrics. If you already use Grafana for dashboards, Loki slots in without another interface to learn. Running Loki next to a simpler live-log viewer is covered in Dozzle vs Grafana Loki for Docker logs.

Retention and disk
Graylog manages retention through index sets: you choose how long or how much data to keep, and old indices are deleted or closed automatically. Indexed data takes more space than raw logs. Plan disk generously and watch growth in the first weeks.
Loki applies retention through its compactor, deleting chunks older than your chosen period, globally or per stream. Because data is compressed and unindexed, keeping months of logs is cheap, and Loki can store chunks on S3-compatible object storage such as MinIO or Garage if your server’s disk is small.
Alerts from logs
Some problems only show up in logs: repeated failed logins, a backup job printing an error, a disk controller warning, a firewall blocking the same address thousands of times. Both can alert on them.
Graylog has event definitions that run searches or aggregations on a schedule and notify you by email, HTTP, Slack-style webhooks and other channels. Because everything is indexed, alert conditions can be quite specific.
Loki uses LogQL alert rules, evaluated by its ruler or by Grafana’s alerting, such as “more than ten failed SSH logins on any host in five minutes”. Alerts flow through the same paths as your metric alerts, which is convenient if you already use Grafana alerting, compared with Alertmanager in Grafana Alerting vs Prometheus Alertmanager.
Firewall and security logs
One use case deserves special mention: firewall and security logs. A firewall can produce many lines per second, and the interesting questions, which addresses are scanning you, which internal devices talk to unexpected destinations, are about fields and aggregations across a lot of data.
Graylog handles this well. Parse the firewall’s log format into fields, and you can chart blocked connections by source country, top talkers, or destinations per device. Loki can do similar aggregations with LogQL at query time, but over large volumes and long time ranges it is slower, and parsing complex formats in every query is more work. If security analysis of network logs is your main goal, Graylog’s model fits better.
Three investigations, side by side
To compare them fairly, I ran both on the same logs for a few months. Three real problems show the difference.
A container that kept restarting overnight. In Loki, selecting the container’s label for the night in question showed the out-of-memory message within seconds. In Graylog, searching the container name gave the same answer just as fast. A tie: narrow questions suit both.
An unknown address in the firewall logs. I wanted every log line, from every device, that mentioned one IP over the previous month. Graylog returned results across firewall, reverse proxy and SSH logs almost instantly. Loki needed a query across all streams for thirty days, which took far longer on my small server and needed a narrower time range to finish comfortably. Graylog wins clearly.
A slow, creeping increase in errors from the reverse proxy. In Loki, a LogQL query counting 5xx responses per hour, shown as a graph in Grafana next to the server’s CPU, made the trend and its cause, a backup overlapping with peak use, obvious. Graylog could chart the same thing from parsed fields, but having it next to the metrics in Grafana was more convenient. A slight edge to Loki for people who live in Grafana.
A sensible starting setup
For most homelabs, I would start like this:
- If you already run Grafana, add Loki in single-binary mode with filesystem storage, and Grafana Alloy on each host collecting Docker and system logs, with labels for host and container.
- Point routers, switches and the firewall at a syslog receiver in the collector.
- Set retention to 30 days to start; raise it once you see disk growth.
- Create three or four alert rules for things you know matter, such as failed logins, backup errors and disk warnings.
- If you find yourself constantly needing broad, fast searches across everything, or detailed firewall analysis, try Graylog on a separate virtual machine with the memory it needs.
Deciding by how you search
Choose Loki if your log searches are mostly “this service, around this time”, you already use Grafana, and your hardware is modest. It is cheap, simple to operate, and good enough for most homelab troubleshooting.
Choose Graylog if you want fast full-text search across everything, rich parsing of formats such as firewall logs, and a dedicated log interface, and you can give it a machine with several gigabytes of memory. It is the more capable log tool, at a higher running cost.
Either is a huge improvement over logging into each machine when something goes wrong.