A developer on V2EX posted something a lot of homelab people will recognize. Logging into the Unraid web UI every time they wanted to glance at CPU, RAM, disk, or flip a VM or Docker container on and off got old. So they used AI to build a desktop control app that talks to the Unraid API, reads status, and starts/stops VMs and containers. It uses the Unraid API with a key you create in the web settings, calls over HTTPS, ships no auto-update or data collection, and keeps everything local. One reply said it was genuinely handy.
That's a clean little tool. But the interesting question isn't the app. It's which part of it is actually reusable, and the answer is: not the native binary.
What the desktop binary locks you into
A native app has to be installed on each machine, built for each OS, and updated by hand (this one explicitly ships no updater). The API key lives on whatever device you installed it on. If you want the same view from your phone on the couch, or a laptop at work, you're out of luck. The dashboard is wherever the executable is.
Strip that away and look at what the tool really does. It holds a credential, polls a box over HTTPS, parses the readings, and draws a screen. None of that needs to be native. All of it maps cleanly onto a small hosted service plus a web page.
The pattern repeating across the board
This isn't an isolated idea. Scanning the same corner of V2EX, you see the same instinct again and again: a browser-based Office suite that runs client-side instead of asking you to install anything, a Spotify lyrics page built for the Tesla browser because there was no web client, a self-hosted link/paste/file tool on Go plus SQLite. Different problems, same move — put the thing on the web, hold the secrets server-side, and let any device be the client.
The lyrics project is the closest cousin to the Unraid case. It runs one poller per active user, only calls the upstream API while a page is open, and stores the provider tokens encrypted in a database. That's exactly the shape a status dashboard wants: a backend that owns the credential and does the polling, a thin front end that just renders.
For a builder or operator, the signal is simple. When you catch yourself writing a native control panel for a box you own, stop and ask whether the durable version is a hosted proxy with one HTML view. The proxy is what you reuse across devices, across tools, and across the next integration.
Rebuilding it as a hosted proxy
Here's how the Unraid assistant translates without the desktop part.
The core is a Python backend you can run Python online, holding the Unraid API key server-side rather than baking it into a binary on each machine. On a schedule, it calls the Unraid API over HTTPS, pulls CPU, RAM, disk, and network readings, and exposes a couple of endpoints: one that returns the latest status, and ones that trigger the VM and Docker start/stop actions the original app supported. The key never leaves the server, so you're not copying it onto every device you want to check the box from.
Each reading gets written to a status ledger so you're not only seeing a live snapshot but a history. A small SQLite table — timestamp, metric, value, plus an action log for every start/stop you fire — is enough. Being able to open a SQLite editor to inspect rows, prune old data, or correct a bad entry by hand keeps the whole thing legible without standing up a heavier database.
The front end is one HTML board: current CPU/RAM/disk/network, the VM and container controls wired to those endpoints, and a simple chart off the ledger. Because it's an HTML app you reach through web app hosting, you open it from a phone, a laptop, or a tablet without installing anything per device. That's the part the native app couldn't give you.
The boundaries, stated honestly
This is not a drop-in replacement, and pretending otherwise would be dishonest.
First, there is no native desktop app in this version, and VicroCode doesn't build one. If you specifically want a packaged executable with a tray icon, that's outside what the platform does. What you get instead is a hosted web board.
Second, and this is the real constraint: the hosted proxy has to be able to reach your Unraid box over HTTPS. A desktop app on your LAN talks to the box locally. A hosted endpoint sits elsewhere, so the box must be reachable from that endpoint — a routable HTTPS address, through whatever tunnel or exposure you're comfortable with. If your Unraid is strictly LAN-only with no inbound path, a hosted poller can't see it, full stop. That's a networking decision you have to make before any of this works, and it's not one the platform makes for you.
Third, the original author's promise is worth reading carefully: no telemetry, no data collection, everything stays local. The moment you move to a hosted proxy, "local-only" stops being literally true. The credential now lives on the server, and the ledger of readings lives there too. That can be perfectly fine — it's your server, your data — but it's a different trust model than a binary that never phones anywhere. Treat the key as a server-side secret, reference it by name rather than pasting it around, and be clear-eyed that "it all stays on my machine" has become "it all stays on my hosted service."
I haven't tested this against a live Unraid install, so treat the specific API behavior, auth flow, and polling cadence as things to verify against your own box — unverified until you've run it. The architecture is the point: the reusable asset was never the executable. It was the proxy that holds the key, the ledger that remembers, and the one page you can open from anywhere.