DEV Community: tyxak

Five fixes from a stranger, and the release that finally got a community

tyxak — Thu, 25 Jun 2026 20:14:16 +0000

RemotePower started as a web page with a single button that turned a machine off. I wrote it in Python one afternoon, and then scope creep did the rest, with a lot of help from AI to speed things up (sorry, AI snobs :-)). That one button is now a self-hosted control plane for a whole Linux fleet: monitoring and alerting, a CMDB, CVE scanning, patching, browser-based SSH, Proxmox, drift detection. Underneath it's still deliberately boring — nginx, Python CGI, flat JSON files — and the agents poll out over HTTPS, so there are no inbound ports open on the clients, ever.

For most of its life it's been a one-person project. The architectural ideas are mine, the code is mostly written by AI, and I'd rather be upfront about that than pretend otherwise.

Then, last week, something happened that I genuinely didn't expect: someone I've never met opened a pull request. Then another. By the end of the week it was five fixes and a really sharp bug report — all from one first-time contributor, none of whom I know.

The release named itself

A little habit I picked up along the way: every RemotePower release gets a codename ending in "Matters." VisualMatters, TrustMatters, FortifyMatters, OnboardingMatters, PerimeterMatters, CTRLMatters. It started as a bit of fun and stuck around, and it turned into a nice forcing function — each release gets one thing to care about most.

This one named itself. The thing that mattered most about it wasn't a feature I built. It was that, for the first time, the "ours" in "the tool is yours, ours really" had someone else in it. So: UnityMatters.

Here are three of the fixes that came with it, because honestly they're the good kind of bug — the boring-looking ones that are quietly nasty.

1. The device record that deleted itself

This is the bug report that made me sit up. A handful of API handlers were doing an unlocked read-modify-write of the device store: load the whole set, change one field, save the whole set back. Classic, and fine until two writes overlap.

On the flat-JSON backend that's the usual lost-update — a dropped field, annoying but survivable. But on the SQL backend it's worse than that. The save reconciles the entire device set and deletes any row that isn't in the payload. So picture a slow admin edit that loaded the device list a moment before a brand-new agent enrolled. When that edit saves its now-stale snapshot, the freshly-enrolled device — and its auth token — simply vanishes. The agent's enrollment, gone, because an unrelated edit happened to be in flight.

The fix is the boring, correct one: every device-write now does its read-modify-write under a single lock (_LockedUpdate(DEVICES_FILE)), so the load and the save can't be split by another writer. There's a guardrail test now too, so the next person who adds a handler can't quietly reintroduce it.

2. The backend that recompiled itself 50,000 times a day

This one's pure "deliberately boring architecture" coming back to bite. RemotePower's backend is a single ~50,000-line Python file, run as a CGI script via fcgiwrap. Turns out CPython never uses the cached .pyc for a script you run as the main program — it recompiles the source every single time. So every request, even a health check, was paying ~0.9s to recompile fifty thousand lines before doing any work.

The contributed fix is a four-line shim: a tiny entry script that imports the big module (so CPython loads its cached bytecode) and runs it as __main__. The big file is untouched. Per-request time went from ~0.9s to ~0.15s — about 6× — for the cost of a file that does basically nothing. My favourite kind of patch.

3. Proxmox, but the whole cluster this time

The Proxmox integration only ever asked the one node it was configured against, so on a cluster you saw one node's guests and nothing else. It now lists guests cluster-wide and tags each one with its owning node, and resolves that node per guest — so start/stop/snapshot/migrate hit the right host even for a guest living somewhere else.

The part I appreciated: node names come back from the cluster, and they flow into request paths. So they're validated as hostnames before they can ever reach a /nodes/<node>/… URL — a hostile or misconfigured cluster can't steer an authenticated call somewhere it shouldn't go. Someone thought about the threat model, not just the happy path.

Why I'm writing this down

There's no "buy me a coffee" button on RemotePower. It's MIT licensed, and it stays that way — homelab niceties and enterprise functions, all of it, free. Instead of a tip jar there's a pull request, an issue tracker, and a security workflow. The tool is yours. Ours, really.

This release is the first time that last sentence had receipts. If you run a Linux fleet or a homelab and you want to kick the tyres, it installs in about five minutes. And if you hit a bug, or have an idea, or just want to say hi — that's all very welcome. Clearly it goes somewhere now. :-)

Under all the AI, there's still a friendly human being behind this.

/jake

RemotePower is self-hosted, MIT-licensed, Linux/Windows/macOS agents, no inbound ports. Repo + install docs: https://github.com/tyxak/remotepower

RemotePower – self-hosted remote power management

tyxak — Fri, 05 Jun 2026 21:20:24 +0000

I built RemotePower because I wanted to power devices on and off across my own infrastructure without depending on a cloud service or some vendor's phone-home dashboard. Everything I run is self-hosted, and remote power was the one annoying gap I kept working around with SSH scripts and cron hacks. So I wrote a proper tool for it.

The itch

If you run your own hardware, you know the pattern: a box needs rebooting, a device needs cycling, and you're either physically there or you've cobbled together a one-off SSH script that you half-remember how to use. Every commercial answer to this wants you to route your power management through their cloud, install their agent that phones home to their dashboard, and trust that the company still exists next year. For something as sensitive as "turn my machines on and off," that never sat right with me.

I wanted something I fully own, that runs entirely on infrastructure I control, and that I can read top to bottom when something breaks.

How it works

RemotePower is a polling-agent setup. Clients phone home to a small server, so you don't have to expose anything inbound on the machines you're managing. The agent reaches out; the server never has to reach in. That means no inbound firewall holes on your managed boxes, which is the whole point when the thing you're controlling is power state.

The flow is simple:

An agent runs on (or alongside) each managed device.
On an interval, the agent polls the server: "anything for me?"
The server hands back any queued commands.
The agent executes and reports back.

Because the agent initiates every connection, the managed machines can sit behind NAT, behind a restrictive firewall, or on a network you don't fully control, and it still works.

The backend is boring on purpose

This is the part I'm actually proud of. The backend is deliberately, aggressively boring:

Python CGI behind nginx — each request is a short-lived process. No long-running app server to leak memory or wedge.
Flat JSON files for storage — no database to babysit, no migrations, no connection pool, no separate service to keep alive.
An HMAC token per device for authentication.

That makes it trivial to deploy on a cheap VPS or a box in your closet, and easy to reason about when something breaks. When your storage layer is cat packages.json, debugging is a very different experience than chasing a query planner.

A rough sense of the layout on the server side:

/var/www/remotepower/cgi-bin/   # the CGI handlers (api.py and friends)
/var/lib/remotepower/           # flat JSON state files
/etc/remotepower/               # config

Is flat-file storage the "right" choice at scale? No. But for the scale most self-hosters actually operate at — a handful to a few dozen devices — it removes an entire category of operational pain, and that tradeoff has been worth it every single time so far.

What the agent does beyond power

Once you have an agent phoning home anyway, it's a natural place to hang a few more useful things. The Linux agent also does:

Package enumeration — it reads installed packages via dpkg-query / rpm / pacman / apk, so the server has an inventory of what's actually on each box.
A CVE scan against OSV.dev — it cross-references those installed packages against known vulnerabilities and surfaces findings per device, with a dashboard view and an ignore-list for the noise.
A Prometheus /metrics endpoint — so if you already run Prometheus + Grafana (and if you're self-hosting, you probably do), you can graph it alongside everything else.

The CVE piece in particular turned a power tool into something I check more often than I expected — knowing which of my boxes are carrying a vulnerable package, without standing up a separate scanner, is genuinely handy.

Why I'm posting this

It's still very much a personal project that grew. There are rough edges. A few I already know about:

The flat-JSON storage works great until it doesn't — there's no row-level locking, so very high concurrency isn't its strength (it's not trying to be).
CGI-per-request is simple but not the fastest model under heavy polling.
The auth model (HMAC per device) is solid for the threat model I designed for, but I'd love more eyes on it.

That last point is really why I'm writing this. I'd genuinely like to hear where the design choices look wrong to people who run more than I do. If you've operated fleets, managed power at scale, or just have strong opinions about polling-vs-push or flat-files-vs-database, I want the pushback.

Try it / tear it apart

The repo is here: github.com/tyxak/remotepower

Happy to answer anything about how it's put together — the architecture decisions, the agent protocol, why CGI in 2026, any of it. And if you spot something I got wrong, that's exactly the feedback I'm here for.