Nerdlog: a remote-first TUI log viewer that keeps analysis on the node
Nerdlog: fast, remote-first, multi-host TUI log viewer with timeline histogram and no central server
At a glance
- What is it?
- Nerdlog is a Go TUI that opens SSH sessions to several hosts, runs the log analysis there, and pulls back only histogram data and a bounded page of messages. It is a good fit for reading syslog or journalctl across a handful of Linux boxes without standing up a central log server.
- Who is it for?
- Adopt Nerdlog if you already have SSH access to the machines whose syslog or journalctl output you read, and you want a histogram over a time range without running Elasticsearch, Graylog or Splunk. Do not adopt it if your logs live only in a central store, if you need Windows hosts as sources, or if you need more than two consecutive files per logstream.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nerdlog targets: reading logs on many hosts without a log server
The README states the primary use case directly: reading system logs from /var/log/messages, /var/log/syslog, or straight from journalctl, on one or more remote hosts, and doing it efficiently even on files of 1GB or more. The project history says it was originally written in 2022 to replace what the author describes as painfully slow Splunk setups, for a web service backend running as systemd services across a set of Linux instances. That origin explains the shape of the tool. It is not a log pipeline. It is a reader, aimed at the person who already has SSH keys to the fleet and wants a histogram of error volume by minute before deciding which host to open.
The intended user is an engineer or SRE who can reach production machines over SSH and is allowed to run commands there. Nerdlog does not ask for an agent, a collector, or a daemon on the remote side. That is the whole point of the design, and it is also the constraint that decides whether the tool is usable for you at all.
How the architecture avoids a central server
According to the design highlights, Nerdlog establishes an SSH connection to every node the user wants logs from and keeps those connections idle in the background. When a query runs, the log analysis happens on the remote nodes, not locally. Only two things come back per node per query: the timeline histogram data, and up to 250 messages from every logstream, a number the README says is configurable. Pagination fetches the next batch. Nerdlog then merges the responses from all nodes and presents them in a unified view. Most of the data is gzipped in transit.
That is a different data flow from a centralised stack. In Graylog or Elasticsearch, messages are shipped to an indexer, stored, and queried from there, so the query cost is paid once at ingest and the history is bounded by your retention policy. In Nerdlog, the remote file or journal is the index. There is nothing to retain and nothing to ingest, but every query re-reads the remote source, and the answer you get is only as complete as the page size allows. The README notes that a separate server to store the log files might still help in some cases, and points at the limitations document for that discussion.
The shell session is not hardcoded to ssh. The design highlights say Nerdlog supports an arbitrary command to establish a shell session with the remote hosts, so it can be used with Teleport or similar tools. For organisations where direct SSH to production is not permitted, that is the difference between usable and not.
Logstreams, the addressing syntax, and what a query actually names
A logstream is defined in the README as a contiguous stream of log messages on a particular server reachable via ssh, or on the local server. Two kinds exist today: one or more consecutive log files, and output from journalctl. The file variant is currently capped at two files per logstream, which the README flags as a limitation that will hopefully be removed. That cap matters in practice, because a rotated syslog on a busy host can have more than one older generation.
The default resolution order is stated plainly: use /var/log/messages and /var/log/messages.1 if present, otherwise /var/log/syslog and /var/log/syslog.1, otherwise journalctl. The README explains the preference: journalctl is described as less reliable and much slower, and the FAQ is cited for the reasoning. The trade-off is acknowledged in the other direction too. journalctl is more universally available and often has longer history, so it is fully supported, but there is no option yet to prefer it over log files by default.
Addressing is compact. A bare myuser@myserver.com picks the default logstream on port 22. The explicit form myuser@myserver.com:1234:/some/other/logfile overrides port and path, and myuser@myserver.com:1234:journalctl forces journalctl. Multiple logstreams are comma separated. Nerdlog also reads ~/.ssh/config for port, username and hostname, and supports globs, so myhost-* can stand in for a list of hosts. Log files cannot come from ssh config, so per-host paths belong in ~/.config/nerdlog/logstreams.yaml, which the README shows starting with a log_streams key.
Getting the binary: releases, go install, and the X11 dependency on Linux
The README says the easiest route is a prebuilt binary from the releases page. Building from source needs Go. On Linux there is one extra system dependency: the X11 dev package, because of clipboard access via the golang-design/clipboard library. On Ubuntu the README gives sudo apt install libx11-dev. MacOS and Windows need no extra dependencies.
Two Go install paths are documented. go install github.com/dimonomid/nerdlog/cmd/nerdlog@latest pulls the latest release and may miss features not yet officially released. go install github.com/dimonomid/nerdlog/cmd/nerdlog@master pulls master. Unless GOPATH or GOBIN is customised, the binary lands in $HOME/go/bin. The Makefile route installs to /usr/local/bin with make && sudo make install, or builds and runs in place with make && bin/nerdlog.
Running the binary opens a query edit form with a time range and a logstreams field. That is the entire setup surface. There is no server to configure, no index template to write, and no ingest pipeline to debug. The cost of that simplicity is that every capability the remote tools do not offer, such as cross-host correlation over long retention, is simply absent.
Where Nerdlog is the wrong tool
The README is explicit that only the client app runs on Windows, and that logs cannot be collected from Windows hosts. If any part of your fleet is Windows, those machines are outside the tool.
The 250-message page size per logstream per query is the second boundary. It is configurable and pagination exists, so this is a design choice rather than a defect, but it changes how you work. You cannot scroll through a day of logs at a glance. You narrow the time range with the histogram, then page. If your actual task is full-text search across months of retained logs with saved queries and alerting, a central store is the right instrument and Nerdlog will feel like a viewer with a short memory.
The two-file cap per logstream is a real operational limit. On a host with aggressive rotation, the older generations are not reachable through the documented file form. And the default preference for log files means that on a modern system where only journalctl exists, you are on the path the README itself calls slower. The README also notes the code still has traces of its hackathon origins, which is an honest statement about polish rather than a functional claim.
How this differs from Graylog and Kibana in approach
Graylog and Kibana, which the README names as loose inspirations, are built around a server that receives, stores and indexes messages, with a web UI querying that store. The difference is not cosmetic. In that model, log retention, search speed and cross-host joins are properties of the index, and the operational cost is the cluster that maintains it. Nerdlog inverts it: the SSH session is the transport, the remote file or journal is the source of truth, and the histogram is computed per query from the remote side.
That inversion has predictable consequences. You get a working viewer in minutes with no infrastructure, which is why the README calls the setup burden essentially nil. You give up retention guarantees, because nothing is stored, and you give up the ability to query hosts you cannot SSH into. The author's own note that a separate server for log files might still help in some cases is the acknowledgement that the two models are not mutually exclusive. Nerdlog can read the files that a shipping agent also writes, but it will not replace the agent's index.
Maintenance, licensing and what to check before adopting
Nerdlog is licensed BSD-2-Clause, a permissive licence that permits use and redistribution with the copyright notice and disclaimer retained. That is a low-friction choice for internal deployment and for embedding in a commercial environment. This is a description of the licence text, not legal advice; if the distinction matters to your organisation, have counsel read it.
Maintenance signals from the repository are recent rather than historical. The last push is dated 2026-08-30, and the release list shows v1.10.0 on 2025-06-09, v1.9.0 on 2025-06-02, and v1.8.2 on 2025-05-25, a cadence of roughly weekly patch and minor releases in that window. The README states the project was revisited in 2025 to clean it up and open source it, after being written in 2022 and used at work and on personal projects for a few years. There are tests, described as decent in the README and documented in docs/tests.md. None of this tells you how the project will be maintained next year, and the README does not promise a support model.
The upgrade cost is low by construction: a single binary, replaced from the releases page or rebuilt with go install. The pieces that can break on upgrade are your local logstreams.yaml and any assumptions about the default resolution order, since the README already indicates that preferring journalctl is a requested but unimplemented option. Verify three things first. That the SSH user on each target can read the log files or run journalctl. That the globs in ~/.ssh/config expand to the hosts you expect. And that the log paths you actually need fit the two-file-per-logstream limit, because if they do not, the fallback is journalctl and the README's own performance note applies.
Editorial conclusion
Adopt Nerdlog if you already have SSH access to the machines whose syslog or journalctl output you read, and you want a histogram over a time range without running Elasticsearch, Graylog or Splunk. Do not adopt it if your logs live only in a central store, if you need Windows hosts as sources, or if you need more than two consecutive files per logstream. Before rolling it out, verify that your non-default log paths are expressible in ~/.config/nerdlog/logstreams.yaml, that your remote shells expose the log files to the SSH user, and that the pagination limit of up to 250 messages per logstream per query matches how far back you actually read.
Community notes