Add Service Dash - #1024
Conversation
Service Dash turns an existing Uptime Kuma status page into a homelab dashboard: each service gets one card carrying both its local (LAN) and external (public) URL, alongside host CPU, RAM, storage and network metrics from a bundled Netdata Agent. Validated with the repo's own tooling: validate-compose reports no issues for Apps/ServiceDash, and build-store-v2 builds the app with zero errors and zero warnings against this repository's store-config.json. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This is a great app. Please add more languages. |
IceWhale's maintainer asked for more languages on the upstream PR (IceWhaleTech/CasaOS-AppStore#1024). Their store's own apps -- Jellyfin, Plex, Syncthing, Immich -- all carry the same fifteen, on the same three fields, so that is the set: tagline, description and release_notes, plus tips.before_install, which most apps leave English but which is the text that stops a failed install here. title stays en_US. It is a product name. Product names, monitor names (`Plex local`), environment variables, ports and the on-screen "URL Locked" label stay English in every locale. They are strings a user types or reads on screen, not prose -- a translated `Plex local` names a monitor the pairing rule will not recognise. Two guards had to move, because translating the text created two new ways for it to go quietly wrong: check-release.py tested `version not in notes_text` across the whole release_notes block. With fifteen locales in there, updating one satisfies it while the other fourteen describe the previous release -- the same staleness the check was written for after the store's What's New sat at 1.3.2 for three releases, only harder to see. It now checks each locale separately, and additionally requires all four translated fields to carry an identical locale set, so a language added to the description but not to the release notes fails rather than shipping half-translated. sync-appstore-upstream.py swapped the install-Kuma sentence in English only, which was correct while the tips were English only. Translating them would have shipped fourteen locales telling IceWhale's own users to install Uptime Kuma from the ZimaOS store instead of theirs. The swap is now a per-locale table, every entry required, and the render aborts if any mention of the wrong store survives. Both guards were mutation-tested: a zh_CN release note left at 1.5.0, a locale dropped from tagline only, and a reworded ja_JP install sentence each fail by name, and pass again once restored.
Localises tagline, description, release_notes and tips.before_install into the same fifteen locales the store's other apps carry. title stays en_US as a product name. Product names, monitor names (`Plex local`), environment variables, ports and the on-screen "URL Locked" label are left in English in every locale: they are strings the user types or reads on screen, not prose. Also updates the entry from 1.3.2 to 1.5.1, which adds linux/arm64 alongside amd64 and two optional services that idle unless signed in.
|
Thanks — glad it's useful. Languages are in, the same fifteen your other apps use. I did the install tips as well, since that's where the Uptime Kuma prerequisite and the monitor naming are explained — easy to trip over in a second language. Left in English on purpose: the title, and anything typed or shown on screen ( Also bumped the entry to 1.5.1 — it had gone stale. arm64 now too. |
|
While I was testing, I noticed that the page wasn't displaying the Docker installation correctly. I checked the status of each service, and they are all showing the correct status. I apologize for the inconvenience, but I was unable to perform the installation myself on ZimaOS. If you require logs, please let me know how to provide them. |
From your screenshot, the install itself is healthy: metrics, storage, and network are all live, so the containers and nginx config are fine. The only thing that failed is the link to Uptime Kuma. Status: OFFLINE, sitting next to Metrics: REALTIME is exactly that split. Service Dash builds its cards from an Uptime Kuma status page on the same host. It needs Kuma reachable on KUMA_PORT (default 3001) and a status page whose slug matches STATUS_SLUG (default "homelab"). Without both, the grid is empty—which is all it managed to tell you. This one line says which of the two it is: sudo docker exec service-dash sh -c 'wget -S -O/dev/null --timeout=5 "http://host.docker.internal:3001/api/status-page/homelab" 2>&1 | head -3'
No logs needed. I'm adding a proper empty state so this explains itself instead of showing a blank grid. |
1.5.2 makes an empty dashboard explain itself. A blank grid previously said almost nothing -- a small OFFLINE in the top bar and a toast that cleared itself after five seconds -- so a first install could not be told apart from a broken one. A blank grid now names which of three things happened and what to do: Uptime Kuma is unreachable (with the fact that it is a separate application this does not bundle, and the steps to install it), the status page has no monitors on it (with the steps to add a group and publish), or the search and filters are hiding the cards. Images are multi-architecture as before. No Compose changes beyond the tags and no new services.
|
|
Update — this is fixed in 1.5.2, which I've just pushed to the PR. The blank screen you hit now explains itself. It turned out there were three quite different reasons a grid can be empty, and the page told you none of them, so it now says which. Your screenshot was the giveaway: metrics, storage, and network were all live, so the install was fine—only the Kuma link had failed. That's what the old page couldn't tell you, and now it does. |
2 participants
What this is: a new app.
Service Dash turns an existing Uptime Kuma status page into a homelab dashboard. Each service gets one card carrying both of its addresses — the internal (local) URL you use at home and the external (public) URL you use away from it — beside live host CPU, RAM, storage and network throughput from a bundled Netdata Agent.
It pairs naturally with two apps already in this store: it reads monitors from Uptime Kuma and bundles a Netdata Agent for host metrics.
What changed
One new directory,
Apps/ServiceDash/:docker-compose.ymlx-casaosblockicon.pngthumbnail.pngscreenshot-1..3.jpgNothing outside that directory is touched.
Metadata follows the conventions in the existing apps rather than only the spec minimum:
idisorg.icewhale.servicedash, assets point at this repository's jsDelivr path, category is Networking (matching Uptime Kuma), andauthor/developername the project rather than the packager, since they are the same person here.tips.before_installcovers the one real prerequisite — Uptime Kuma must be running on the host — and explains the monitor-naming convention that produces the paired local/public URLs.How it was validated
Run with this repository's own tooling, not a reimplementation:
.github/actions/validate-compose(--app-path ServiceDash)build-store-v2against this repo'sstore-config.jsonamd64verified against the live registry manifests for all 5 imagesThe build was run scoped to this app rather than over all 168, to avoid hammering the registries for apps this PR does not touch.
Notes
architecturesdeclaresamd64only, which is what the images publish today. arm64 builds have just been enabled upstream and will be added here in the release that first ships them — the build verifies this claim against the registry, so it cannot be declared early.netdatamounts the host rootro,rslavefor its disk collector, and Docker socket access goes throughcetusguardrestricted to twoGETnetwork endpoints — the dashboard never gets a writable socket.id, category, or any metadata to whatever you prefer.