I Got Tired of a Dozen Browser Tabs, So I Built Peira

A homelab has a way of sprawling across browser tabs. The Proxmox web UI in one. Grafana in another. Whatever dashboard the media stack exposes in a third. A terminal for SSH, an Open WebUI tab for the local models, the Wiki in the back somewhere. Individually all fine; collectively a tab bar I kept losing things in.

So, in the grand tradition of solving a mild annoyance with a disproportionate amount of work, I built an app. It is called Peira, it is a native desktop program rather than another tab, and it is now public on GitHub under Apache-2.0.

I should set expectations up front: I am not a professional app developer. Peira is a Flutter app I built against my own cluster because I wanted the thing to exist, and it carries some of that lab’s shape in its assumptions (more on that below — honestly). But it does real work, it reads safely, and it is genuinely useful if your homelab looks anything like mine.

What it actually does

Peira is organised as tabs down a nav rail, each one a surface onto part of the lab:

The first launch is a setup wizard that needs only your Proxmox URL and an API token, and it runs a real connection test before it lets you continue. The nice part: a read-only PVEAuditor token is enough for everything except management actions, so you can point Peira at your cluster and look around without handing it the keys to delete anything. The wizard even prints the exact pveum commands to create the token.

Eight themes, because I could not pick one

Version 1.1.0 added eight theme families, each one re-skinning the whole shell — background, masthead, panels, nav rail, ornaments — through its own palette and typography, with a dark and a light variant for every family:

Is eight themes a reasonable number for a one-person homelab app? Absolutely not. Did I build them anyway? Yes.

Try it before you trust it

You do not need a Proxmox cluster to take it for a spin. Demo mode boots a fully populated, obviously-fake lab — no configuration, no keyring writes, no network access — with a persistent banner so a demo screenshot can never be mistaken for a real one.

chmod +x Peira-x86_64.AppImage
./Peira-x86_64.AppImage --demo

When you do want to run it for real, verify the download first. Every release ships a SHA256SUMS file and a detached GPG signature from the Peira Labs signing key:

sha256sum -c SHA256SUMS
gpg --verify SHA256SUMS.asc SHA256SUMS

Updates are manual by design — an AppImage cannot replace itself in place — and the public build’s update check is a single GET against the releases API only when you ask for it. No telemetry of any kind.

The honest part

The rule I try to hold to on this blog is that honesty about something new beats making it sound finished, so here is what Peira assumes and where it is rough:

And the elephant in the AppImage: it is about 329 MB. That is almost entirely the embedded Chromium engine (CEF) that powers those in-app views of Grafana and friends. Trimming that down is the next real job on the list. It is Linux-only today, too — GTK 3, an X11 or Wayland-with-XWayland session, and a Secret Service provider (GNOME Keyring or KWallet) for storing credentials.

A smaller cousin from the same workbench

If you run the media side of a homelab, there is a much smaller, single-purpose tool from the same lab worth a look. When my qBittorrent downloads sat at 0 KB/s for four days behind a VPN while every port-sync tool happily reported success, I wrote deadair, a tiny Rust checker that tells you when a gluetun + qBittorrent stack has quietly stopped moving data rather than merely being configured correctly. The full story is here — it is the same lesson Peira is built around, really: configured is not the same as working.

Links

• Source: github.com/peiralabs/peira (Apache-2.0)
• Download: the signed x86_64 AppImage on the releases page

If you try it — especially in --demo, which needs nothing — I would genuinely like to know what breaks. That is the whole point of putting it out there.