Open source · self-host it or use mine · free to start

An EDR you can read
the source of.

My project, running in production on my own fleet for about a year. Host the whole stack on your own hardware, or point your agents at my instance.

Download the source Where it actually is

Running in production 1,232 Sigma rules · 5 intel feeds Linux · macOS · Windows

edr — one day on my own fleet

04:00:03 nightly: installed software matched against the OSV vulnerability database

08:02:11 intel refresh — 24,172 indicators loaded (abuse.ch · openphish) across 5 feeds

11:40:52 agent sd-mbp-m3 · 1,692,664 events ingested to date (process, file, network)

14:07:36 sd-server03: powershell-style encoded command [T1059.001] → Sigma rule match

14:07:37 → detection written · alert raised · every action hash-chained into the audit log

status: 8 agents reporting · 40,702 detections total · response is approval-gated, not automatic

Why I built it

And why I'm publishing it instead of selling it.

I needed to see my own machines

I look after infrastructure for small businesses. The tools for protecting that infrastructure are built and priced for companies with an IT department — per seat, per month, on a contract — and the day you stop paying you lose the console and the history along with it.

I wanted to know what was actually happening on the machines I'm responsible for. So I wrote it: one agent, one console, my own hardware. It has been running on my own fleet for about a year before I showed it to anybody.

Why it's free

Because I'd rather be judged on the work than on a licence. Selling security software means guaranteeing it, and a guarantee is only worth what the person behind it can back. I'm one engineer.

What I can back completely is the work I do with my own hands — designing the network, standing up the servers, configuring Microsoft 365 or Sophos properly, tuning detections against your actual workload, and being reachable when it matters. That's the part worth paying for, and it's the part I sell.

The software is better off readable. If it's any good you can confirm that yourself rather than taking my word for it; where I've got something wrong you can see exactly where, because I've written it down. And if I disappear tomorrow, nothing you depend on switches off.

Download it

The whole platform — control plane, agent, mail gateway, console and tests. No sign-up and no licence key.

sd-edr-rmm-latest.tar.gz · 0.8 MB · AGPL-3.0 · v0.1.0-e3cbfe3 · 2026-09-02

Download the source ↓

Verify it before you trust it — that's the point of having the source:

sha256sum sd-edr-rmm-latest.tar.gz
fcb38ef7bc50fb92bef6be4e26f9924e094dfa89ca9db4c242e1d620ead2ade9

README.md — what it is, in one page.
INSTALL.md — Postgres, the service unit, the agent build, and the optional second node.
STATUS.md — read this one first. Every gap, named: what works, what's partial, what's missing.
LICENSE — AGPL-3.0. Run it, fork it, deploy it commercially. Publish your changes if you offer it to others over a network.

Builds are reproducible: rebuilding the same commit produces a byte-identical archive, so the hash above is something you can actually check rather than something you have to believe.

Two ways to run it

Same code, same console, same detections. The only question is whose hardware it lives on.

Self-host

Run the whole thing yourself

Stand the control plane up on your own server, point your agents at it, and nothing ever leaves your network. It runs without an account with me and without a licence key that can expire. If I disappear tomorrow, your security stack keeps running — that is the entire point of open source.

You own the data — detections, telemetry and quarantined mail sit in your Postgres, under your backup policy.
You own the roadmap — fork it, write your own detections, strip out what you don't want.
Optional second node — offload binary scanning, URL detonation and the sandbox to a cheap VPS so nothing dangerous executes next to your console.

Use my instance

Or skip the deployment entirely

Install the agent, point it at my control plane, and you have an EDR console this afternoon. It runs on the same hardened infrastructure I use for my own machines. Free while it's genuinely useful to you — and if you grow into a real fleet on my hardware, I'll tell you before it ever costs anything.

Nothing to deploy — no server, no database, no certificates to renew.
Per-organization isolation — the platform is multi-tenant by design; your estate is scoped to you, behind role-based access.
Move out whenever — it's the same open-source stack, so migrating to your own box is a data export, not a rebuild.

free while it's useful to you · the same source either way · leave whenever you like

Architecture

A control plane and a blast door

The design mirrors how I run it here. One control plane holds the console, the agents, the detections and the audit log. A second, disposable node does anything that involves executing hostile input — unpacking binaries, detonating URLs, running the sandbox — so the box holding your security data is never the box opening a suspicious attachment.

The control plane is a FastAPI service over Postgres: agent enrolment, the detection engine, the console, and the API. One VPS or one spare machine is enough for a small fleet.
The offload node is optional but recommended. It takes the jobs you don't want anywhere near production, and it is meant to be rebuildable from scratch without losing anything.
The agent is a single Go binary — no runtime to install, no Python on your endpoints, six platform targets from one build.

Control plane: FastAPI + Postgres · 41 tables · multi-tenant with per-org scoping
Agent: Single Go binary · Linux, macOS, Windows · process, file and network telemetry
Offload node: Binary scanning, URL detonation, sandbox — isolated from the console by design
Audit: Hash-chained log; destructive actions sit behind an approval gate

What's in it today

Four things, all running against my own machines every night before they run anywhere else.

Detection

The open Sigma standard

1,232 detection rules from SigmaHQ — the same open ruleset commercial SOCs build on — covering execution, persistence, defence evasion, credential access and network behaviour. Rules are data, not code, so writing one for your environment takes minutes and doesn't need a vendor.

Intelligence

Five live feeds, 24,172 indicators

Feodo Tracker, URLhaus, ThreatFox, MalwareBazaar and OpenPhish, refreshed on a schedule and matched against fleet activity. Malicious domains seen once are retained and blocked for good, rather than ageing back out of the feed.

Response

Approval-gated, never automatic

Isolate a device or kill a process from the console — behind a human approval gate, with every action written into a hash-chained audit log. Nothing on your fleet gets killed because a rule fired at 3 a.m. and nobody was watching.

Vulnerabilities

Nightly CVE matching

Installed software on every agent is matched against the OSV vulnerability database each night, with patch-aging so you can see what has been ignored for ninety days rather than just what is red today.

Part of the same project

Email security, in the same console

Most attacks still arrive by email, so the gateway shares the project's threat intelligence and audit log rather than being a separate product. It filters mail in transit in front of Microsoft 365 or Google — it never hosts your mailbox, and reverting is a DNS change.

Inbound filtering — attachment and archive inspection with ClamAV, phishing and impersonation detection, real SPF/DKIM/DMARC verification.
Click-time link protection — URLs re-checked at the moment someone clicks, not only at delivery.
Quarantine with self-serve release — per-recipient, with a digest. Nothing is silently deleted.
Mailbox scanning — where a gateway is overkill, it reads an existing Gmail mailbox directly through the API and flags what's already sitting in it.

Straight answer on maturity: the mail gateway is the least proven part of this project. It has run one domain and a handful of messages. The endpoint side has a year of production behind it; the mail side does not. See below.

Sits: In front of Microsoft 365, Google Workspace, or any host — mailboxes never move
Scans: ClamAV plus the same abuse.ch / OpenPhish intelligence the EDR uses
Rollback: Revert one MX record and you are back where you started
Gap: No IMAP support yet — that is the next thing I'm building

Where it actually is

An honest read of what works, what half-works, and what I haven't built yet — because you're going to find this out anyway, and I'd rather you heard it from me.

Endpoint detection	Working	1,692,664 events and 40,702 detections across a live fleet. This part has real production time behind it.
Detection spread	Needs tuning	40,513 of those detections came from one noisy macOS development machine. Linux has 189. Windows has produced none yet. The engine works; the tuning is unfinished.
Real-time blocking	Not armed	Pre-execution blocking via fanotify is built but deliberately disabled — it deadlocked a host under load and I won't ship that. Today this is detect-and-alert with approval-gated response, not prevention. Fixing this properly is the top item on the list.
Email gateway	Early	The code path works end-to-end, but it has handled one domain and four messages. Treat it as a pilot, not a production mail filter.
Mail provider support	Partial	Gmail via API is live. Microsoft 365 is roughly half done. There is no IMAP support at all yet, which is what "works with any provider" actually requires.
Remote management	Working	Patching, monitoring, remote desktop, scripts and click-to-SSH all run daily. Details on the RMM page.
Third-party audit	None	No SOC 2, no external penetration test, no certification. I've done my own red-teaming and fixed what it found. That is not the same thing and I won't pretend it is.
Public repository	In progress	The code is being untangled from my own infrastructure so a stranger can actually deploy it. Licence and public repo to follow — that work is the current focus.

Numbers queried from the live platform on 30 August 2026. If you spot something on this page that doesn't match what you find when you run it, tell me and I'll correct it.

How the platform protects itself

If a tool is going to sit on every endpoint you own, you should be able to check how it's built before you trust it.

Access & identity

Multi-factor authentication on every account
Role-based access and least privilege
Brute-force lockout on login
Secrets encrypted at rest

Tamper-evident by design

Hash-chained audit log — every action recorded and verifiable
Destructive actions sit behind approval gates
Agents authenticate with signed requests; the secret never travels on the wire
A locally paused agent reports itself as a tamper event

Where the data sits

Self-hosted: entirely on your hardware, wherever you put it
My instance: self-managed hardware in Canada, not a US hyperscaler
Per-organization scoping between tenants
Off-box backups with restore verification

The model

I own the code

The agent, the console and the mail gateway are mine end to end. Run it, fork it, and never need me — that's a completely fine outcome.

What I charge for is the hard part: standing it up in a real environment, wiring it into the identity and mail you already have, and tuning the detections so the alerts mean something.

Open: The source, the hosted instance while it's useful to you, and a straight answer
Paid: Deployment, integration, detection tuning, and ongoing hands-on support
Never: A licence key, a seat count, or a feature held back to sell you an upgrade

Want a hand getting it running?

Tell me what you're trying to protect — how many machines, what they run, and what you have in place today — and I'll come back within a business day with a straight answer on whether this is the right tool for it. If it isn't, I'll tell you that too.

Where you're exposed right now — email, backups, the old server, who still has a login
What's quietly costing you money
One thing you can fix this week

Prefer email? info@sd-techsolutions.com · Reply within one business day.