The dashboard the Control Plane replaced
Author’s note: this post was drafted by Claude (Anthropic) from my project notes and source code, then reviewed and edited by me before publishing. The voice and judgments are mine; the typing isn’t.
What it was
At any given time I have a dozen little local projects on this machine, each a web app that runs on its own port. Starting them meant remembering which folder, which script, which port — and stopping them meant hunting for the right console window. Server Dashboard fixed that with a single rule: drop a start.bat into a project folder and it shows up automatically.
It’s one Flask app and some vanilla JavaScript. It scans the sibling folders for a start.bat, parses the port each one serves on out of the script, and renders a card per project. A socket probe to each port, polled a few times a second, gives every card a live running/stopped dot. Click Launch and it runs that project’s start.bat exactly as if you’d double-clicked it; click Stop and it runs the project’s stop.bat, or failing that kills whatever’s listening on the port. An optional projects.json let me rename, re-emoji, or hide entries, or add things that weren’t start.bat projects at all.
It bound to 127.0.0.1 only and was never meant to leave the machine — it can launch arbitrary local programs, which is exactly the capability you don’t expose to a network.
It worked. For a good while it was the first thing I opened in the morning.
Why I retired it
The auto-discovery was elegant and also its ceiling. Discovering projects by their start.bat meant the dashboard only knew what a launcher script could tell it — a port and a folder name. It couldn’t tail a service’s logs, couldn’t embed a running app’s UI, couldn’t deploy or publish anything, couldn’t tell me why a service was unhealthy rather than just that its port was closed. It was a launcher, and launchers have a natural size.
When I needed those other things, the honest move wasn’t to keep bolting features onto a port-scanner. It was to build the tool the job actually wanted — a proper service supervisor with a real registry, log viewers, embedded service UIs, and deploy/publish workflows. That became the Control Plane, a desktop app (Rust + Tauri) that does everything Server Dashboard did and the things it structurally couldn’t.
So Server Dashboard is retired. In the Control Plane it survives as a single watch-only registry entry — listed, never launched, because two managers auto-starting the same projects would just fight over the ports. The folder is kept for reference, with a note at the top telling future-me (and any AI session) not to run it.
The point
This is the second project I’ve retired on purpose and written up (the first was a Rust key-value store), and there’s a pattern I like in both: retiring something isn’t failure when it’s because you’ve outgrown it. Server Dashboard taught me what I actually wanted from a service manager — by being a good-enough version that ran into its own limits. The Control Plane is a better tool partly because Server Dashboard showed me exactly where the ceiling was.
A tool that earns its own replacement has done its job. This one did.
— Luke Simmons, Auckland