Free, open source, self-hosted Starlink fleet monitoring exists, and the projects range from actively maintained to quietly abandoned. A good one shows itself in five places: somebody is still maintaining it; the record survives an outage rather than leaving a hole; it survives an update rather than losing what it had collected; the documentation tells you how to deploy it safely, not just how to start it; and you can see plainly what running it will cost you in time. Those are the five checks. They take an afternoon, none of them requires reading code, and they apply to any option in this space, ours included.
Why are there so many of these projects now?
Because a dashboard has become quick and cheap to build, and screenshots no longer tell you which projects have substance behind them.
Open source software was always a mixed bag; what protected users was how much effort a working system took to build, and the maintainers and review the survivors accumulated along the way. That barrier has gone, so the judging is now yours. The good news is that it does not require reading anyone’s code, only watching how a system behaves.
Who maintains it?
Look for signs of a maintainer, not signs of polish. A release history with dates, and something recent in it. Issues that get answers, even short ones. A licence and README honest about limits, and a named person or group behind the project.
None of these prove the software is good, but their absence tells you the project is a snapshot rather than a commitment. Monitoring is a commitment: it has to be trustworthy in six months, not just tonight. And free projects run on their author’s spare evenings, so a project can fall silent the month its author’s circumstances change. That is no slight on the authors, just the nature of free, and better known before you build a record on it.
Does the record survive an outage?
Unplug a site’s connection for an hour, restore it, and look at the chart for that period. The hour should fill in with what the terminal actually did. If the hole is permanent, the project polls rather than records, and the gaps will always sit exactly where the questions are.
Ask how deep the buffer goes while you are at it. Hours suits an office with a flaky line; a vessel that spends four days out of contact needs days.
Does it survive an update?
Restart or update the software running at the site, then check whether the data it had buffered is still there. Store-and-forward is the promise most often made and least often tested: if the buffer lives somewhere the update wipes, the guarantee goes with it, quietly, the first time you upgrade.
It matters more here than anywhere else, because with a self-hosted project you are the one applying updates. A system that loses buffered data on restart will lose it repeatedly, on your schedule, without telling you.
Does the documentation cover deploying it safely?
Read past the quick-start and see whether the project tells you what to put in front of it. Many good self-hosted tools serve plain HTTP and expect a proxy to handle encryption, exactly as Grafana and similar tools do. That is a normal division of labour rather than a flaw, and a small proxy such as Caddy handles certificates in a few lines.
What you are judging is whether the project says so plainly, and whether its defaults are safe for someone who follows the quick-start and stops there. While you are in the documentation, check what is needed to add a device to the fleet, whether that credential can be withdrawn later, and whether removing a device actually stops it reporting. Those are covered in more depth in how to evaluate fleet monitoring software.
What will running it cost you?
The software costs nothing. The running of it is yours, and it is ongoing. It is not difficult work, but it is worth seeing whole before you start rather than discovering it in pieces.
Something has to be on all the time, because monitoring only knows what it was awake for: a small always-on box, a Pi on a shelf, a spare mini PC. A laptop that sleeps leaves holes in exactly the periods you later want to examine. Updates are yours to apply, since nothing will tell you a fix exists. Back up what you collect, because the whole point is a record you can look back at, and a record on one disk in one place is one failure from not existing. And someone has to notice when the monitoring itself stops, which is the part people miss: a dead monitoring system looks identical to a fleet with no problems, and that is when it is trusted most.
Who is self-hosting actually for?
If you have the time and the inclination, it is for you. At five terminals, for someone comfortable with Docker and a weekend of setup, that list is perfectly reasonable. You keep the data on your own infrastructure, you can inspect exactly what the software does, and the good projects are worth using and worth contributing to; contributing back is how a promising project becomes a maintained one.
If someone else can dispute what the record says, think harder. A customer querying a bill, an insurer asking whether a link was up, a contract with an availability clause: at that point the record has to hold up in an argument, and our guide on what uptime actually means sets out what a defensible one looks like. The honest question is not which software is better. It is whether you want to be the person defending the numbers, applying the fixes and getting up when the alerting itself goes down, or whether you would rather that sat with someone else.
One distinction worth knowing before you choose: self-hosted and open source are not the same thing. You can run supported software on your own infrastructure, keeping the data on your network while the software, its updates and its behaviour are someone else’s responsibility. Nexus Telemetry Fleet offers that, and a managed option for operators who would rather not run a server at all.
The short version
Check that somebody is still maintaining the project: dated releases, answered issues, a name behind it. Unplug a site for an hour and check the gap fills in. Restart the software and check the buffered data survived. Read past the quick-start to see whether the project tells you how to deploy it safely. Then price free as your own ongoing time: an always-on machine, updates, backups, and someone to notice when the monitoring itself stops. Nothing filters these projects before they reach you now; these five checks are the filter. If the job suits you, use the good projects and get involved with them. If the record has to hold up in an argument, or you would rather not carry the running of it, choose software someone else is responsible for, whether you host it or they do.
Part of Starlink Fleet Monitoring: The Complete Guide. Nexus Telemetry Fleet is built by Liquidbinary Ltd, the team behind the first Starlink Enterprise management platform. The founding-operator beta is available from Monday 31st August: join the beta.