You know how it goes. You're happily using Homer or Homepage for your home-lab dashboard. It's great. It looks nice. It does its job. But then one evening you think: "Wouldn't it be cool if the dashboard actually showed whether my services are alive without building a custom tile for homer?"
And instead of, oh I don't know, contributing to homer or using Uptime Kuma next to it like a reasonable person, you go full not-invented-here and build your own thing from scratch.
So here's ilias, a static HTML dashboard generator that actually checks your stuff.
What makes it different from Homer / Homarr / Dashy / the other 47 dashboards?
It actually runs arbitrary checks. You give it a YAML config with HTTP endpoints and shell commands, and it:
- Executes all the checks in parallel (so treat it like a shell script and don't be stupid!)
- Matches results against rules you define (status codes, exit codes, regex on output)
- Bakes everything into a single, self-contained HTML file. No JavaScript, no API server, no database, no Docker container running in the background
The output is literally one .html file. You can scp it to a Raspberry Pi running nginx, open it from a USB stick, email it to yourself ... it just works. It's HTML and CSS. That's it.
The "why should I care" summary
- Zero runtime dependencies. No Node.js, no Docker, no database. One tiny binary, one HTML file out.
- Active health checks. HTTP requests, shell commands, regex matching on output. Not just a bookmark page.
- Generate blocks. Run a command before rendering: pipe a Prometheus query into a chart, embed the image as a banner: now your dashboard can show graphs.
- Single HTML file output. Icons, CSS, images, everything is inlined. The file is fully self-contained.
- NixOS module included. Systemd timer, nginx vhost, sandboxed service. If you're a NixOS person, it's
services.ilias.enable = true and you're done (after verifying my code ofc, I'm just a rando on the internet!).
- ~1,100 lines of Go. One external dependency (
gopkg.in/yaml.v3). That's the whole thing. You can read the entire codebase during lunch.
Quick taste
Minimal config:
title: My Lab
groups:
- name: Services
tiles:
- name: Jellyfin
icon: https://cdn.jsdelivr.net/npm/simple-icons@v9/icons/jellyfin.svg
link: http://jellyfin.lan:8096/
slots:
- name: status
check:
type: http
target: http://jellyfin.lan:8096/health
rules:
- match: { code: 200 }
status: { id: ok, label: "✅" }
- match: {}
status: { id: down, label: "❌" }
ilias generate -c config.yaml -o index.html
Done. Open index.html. Your Jellyfin tile shows ✅ or ❌ based on whether /health returns 200.
Want to check disk space too? Add a command check:
- name: Disk
slots:
- name: root
check:
type: command
target: "df / --output=pcent | tail -1 | tr -d ' '"
rules:
- match: { output: "^[0-6]\\d%$" }
status: { id: ok, label: "✅ <70%" }
- match: { output: "^[7-8]\\d%$" }
status: { id: warn, label: "⚠️ 70-89%" }
- match: {}
status: { id: full, label: "🔴 ≥90%" }
Hover over any status to see the raw command output in a tooltip. Regex matching on stdout. Exit codes. The works.
"But what about..."
Uptime Kuma? Uptime Kuma is excellent for monitoring with alerting, history, and notifications. ilias can't do any of that! It's for when you want a single glanceable status page that you regenerate every 5 minutes via cron ro whatever. No history, no alerts, no database. Just "is everything green right now."
Homer? Homer is a beautiful bookmark dashboard. ilias took that idea and asked "what if the bookmarks could tell you if my random, unsupported service behind them is actually working?" If you just want a pretty link page or use the services already supported, Homer is great. If you want status checks for everything baked in, give ilias a try.
Links
Edit:
Based on the suggestions from the comments that the config might be a tiny bit noisy, I implemented a few easy ways to simplify bigger configs (see here ). Since I'm misusing semver for pride-versioning, that bumped my version up to a whopping 0.2.0 🥳
Edit 2:
Someone said they might use this to make service health publicly available to customers, which made me worry about information leakage.
And since I couldn't stop worrying, I added:
--no-tooltips param: Don't include command output for hover tooltips to prevent system information from leaking--no-timestamp param: Omit the "Generated at" timestamp to hide system clock and monitoring cadence.
If you're using these, I feel much better about making the html publicly accessible, but when you set up a config please remember that link-tags can expose your internal topology and the tile/slot name might do the same! Don't go naming your tiles something like "Database Primary", "Payment Service Worker", or "Internal Auth API"!
