Kula: A single-binary Linux monitor that reads /proc and /sys, stores in a ring buffer, and ships a TUI and web UI

What Kula actually solves

Kula targets a specific pain: you need server metrics now, on a Linux box, without standing up a database, an agent, and a dashboard. The README says it has zero dependencies, no external databases, and ships as a single binary. You upload it, run it, and it reads /proc and /sys every second. That means no PostgreSQL schema, no Redis cache, no node exporter to install. It is aimed at operators who want quick real-time visibility into CPU, memory, network, disk, and thermal state, and who do not want to maintain a separate collection pipeline. The self-contained nature also makes it a plausible tool for air-gapped or minimal environments where installing a full monitoring stack is overkill.

The ring-buffer storage engine and its trade-offs

Kula does not use an external time-series database. Instead, it has a custom ring-buffer storage engine that writes metrics into fixed-size binary files. The README explains that new data overwrites the oldest entries once the file reaches its maximum capacity. There are three tiers: Tier 1 keeps raw 1-second samples with a default cap of 250 MB, Tier 2 stores 1-minute aggregations with average, min, and max, defaulting to 150 MB, and Tier 3 holds 5-minute aggregates, defaulting to 50 MB. On startup, Kula restores the latest-sample cache and rebuilds pending aggregation buffers. This design gives you bounded disk usage and fast writes, but it also means you cannot keep months of raw history. If you need long-term retention for capacity planning or compliance, Kula's ring buffer will eventually discard old data. That is a deliberate trade-off: you get a small footprint and no external storage dependency, but you lose the ability to query historical data beyond the buffer window.

How the collectors and API fit together

The collectors read directly from /proc and /sys. The README lists a wide range of metrics: CPU usage with user, system, iowait, irq, softirq, and steal; GPU load, power, and VRAM; load averages; memory with buffers, cached, and shmem; swap; per-interface network throughput, packets, errors, drops, plus TCP errors and resets; per-device disk I/O and filesystem usage; system uptime, entropy, clock sync, and logged-in users; process counts; Kula's own resource usage; thermal readings; battery status; container stats from Docker, podman, or raw cgroups; application metrics from PostgreSQL, MySQL, nginx, and apache2; and custom metrics. The HTTP server exposes a REST API and a WebSocket endpoint for live streaming. The dashboard is a single-page application embedded in the binary, built on Chart.js with custom SVG gauges. It connects via WebSocket for live updates and falls back to a history API for longer ranges. This split means you can scrape the REST API for your own tooling, or use the dashboard as-is.

Getting it running: commands and config keys

The README offers several install paths. The guided installer is a bash script fetched from the repository: bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install_v2.sh)". There is also a verified variant that downloads the script, checks its SHA256 against a hardcoded hash, and only then runs it. For a standalone install, you download the release tarball, verify its checksum, extract, and run ./kula. Docker is supported with a temporary container that mounts /proc read-only and uses host networking: docker run --rm -it --name kula --pid host --network host -v /proc:/proc:ro c0m4r/kula:latest. For persistent storage, you add a volume for /app/data. The README also mentions a .deb package for Debian and Ubuntu, though the text is truncated. Configuration lives in config.yaml, and the README references enabling Ollama there for the AI assistant. Authentication is optional; when enabled, it uses Argon2id password hashing, secure session cookies, and token-only session validation with sliding expiration. You can also use a bearer token via the Authorization header for API access.

The AI assistant: local Ollama, not a cloud feature

Kula includes an optional AI assistant that talks to a local Ollama instance. The README says all inference runs locally through the Ollama API. When enabled in config.yaml, a button appears in the dashboard header. You can open multiple conversation sessions, click an icon on any chart to pre-load that chart's recent data as CSV, and the model can call a get_metrics tool to pull metrics on demand, up to five rounds per turn. It supports switching between locally available Ollama models, and the panel is draggable and resizable. This is a different approach from cloud-based assistants: your metrics never leave the machine, but you must run Ollama yourself. That adds a dependency, which undercuts the zero-dependency selling point. If you do not want to run a local model, you simply do not enable it. The feature is a nice extra, but it is not core to monitoring.

Limitations and cases where Kula is the wrong tool

Kula is Linux-only. The README says it reads from /proc and /sys, which means it will not work on Windows, macOS, or BSD. The GPU monitoring note warns that NVIDIA GPUs might require additional setup, so do not assume it works out of the box on every GPU server. The ring-buffer storage caps history, so it is not suitable for long-term trend analysis or audit trails. The alerting system is described as covering clock sync, low entropy, and system overload, which is a narrow set; there is no mention of alerting on arbitrary metric thresholds or sending to PagerDuty or Slack. Also, the AI assistant depends on Ollama, which is an external process. If you need a monitoring tool that supports multiple operating systems, keeps years of data, or integrates with a mature alerting pipeline, Kula will feel limiting.

Alternatives and how they differ

The most direct alternative is Netdata, which also reads /proc and /sys and provides a real-time dashboard with a web UI. Netdata uses its own database and has a much larger feature set, including alarms, notifications, and a plugin system, but it is not a single binary; it is a daemon with a significant install footprint. Prometheus plus node_exporter is another common choice: node_exporter exposes metrics on an HTTP endpoint, and Prometheus scrapes and stores them in a time-series database. That approach gives you long-term storage and powerful queries with PromQL, but it requires running two services and a database, and it does not include a built-in dashboard; you would add Grafana. Kula's advantage is that it is one binary that does collection, storage, and visualization. The sacrifice is that you cannot easily extend it with custom exporters or retain data indefinitely. If you already run Prometheus, Kula's Prometheus exporter endpoint lets you scrape it, but the ring buffer remains the primary storage.

Licence and maintenance considerations

Kula is licensed under AGPL-3.0. That is a strong copyleft license; if you modify the code and offer it as a network service, you may need to release your modifications. For internal use, this is usually not a problem, but if you embed Kula in a commercial product, you should understand the implications. The project is actively maintained, with releases 0.18.6, 0.18.7, and 0.18.8 pushed within a few weeks of each other in July 2026. The release cadence suggests ongoing fixes. Upgrades appear to be straightforward: download the new binary and replace the old one, since there are no external dependencies. However, the storage engine's format might change between versions, and the README does not mention migration tooling. Before upgrading, you should check the release notes for any breaking changes, and you should back up the data directory if you care about the ring buffer contents.

Editorial conclusion

Adopt Kula if you run Linux servers and want a monitoring tool that needs no database, no agent runtime, and no package manager beyond a single binary. Skip it if you need Windows or BSD support, long-term retention beyond a few hundred MB, or a mature alerting system. Before production use, verify the checksums from the release page, review the AGPL-3.0 implications for any embedded distribution, and test GPU monitoring on your exact NVIDIA driver setup, since the README warns that extra setup may be required.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes