DEV Community: tyxak

My NAS kept its encryption keys on itself — so I built a KMIP server into my open-source monitoring tool

tyxak — Thu, 30 Jul 2026 14:14:16 +0000

I maintain RemotePower, an open-source (MIT)
self-hosted control plane for a small fleet or a homelab — monitoring, alerting,
CVE scanning, patching, a CMDB. It started as a tool for my own machines and
grew from there. Version 6.4.1 just shipped, and the headline feature came out
of a realisation that had been quietly bothering me for a while.

The itch

My Synology encrypts its volumes. Good. It stores the encryption keys for those
volumes... on the Synology. Same box, same disks, same burglar. Whoever walks
off with the appliance gets the lock and the key together, which defeats a lot
of the point of encrypting at all.

The industry already has an answer: KMIP (Key Management Interoperability
Protocol), the OASIS standard that lets an appliance fetch its keys from an
external key manager at mount time. Synology DSM, TrueNAS and VMware vSphere
all speak it natively. The problem is the other end of the conversation —
everything I found that implements the server side is an enterprise appliance
or a heavyweight commercial suite. There was no small, self-hostable KMIP
server a homelab could point a NAS at.

So I built one into the tool that was already monitoring those boxes.

What it looks like

It's deliberately conservative in design:

Off by default. Nothing listens until you enable it.
A separate, sandboxed sidecar (remotepower-kmipd on tcp/5696) that terminates mutual TLS and parses the KMIP wire format — and holds no keys, no database access, no master key. It runs under systemd DynamicUser=yes with no access to the data directory. All the material that matters (the CA, the key objects, encryption at rest, the activity log) lives behind the main API, reached over loopback with a shared secret.
Mutual TLS only. Enabling it generates a private CA; each appliance gets its own client certificate through a three-step wizard, and the private key is shown once and never stored server-side.
An encrypted recovery bundle, because key custody without a way back isn't a feature — it's a liability.

Setup is one installer flag:

sudo ./install-server.sh --with-kmip

The supported operation set is deliberately matched to what DSM actually calls
in practice (an appliance that hits an unimplemented KMIP operation tends to
abort its whole setup with a generic error, so partial support is worse than
none).

The footgun, stated plainly

External key custody has a real trade-off, and I'd rather write it here than
have someone discover it at 2am: once an appliance stores its keys here, it
needs this server reachable at its own boot time to mount encrypted storage.
A NAS that keeps its keys on a VM hosted by that same NAS will not come back
from a reboot. That circular dependency is the classic self-hosted key-server
mistake, and the docs lead with it.

Two things in 6.4.1 exist specifically to soften the sharp edges: the key
server now has its own row on the server-status page (it was the one sidecar
without one, despite being the one whose outage stops volumes mounting), and it
warns ahead of its own certificate expiry — because an expired client cert
silently ends an appliance's access to its keys, and the failure surfaces at
the next reboot, which is the worst possible moment.

The rest of the release

Less glamorous, but honest work:

A per-destination minimum severity filter that had never filtered — the saved values sat in a range below every event's actual priority, so all four choices behaved identically. It works now, and existing settings keep exactly the behaviour they had, so nobody's alerting changes without asking.
Laptops on Windows and macOS report like laptops. Three signals were Linux-only, which left the laptop features dead on precisely the hosts they were designed for: a closed lid was treated like a dead server instead of getting the grace period, and battery health never reached the alerts.
A UI pass for the small stuff — one body size, one icon size, buttons that sit in a row, panels that scroll instead of growing without limit.

Try it
There's a read-only demo seeded with synthetic devices, alerts and CVEs —
no install needed: https://demoremote.tvipper.com (login demo / demo, resets every few hours).
Code and docs: https://github.com/tyxak/remotepower
It's a one-person project and I have no illusions about that. If you've run key
servers in production — or you can poke a hole in the KMIP design — I would genuinely rather hear it from you than from an incident. Issues and discussions
are open.

Making Windows a first-class citizen in my self-hosted fleet manager (RemotePower 6.2)

tyxak — Tue, 14 Jul 2026 19:42:51 +0000

For the last few releases, RemotePower's Windows support was… let's be honest, "kind of there." The agent ran, it reported in, but it did so as a scheduled task that quietly died if the box hiccuped, and half the things that were effortless on Linux needed hand-holding on Windows.

6.2 — codename "Daem0nMatters" — is the release where I stopped apologizing for that.

The agent is now a real service, everywhere

The headline change is boring in the best way: the agent runs as a proper supervised service on every OS it supports.

Windows — an actual Windows service (via pywin32), registered with the Service Control Manager. It shows up in services.msc, and the SCM restarts it if it crashes. No more scheduled-task-that-silently-stops. (If you've ever fought "Error 1053: the service did not respond in time" — that self-heals now.)
macOS — a launchd job with KeepAlive.
Linux — systemd, as before.

The practical upshot: the agent survives reboots and crashes on its own, on the OS where that was least true before.

Onboarding a Windows box is now a one-liner

Just like Linux. You paste one elevated-PowerShell line:

iwr /install.ps1?t= | iex

…and it downloads the agent, verifies its SHA-256, installs Python if it's missing (winget on modern Windows, the official python.org silent installer otherwise), enrolls with a one-time token, and registers the service. Nothing else to configure on a bare box.

It actually understands Windows now

A Windows host isn't just "a Linux host with worse paths," so the agent stopped pretending. New this release:

Security posture as first-class checks — BitLocker volume status, Windows Defender real-time protection and signature age, the Windows Firewall per profile, and the Windows Update service all render as Checks rows, drive alerts, and now show at-a-glance in the device drawer. "Real-time protection is off on WEB03" is a thing you find out before it matters.
A windows_service check type — the analogue of systemd_unit: "is service X running?" via Get-Service.
Real Event Log reading — a persistent RecordId cursor (so you don't re-ingest or miss events across restarts), the Security channel, and Event IDs.

And two genuinely embarrassing bugs got fixed along the way: the self-updater used to report success even when it failed (rc=0 unconditionally), and it resolved helper binaries by bare name — a SYSTEM PATH-hijack waiting to happen. Both closed, and the self-update is signature-checked when you enable signed updates.

The rest of 6.2, briefly

Windows was the theme, but it rode in with a batch of gap-closing:

A governed AI executor — you can ask the assistant to remediate a host, but it can only pick one action from a catalog you wrote, by exact id. It can't author a command, so there's no prompt-injection path to a shell.
A PII scan (cards by Luhn, national IDs, IBANs, emails), EDR coverage reporting (cross-references Wazuh/CrowdStrike/SentinelOne against the real fleet to find hosts with no endpoint protection), and DNS-blocker control (pause Pi-hole/AdGuard for a bounded, self-re-enabling window).
Three new tripwires: privileged-group changes (sudo/wheel/Administrators), Defender-off, and USB physical-access.
A host-wide disk-usage explorer for when a mount is 94% and you need to know of what, plus a composite device-reliability prediction.

On the boring-but-important stuff

It's still self-hosted, MIT-licensed, Python + nginx (gunicorn/Flask), with JSON / SQLite / PostgreSQL backends. Every release goes through CodeQL, Bandit and gitleaks, plus a code-level security review; nothing Critical, High or Medium ships. The 6.2 review is in the repo (https://github.com/tyxak/remotepower/blob/main/docs/security-review-6.2.0.md).

If you've been running Linux boxes on it and eyeing the Windows column with suspicion — this is the release to give it another look.

Repo + docs: https://github.com/tyxak/remotepower

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.