DEV Community

tyxak
tyxak

Posted on

RemotePower – self-hosted remote power management

#monitoring #devops #security #ai

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:

  1. An agent runs on (or alongside) each managed device.
  2. On an interval, the agent polls the server: "anything for me?"
  3. The server hands back any queued commands.
  4. 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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)