Patching, monitoring, remote access, software inventory and scripted remediation — the boring, essential half of running a fleet. Same project as the EDR, sharing one agent and one console.
One agent, six platform targets 1.15M metric samples
One archive for the whole platform — the RMM, the EDR and the mail gateway are the same codebase and the same agent. No sign-up, no licence key.
Verify it before you trust it:
sha256sum sd-edr-rmm-latest.tar.gz 417e205eaaa9f7e10c289a48d0c557b8e519115ac8224eb14f36eec7fcb8fe04
go build and it's yours.The RMM and the EDR are one platform. Whichever way you run it, you get both.
One control plane, however many agents you like. Useful if you are an internal IT team who wants management tooling you host yourself, or a consultant who would rather run something you can read the source of.
One command on the machine, and it shows up in a console you didn't have to build. Free while it's useful to you. If it turns into a serious fleet running on my hardware, we'll have a conversation about that before it costs you anything — and you can always take your data and leave.
the same software at ten machines or a thousand · every feature, whichever way you run it
One Go binary per machine. No runtime to install, no Python on your endpoints, no separate agent per feature.
CPU, memory, disk, uptime and network sampled continuously — 1.15 million samples on my own fleet so far — with offline detection and a per-device health grade so you can see what needs attention without reading a dashboard full of green.
Installed software is inventoried (9,825 packages across my fleet) and matched nightly against the OSV vulnerability database. Patch-aging means you can see what's been unpatched for ninety days, not just what turned red today.
Click-to-SSH from the console with host-key pinning on first use, scripted remediation across the fleet, and remote desktop through an embedded MeshCentral instance — someone else's excellent open-source project, not mine.
Hardware and software inventory per device, so the question "what are we running and where" has an answer that isn't a spreadsheet somebody last updated in March.
Rule-based alerting with throttling and per-organization notification policy, pushed to ntfy, email or webhook. The throttle matters more than the rules — an alert channel nobody reads is worse than no alert channel.
Every remote command, every script run, every configuration change lands in a hash-chained audit log. If someone reaches into a machine through this tool, there is a record of who and when.
Management and security share the same agent and the same control plane, which is the whole reason this is worth running. The patch data feeds the vulnerability matching; the inventory feeds the detections; the audit log covers both. Most stacks make you buy those separately and then integrate them yourself.
The parts I'd trust on your fleet tomorrow, and the parts I wouldn't.
| Monitoring & inventory | Working | 1,150,570 metric samples and 9,825 inventoried packages across a live fleet. This is the most exercised part of the platform. |
|---|---|---|
| Patching & vulnerabilities | Working | 1,270 updates tracked, 1,557 findings matched against OSV. Reporting is solid; automated patch deployment is deliberately conservative and still mostly a human decision. |
| Remote access | Working | 89 commands executed through the console, click-to-SSH with host-key pinning, and MeshCentral for desktop. Used daily. |
| Windows installer | Known bug | The branded installer reports success even when enrolment fails, so a machine can look deployed and never appear in the console. Install tokens are also single-use per download. Both are on the fix list and both are exactly the sort of thing that makes an open-source deployment miserable. |
| Database migrations | Missing | There is no migration framework — schema changes have been manual because I've been the only operator. That is fine for one person and completely unacceptable for a project other people upgrade. It's a prerequisite for the public repo. |
| Packaging for strangers | In progress | The deployment still assumes my infrastructure in places. Untangling that into something you can stand up from a clean VPS is the current work, and it's the honest blocker on the repo going public. |
| Endpoint security | See the EDR page | Detection works and has real production time; real-time blocking is built but not armed. The full status is written out there. |
| Third-party audit | None | No SOC 2, no external penetration test. Self-reviewed and self-hardened, which is not the same thing. |
Numbers queried from the live platform on 30 August 2026.
Written to manage my own machines properly, then open-sourced. It's the same codebase I run everything on.
If you want it on your own hardware and you'd like a hand — deployment, integration with the identity and mail you already have, alert tuning, or just someone you can reach when something breaks — that's the part I charge for.
Tell me what you're managing — how many machines, what they run, and what you're using today — and I'll come back within a business day with a straight answer on whether this is worth your time. If something off-the-shelf fits you better, I'll say so.
Prefer email? Write to info@sd-techsolutions.com. I reply within one business day.