Veyra
Design & engineering
A macOS-first observability and resource-intelligence platform in Rust. One engine indexes the filesystem, explains where storage goes, monitors resources, and runs a cleanup workflow that never deletes anything without a reviewable, reversible plan.
| When | 2026 |
| Stack | Rust, SQLite, Axum, egui, ratatui, Tokio |
| Links | github.com/kali-physi-hacker/veyra |
| 8 | workspace crates |
| 1M | records indexed in benchmarks |
| 20 ms | largest-directory query |
| 0 | files deleted, ever |
Veyra (internally codenamed Stratum) started from a question I kept asking my own laptop: where did the space go, what changed, and what is actually safe to remove? Existing tools answer the first question with a pretty map and the third with a big delete button. I wanted the middle part, the explanation, and I wanted an action model I would trust on my own machine.
One engine, four surfaces
The workspace is eight Rust crates with a deliberate boundary: domain holds versioned, transport-independent contracts; platform does streaming filesystem traversal and system sampling; index owns SQLite; engine composes them into the application services; and api, cli, desktop and tui only translate requests and render results. There is no second business-logic layer for the GUI. The desktop app, the terminal interface, the CLI and the local HTTP API all call the same functions, which is also what makes a thin MCP adapter possible later.
| CLI | scripting & JSON |
| TUI | nine pages, keyboard first |
| Desktop | native egui app |
| HTTP | loopback, bearer auth |
A persistent index instead of a scan
Every scan builds a new generation of the index in SQLite and publishes it atomically, so a query never sees a half-finished tree. Directory totals, category rollups and a directory-name index are maintained transactionally at publication, which is what turned a 360 ms category query into 0.03 ms on a hundred-thousand-file fixture and keeps largest-directory queries around 20 ms at a million records. A native filesystem watcher updates leaves incrementally between scans; freshness is reported honestly as probably fresh or stale rather than promised.
Findings you can argue with
Insights are deterministic rules, not a score. A finding such as "Rust build artifacts account for 100% of their parent" carries its evidence: the indexed directory, the manifest that sits beside it, and the parent-share measurement. Growth anomalies are normalised by elapsed time and exclude partial scans. Absence of findings is explicitly not a health verdict, and the interface says so.
Cleanup that cannot surprise you
This is the part I am most careful about. The workflow is discover → plan → preview → execute → audit:
- Candidate rules only recognise specific regenerable files (Cargo artifacts, package caches). A large or old file is never a candidate on its own.
- A plan is immutable, expires, records each file's identity and content hash, and produces an approval phrase that must be typed exactly.
- Execution moves files into a same-filesystem quarantine with a per-item journal, rejecting anything that changed, is hard-linked, symlinked, protected or on another device.
- Undo restores the bytes if the original location is free and the hash still matches.
Quarantine preserves bytes; it does not free capacity, and the product never claims otherwise. That copy discipline matters as much as the code.
The interfaces
The desktop is a native egui application with bundled typography and icons, dark and light appearances, a treemap that includes direct files, an inspector with classification evidence, and a step-based cleanup review. The terminal interface covers the same nine pages with keyboard navigation, live scan progress and the same plan-and-approve flow. Both are exercised by headless tests: first run must never scan, quarantine cannot execute without the exact phrase, and a fixture file is quarantined and restored byte-for-byte.