OpsCommandCenter is a self-hosted, LAN-only RMM-style dashboard: an agent on each managed device (Windows, Linux, or Android) reports hardware/health telemetry to a central Server, which stores it and pushes live updates to a Blazor dashboard over SignalR. No cloud, no subscriptions.
Windows Agent \
Linux Agent >-- HTTP/heartbeat --> Server (ASP.NET Core + PostgreSQL + SignalR + Dashboard)
Android Agent / (Ubuntu VM on Proxmox)
|
Browser (LAN)
Every agent speaks the same plain HTTP+JSON heartbeat to the same /api/heartbeat endpoint —
the Server doesn't care which platform sent it, which is what makes adding another platform
mostly a matter of writing a new client, not changing the Server.
- Server deployment (Ubuntu on Proxmox) - stand up the Server half of the system on a fresh Ubuntu Server VM.
- Windows Agent installation - silently install on each managed Windows PC and point it at the Server.
- Linux Agent installation - silently install on each managed Linux PC via systemd.
- Android Agent installation - a Termux script for phones/ tablets, no APK required.
This is a thin vertical slice, not the full product spec:
Working today: agents collect CPU/RAM/OS/disk-health/BitLocker-or-equivalent/Defender/ battery (where applicable) data and report every 10-30s; Server stores it and pushes live updates; dashboard shows one status-colored card per device (green/yellow/red/gray), with an automatic offline flip if a device stops reporting.
Not built yet (explicit follow-ups, not silently dropped): authentication (dashboard and the heartbeat endpoint are both open to anyone on the LAN), bulk actions, remote tools (RDP/PowerShell/VNC), alerts/notifications (email/Discord/Telegram), notes/TODO per computer, license tracking, hardware lifecycle tracking, maintenance calendar, audit trail, Proxmox VM monitoring alongside physical PCs.
- Disk health reporting depends on
MSFT_StorageReliabilityCounter(Windows) orsmartctl(Linux) being available - not always the case (confirmed on a Kingston SA400 SSD during testing), and shows "n/a" rather than a fabricated number when unavailable. Android has no disk health signal at all reachable from Termux. None of this affects a device's overall status color unless the data genuinely is available and genuinely is bad. - The Ubuntu Server deployment, the Linux Agent, and the Android Termux script have all been written carefully and build/cross-publish cleanly, but none of the three have been run on real target hardware - there was no Ubuntu VM, Linux PC, or Android device/emulator available in the session that built them. Treat your first real install of each as the first real test, and report back anything that needs fixing.
- BitLocker/Defender-equivalent security signals only exist in a genuinely meaningful form on
Windows (BitLocker/Defender) and Android (full-disk encryption state via
ro.crypto.state). Linux reports both as "n/a" rather than a shaky per-distro heuristic.