Lunalytics: a self-hosted uptime monitor with multi-user access at the centre
🚀 Open source monitoring tool built with Node.js
At a glance
- What is it?
- Lunalytics is a Node.js and React monitoring tool that checks HTTP, TCP, PING, JSON Query, PUSH and Docker containers, and its README states it is still in beta. The interesting part is not the check types but the account model: multiple users, role based access control and status pages designed to be shared.
- Who is it for?
- Adopt Lunalytics if you need several people to log into the same monitoring instance with different permissions, and you accept the README's own warning that the project is in beta and things may randomly break. Do not adopt it if you need a stable, long-lived monitoring stack with a documented upgrade path, or if MongoDB is a hard requirement, since the roadmap still lists it as unchecked.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 45 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The sharing problem Lunalytics was built around
The README's backstory is unusually direct about the motivation. The author writes that they like Uptime Kuma but that the main issue was the ability to share it with friends and colleagues, and that alternatives which do allow sharing either have an outdated UI or cost more than the author wanted to pay. Lunalytics is the response: a monitoring tool where multiple users are a first-class feature rather than an afterthought.
That framing matters when you evaluate the feature list. Multi-user support, advanced role based access control, customisable status and dashboard pages, and single sign on are listed alongside the check types, not buried at the bottom. The target user is a small team or a group of collaborators who want one instance that several people can log into, each with their own permissions and their own view. A solo operator running a handful of personal sites is not the audience the README is arguing for, even if the tool would work for them.
What Lunalytics actually checks
The feature list names six monitor types: HTTP(s), TCP, PING, JSON Query, PUSH and Docker Containers. That covers the usual web uptime case plus a few that matter in specific setups. JSON Query implies asserting on a value inside a JSON response rather than only checking that the endpoint returned 200, which is the difference between knowing a service is up and knowing it is returning usable data. PUSH inverts the direction: instead of Lunalytics polling a target, the target reports in, which is the pattern you need for cron jobs and batch tasks that have no listening port.
Docker container monitoring is the one worth thinking about carefully. The README lists it as a supported monitor type but does not describe the mechanism. Monitoring a container normally means either querying the Docker socket or API from the Lunalytics process, or running an agent inside the container. The material here does not say which, and that distinction decides whether Lunalytics needs the Docker socket mounted into its own container, which is a meaningful privilege decision. Check the documentation before assuming either way.
Install paths: Docker, Compose, npm, or pm2
The README gives four ways to run Lunalytics, and the Docker path is the shortest. The single command maps port 2308 and mounts two volumes, one for data and one for logs:
docker run -d -p 2308:2308 -v /path/to/data:/app/data -v /path/to/logs:/app/logs ksjaay/lunalytics:latest
The Compose file in the README uses the same image, container name, port and volume pair, so the two are equivalent in behaviour. Note that the data volume is where your monitors, users and incident history live. Backing up /app/data is the backup story unless the documentation says otherwise.
Installing from source has its own requirements: Node.js v22.14.0 or higher, npm or Yarn, and Git. The sequence is git clone, then cd Lunalytics, then npm run setup, then npm run start. The README also notes that node server/index.js works as a direct alternative to the start script. For a background process, the README documents pm2: pm2 start server/index.js --name Lunalytics, or pm2 start npm --name "Lunalytics" -- run start, followed by the optional pm2 save and pm2 startup. The README states the app will be accessible on https://localhost:2308, though the scheme in that line is worth confirming yourself since a fresh local install normally serves plain HTTP on that port.
Notifications and identity: where the integration surface sits
Lunalytics lists nine notification targets: Apprise, Discord, Email via SMTP, Home Assistant, Pushover, Slack, Telegram and Webhook, with the README adding "More to come". Apprise is the interesting entry because it is itself a notification abstraction layer, so routing through Apprise broadens the reachable services well beyond the eight named ones. The plain Webhook option covers anything the list misses.
On authentication, the README lists SSO support for Custom providers (naming Authentik, Authelia and Keycloak as examples), plus Discord, Google, GitHub, Slack and Twitch. The roadmap adds context that the README's feature list does not: the move to OAuth2 is still an open item, with the note that the project has moved to a session based system but not full OAuth2. Read those two sections together and you get a clearer picture than either alone. SSO exists, but the authentication layer is mid-migration, and release 0.10.23 is described as fixing bugs with status pages and session tokens. Session handling is an area that has been actively changing.
The beta warning is not boilerplate
The README carries an explicit caution block: the project is under active development and still in beta, and things may randomly break. The release history is consistent with that statement. Three releases are listed, 0.10.21 in January 2026 described as fixing various reported bugs, 0.10.22 in March 2026 updating a Discord URL regex and fixing auto not working, and 0.10.23 in May 2026 fixing bugs with status pages and session tokens. Each is a patch release on the 0.10 line, and each is framed as a fix rather than a feature.
That is a normal shape for a young project, but it has consequences for adoption. There is no stated long term support branch, no migration guide in the material, and no indication of how database schema changes are handled between versions. If you run the SQLite backend and a future release changes the schema, the README does not tell you what happens. The roadmap's unchecked item for session management, meaning the ability to track and log out of sessions, is another gap that matters more for a multi-user tool than for a single-admin one.
There is also a licensing wrinkle. The repository reports the licence as NOASSERTION, and the README simply points at the LICENSE file. NOASSERTION means an automated classifier could not map the file to a standard identifier, which can happen for a custom licence or a modified one. Do not assume MIT or Apache-2.0 from the tone of the project. Open the LICENSE file and read it, particularly if you intend to run Lunalytics inside a company or redistribute the image.
How Lunalytics differs from Uptime Kuma
The README names Uptime Kuma directly, so the comparison is fair game. The stated difference is not in check coverage. Uptime Kuma is a mature single-tenant-style monitor that many people run for themselves, and the Lunalytics author's complaint was specifically about sharing it with other people. Lunalytics answers that with multiple user accounts, role based access control, per-user API keys (the roadmap marks those as done), and customisable status pages that are meant to be handed out.
So the practical difference is the account and permission layer, not the probing engine. If you want a monitor that one person administers, Uptime Kuma's longer track record is a reasonable argument in its favour, and nothing in the Lunalytics README claims otherwise. If you want colleagues to log in, see only the monitors relevant to them, and receive their own notifications, that is the gap Lunalytics is aiming at. Whether the role model is granular enough for your organisation is something the README does not spell out, so read the documentation's RBAC section before committing.
Upgrade cost and what to verify before you commit
Running Lunalytics from the Docker image means upgrades are a pull and a restart, and your state stays in the mounted /app/data volume. Running from source means pulling the repository, re-running npm run setup, and restarting the process, whether under pm2 or directly. The README does not describe a migration step for data between versions, so the safe assumption is that you should snapshot /app/data before pulling a new image. That is not advice the project gives; it is the gap the documentation leaves.
The database situation is also worth checking against your own constraints. The roadmap shows PostgreSQL and SQLite support as completed and MongoDB as still open. If your infrastructure standardises on MongoDB, Lunalytics is not there yet. If you are on SQLite, confirm how the file is stored relative to the /app/data mount so that your backups actually capture it.
Finally, the Node.js v22.14.0 minimum applies to source installs. Docker users do not need Node on the host at all, which is the lower-friction path and the one the README leads with. Whichever you choose, the beta caution and the May 2026 session token fixes are the two facts that should shape how much you depend on this tool in production.
Editorial conclusion
Adopt Lunalytics if you need several people to log into the same monitoring instance with different permissions, and you accept the README's own warning that the project is in beta and things may randomly break. Do not adopt it if you need a stable, long-lived monitoring stack with a documented upgrade path, or if MongoDB is a hard requirement, since the roadmap still lists it as unchecked. Before deploying, verify the LICENSE file directly, because the repository reports NOASSERTION rather than a recognised identifier, and confirm the Node.js v22.14.0 minimum if you install from source instead of Docker.
Community notes