Self-Hosting a Loki and Promtail Log Collection Server on a Raspberry Pi for Your Shop Devices

This site's Raspberry Pi self-hosting content covers plenty of individual services — a NAS, a VPN gateway, a Pi-hole instance, Home Assistant — but if you've got more than two or three of them running, you've probably had the experience of SSHing into each one separately to figure out why something broke at 3am. Centralized log collection fixes that: every service's logs land in one place, searchable, instead of scattered across however many SD cards and SSH sessions your shop network has accumulated.

Why Logs, Not Just Metrics

This site already covers metrics-style monitoring — dashboards tracking CPU load, temperature, and uptime across a print farm or home network. Metrics tell you something is wrong; logs tell you why. A Pi that shows a CPU spike on a graph doesn't tell you which service caused it or what error it was throwing at the time — the log lines from that exact moment do. Running both together is genuinely complementary: metrics flag the moment to look closer, and a log aggregator is where you actually go looking.

Why Loki Specifically

Loki (from Grafana Labs) is built specifically to be lightweight enough to run comfortably on a Raspberry Pi, which matters a lot here — a full Elasticsearch-based logging stack (the traditional ELK approach) is genuinely painful to run well on anything less than a dedicated server with real RAM to spare. Loki takes a different, cheaper approach: it indexes only labels (hostname, service name, log level) rather than indexing the full text of every log line, and stores the raw log content compressed. That trade-off — less powerful full-text search in exchange for dramatically lower resource use — is exactly the right trade for a home shop network where "search every log line for an exact string, instantly, across terabytes" was never actually the requirement.

What You'll Need

• A Raspberry Pi to act as the central log server — a Pi 4 or 5 with at least 2GB RAM is comfortable for a handful of client devices; this doesn't need to be a dedicated machine if you're already running another lightweight service on a Pi with headroom to spare.
• Docker and Docker Compose installed on that Pi, which this site's Docker-on-Raspberry-Pi content already covers if you haven't set that up yet.
• Promtail (or an equivalent log-shipping agent) installed on every device whose logs you want collected — this includes other Raspberry Pis, but also works on x86 Linux boxes, so a shop network mixing Pi and non-Pi devices is fine.
• Optionally, Grafana for visualizing and querying what Loki collects — Loki stores the logs, but Grafana is the normal way to actually browse and search them with a usable interface rather than raw API queries.

Setting Up the Loki Server

Run Loki itself via Docker Compose on the central Pi, mapping a persistent volume for its storage directory so log history survives container restarts, and exposing its default port (3100) only to your local network — Loki has no built-in authentication in its simplest configuration, so it should never be exposed directly to the internet without a reverse proxy adding auth in front of it, the same caution this site's other self-hosted service guides give for anything without its own login screen. Set a retention period in Loki's configuration that matches how long you actually want to keep logs around; shop logs rarely need to be kept forever, and a sane retention window keeps storage use predictable on a Pi's limited SD card or SSD.

Shipping Logs with Promtail

Promtail runs on each device you want to monitor and tails local log files (or reads from systemd's journal on modern Linux systems) and forwards them to the central Loki instance over the network. Configure Promtail's scrape targets to match what you actually care about — systemd journal logs cover most services running as system units, while Docker container logs need a separate scrape config pointed at Docker's log driver output if you're running containerized services on the client devices too. Label each client clearly by hostname and role in Promtail's config (print-farm-pi-1, laser-controller, nas-server) since those labels are what you'll actually filter and search by later in Grafana.

Querying What You've Collected

Loki's query language (LogQL) is deliberately similar to Prometheus's PromQL if you've used that for metrics before — queries start by selecting a label set (device, service, log level) and then optionally filter the matching log lines by text pattern. In Grafana, build a simple "Explore" view filtered to a device label first, which is usually enough to spot an obvious error during a live troubleshooting session, before reaching for more complex LogQL filtering for a specific recurring pattern you're hunting down.

Practical Shop Uses

ScenarioWhat Centralized Logs Give You A print farm controller Pi reboots unexpectedly overnightKernel and system logs from the exact reboot window, without needing physical or SSH access to the Pi before it potentially reboots again A self-hosted service (Pi-hole, Home Assistant, a NAS share) intermittently failsA searchable history across days or weeks instead of whatever scrolled past in a terminal you weren't watching at the time Multiple Pis on the shop network, each running different servicesOne dashboard instead of remembering which Pi runs which service and SSHing into each one in turn

This isn't infrastructure most one- or two-device home shops need — if you've got a single Pi running Pi-hole and nothing else, SSHing in when something breaks is still the simpler answer. Once your shop network grows past a handful of always-on devices, though, centralized logging stops being enterprise overkill and starts being the difference between finding a problem in minutes versus hunting through SSH sessions one device at a time.