The Question Monitoring Tools Can’t Answer
Something breaks on a Wednesday afternoon. You spend an hour triaging, you find the cause, you fix it. Thursday morning someone asks the reasonable follow-up: was that machine actually patched when it went down?
You go look. Your monitoring tool says yes, patched. But that is what it thinks now. It has no idea what it thought yesterday, because when the new inventory came in it wrote over the old one. The record of what you believed during the incident is simply gone, overwritten by the truth that arrived afterward.
So you are left reconstructing your own past from memory and chat logs. Everyone has done this. Nobody enjoys it.
Two Clocks Instead of One
Everwas stores every inventory fact on two separate time axes. One records when something was true on the machine. The other records when the server found out.
Those are genuinely different questions, and conflating them is what makes post-incident analysis so slippery. “Was web-01 patched during the outage?” and “did we know it was patched while we were triaging?” can have opposite answers, and both of them matter.
Keeping both means late-arriving data stops silently rewriting history. An agent that was asleep during the incident and reports in at midnight adds to the record instead of replacing it. You can ask what the fleet looked like at 2:14pm on Wednesday, and separately ask what you believed at 2:14pm on Wednesday, and get honest answers to each.
The project treats this as its signature rather than a footnote. Valid time gets amber, record time gets cyan, and that two-color motif runs through the whole interface.
The Rest of the Job, Done Properly
A memory model is only interesting if the tool underneath it actually works. Everwas does the ordinary things an RMM has to do.
Live telemetry and alerting with cooldowns, so a flapping disk does not page you eleven times. A real terminal in the browser, with sessions recorded for later review. Script delivery that survives sleeping laptops, because durable queuing means the work waits for the machine instead of evaporating. Inventory across Windows, macOS, and Linux. Patch management spanning five package systems: apt, dnf, pacman, Windows Update, and macOS softwareupdate.
The agent is a single static Go binary that dials out over an encrypted connection. Nothing to install underneath it, no inbound firewall holes to argue about with a security team.
Making the Fleet Legible
There is an MCP server built in, so an assistant can query the fleet directly instead of you copying terminal output back and forth.
The permissions are the interesting part. Reads are open. Anything that changes a machine requires an explicit confirmation, and without one you get a dry-run plan describing what would have happened rather than a change you did not ask for. Every call is written to an audit log.
That shape is deliberate. A tool with root on every machine in your fleet should make the safe thing automatic and the dangerous thing loud.
Licensed on Purpose
The server is AGPL-3.0, so improvements made by anyone hosting it come back to the commons. The agent is Apache-2.0, because a binary going on thousands of company machines should clear legal review without a meeting. Contributions use a DCO rather than a CLA, which means no single party accumulates the rights to relicense the project out from under the people depending on it.
That split is argued in public rather than buried in a LICENSE file. Anyone deciding whether to run this on their fleet deserves to see the reasoning, not just the outcome.
