Carrot — Wiredwolves

Why I built it

Managing a handful of machines starts simple. You SSH in, run the command, check the logs, move on. It stays simple right until the number of machines makes keeping track of them the actual job.

The tools that solve this already exist. They're built for managed service providers and priced for them, and they run on infrastructure you don't control, with your machines reporting to someone else's cloud. The open source options were either built for one operating system or took more effort to stand up than they saved.

I wanted something I owned. Something I could read, change, and trust because I built it myself. So that's what I did.

What it is

Carrot is a self-hosted remote monitoring and management platform. You install the server on one Linux box and enroll your machines. After that, one dashboard answers the questions that used to take a dozen terminal windows: what's online, what each machine is running, when it last checked in, and what's happening on it right now.

From the same place I can run a command on one machine or fifty, scan for and apply patches, push software, run saved scripts, and read back what happened afterward.

The agents never accept incoming connections. They reach out to the server, ask if there's work, do it, and report back. That decision is the reason a machine behind a home router, a firewall, or a VPN works without any special setup. Nothing has to be opened up to reach it.

Enroll›Check in›Poll for work›Execute›Report back

What it looks like

The interface, top to bottom. Dark, flat, and built to be read at a glance.

Dashboard

The main view. Every enrolled machine across Windows, Linux, and macOS in one place, with live counts for what's online, offline, stale, and waiting on patches. The activity feed shows agents checking in and reporting snapshots in real time. The whole point of the project sits on this one screen: stop guessing what your fleet is doing and just look.

Patch management

Patching follows a scan, review, apply flow instead of firing updates blind. You pick an endpoint, see what is actually pending on it, and decide from there. Online machines are ready to act on right away; the rest show their real state so nothing happens to a box you can't currently reach.

Probe engine

Probes are how Carrot collects the data behind everything else. Each one targets a specific OS, runs on its own schedule, and returns a defined result type, whether that is a single value, a key/value set, or a full table. The built-in set already covers package inventory, OS details, disk and TPM status, FileVault and BitLocker, firewall state, and agent health. New probes get added without touching the rest of the system, which was the design goal from the start.

Reports

Fleet analytics built on the same data the agents report. Status counts, OS distribution, last-seen tiers, and a rolling heartbeat trend, with CSV export for anything you want to pull out. One detail I care about here: the page separates a machine's raw stored status from its actual operational health, because the two are not the same thing, and pretending they are is how dashboards start lying to you.

Settings

Where the operator owns the platform. Enrollment tokens, agent timing and the thresholds that decide when a machine counts as online, stale, or offline, log retention, and authentication. The status definitions are written out in plain language right next to the controls, so the rules the system runs on are never a mystery. Self-hosted means these knobs belong to you, not a vendor.

The part I care about

Anyone can wire up an API and call it a platform. The real work is in the decisions that never show up in a demo.

Take the agent installer, which is about the least glamorous part of the whole thing. The easy version drops files wherever and calls it done. Mine puts its files in the correct system locations, sets permissions so only the right account can touch them, and registers the agent as a managed service that comes back on its own after a reboot. Before it reports success, it verifies that what it just did actually worked. If the install didn't land, it tells you. It doesn't pretend.

Those are three deliberate choices inside one boring script. The files are protected, so a random user can't tamper with them. The service is built to stay up and recover by itself. Nothing reports "done" until it's confirmed true. That's confidentiality, availability, and integrity, handled as plumbing rather than as a tagline. Anyone who does this for a living knows what it takes to get right. Everyone else just gets a tool that installs cleanly and keeps running.

The rest of the system follows the same rule. There is exactly one place in the entire codebase where a network connection is allowed to skip its security check, and that's the single moment before a machine has the certificate it needs to verify the server. Nowhere else. That kind of rule is simple to write down and genuinely hard to hold to over time. Holding to it was the whole point.

How it actually went

This wasn't planned front to back and then typed in clean. I planned it, built it, broke it, figured out why, and fixed it, over and over.

Early on, reinstalling an agent created a duplicate record every time instead of recognizing the machine it already knew about. The installers were quietly saving a blank authentication token, so agents looked enrolled but couldn't prove who they were. I found each of those by reading the actual state of the machine after the fact instead of guessing, traced it to the exact line responsible, fixed it properly, and confirmed the fix before letting the change stand.

Observe, figure out what's really wrong, fix it, confirm. That's the job. The code is just where it ends up.

Where it stands

I'm not going to oversell this. Carrot is real and it works front to back, but it isn't a finished commercial product and I won't pretend it is. I'd rather tell you exactly where the line sits than put my name on something I haven't stood behind.

Solid, and I trust it

Agent enrollment
Endpoint visibility and status
Command system and results
System snapshots
Operational logging
Linux agent and installer

Real but still maturing

Deployment scheduling
Broader reporting
Probe library depth
Role-based controls
macOS patch support
Production hardening

Where it's going

The current version covers the core loop. I built the architecture from the start to take on more without tearing up what already works: security posture checks, compliance tracking, fleet-wide health scoring, real reporting. None of that is finished yet. But the foundation was laid with all of it in mind, which is a different thing from bolting it on after the fact.

Why I do this

I'm a problem solver. What I enjoy is understanding how a system actually works, the decisions behind it and the tradeoffs someone made and why. Building Carrot let me take an idea, turn it into a working thing, and then improve it through testing instead of guessing.

I don't expect everyone to understand why I'd build my own RMM, and that's fine. This is the work I care about, and this page is the honest version of it. Not a pile of buzzwords, just the thinking behind something I made and still maintain.