Proxmox already runs vzdump backups, but nothing in the app said
whether they were actually succeeding — a silent backup failure is
one of the more dangerous blind spots a homelab admin can have. Adds
a "Backups" card to the Proxmox page: configured backup job
schedules (storage target, which guests, enabled/disabled) from
GET /cluster/backup, and recent vzdump task history per node from
GET /nodes/{node}/tasks?typefilter=vzdump, with a banner at the top
if the most recent run didn't succeed.
New "Proxmox backup failed" notification toggle under Settings ->
Notifications, on the same daily schedule as the other checks. The
scheduler checks each node's own most-recent vzdump run independently
(not just the single most recent task overall) so one node's healthy
backup can't mask another node's failing one in a multi-node cluster.
Known limitation, documented in the adapter's own header comment:
Proxmox's task list doesn't reliably expose which specific guest
failed within an "all guests" job — only the task's own log text has
that — so this surfaces job- and task-level status rather than
guessing at per-guest outcomes.
Verified against a fake Proxmox server (real self-signed HTTPS, since
the adapter's node:https usage can't be monkey-patched under ESM)
reproducing the documented /cluster/backup and task-list response
shapes: job parsing (all-guests+exclude vs specific-vmids+disabled)
correct, task OK/failure parsing correct, and the critical multi-node
scenario confirmed — one node's failing latest run flagged, the
other's healthy latest run correctly left alone, with exactly one
notification of the right content. This reproduces Proxmox's
documented API shape rather than a live-verified one; flag if the
real cluster's response differs in some way this didn't anticipate.
Confirmed the real dev database's mtime was untouched throughout.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Homelab Manager
Repository: git@10.200.5.13:bobban/Homelab-manager.git (gitea.labsconnect.se/bobban/Homelab-manager externally).
A single dashboard for a homelab: Proxmox, Synology DSM, Semaphore, Tailscale, Gitea, and Dockhand/Docker status and basic actions, plus DNS record management, an IP address inventory (IPAM), and a secret-expiry tracker (ported from Sloth Manager) and scheduled-task tracking across Debian/Raspbian hosts (ported from Schedule Task Manager). Looks and feels like a Tabler admin dashboard. Sign-in is delegated to Authentik (OIDC), with local admin/operator/viewer roles.
Status
All modules from the original plan are built:
-
Monorepo scaffold, Tabler-themed app shell/navigation
-
Authentik OIDC login, roles (first user to sign in becomes admin), audit log
-
Dashboard — an overview of every system this app tracks, all sharing one widget-card design (label + status badge, a small stat row, then its own breakdown): DNS (domain/record counts per provider, cached records by type), Secrets (monitored/expiring/expired, by type), and one widget per integration — Tailscale by OS, Proxmox by node (VM/LXC counts too), Dockhand by container state (plus host count), Semaphore and Gitea by last-run status (plus private-repo count), and Synology's CPU/RAM alongside its disk-health breakdown. Breakdowns render as a stacked proportion bar with a legend — no charting library, matching the rest of the app's plain-Tabler-CSS approach.
-
Diagnostic Log (admin-only) — every call this app makes to a DNS provider or integration (Tailscale, Proxmox, Synology, Semaphore, Gitea, Dockhand), success or failure, with latency and the error message if it failed — the last 500 calls, filterable by source/result, for troubleshooting connectivity issues (ported from Sloth Manager's provider-diagnostics log, generalized to cover every integration this app has, not just DNS)
-
Secrets — expiry tracking for API tokens/certs/passwords
-
IP Addresses (IPAM) — inventory of IPs across vendors/locations, with "Sync from Tailscale" and "Sync from Proxmox" actions to pull in tailnet device IPs and VM/LXC IPs (never overwrites a manually-entered IP), and each entry now shows its matching DNS record(s) from the DNS module's cache
-
DNS — zone/record management across Cloudflare, Loopia, Pi-hole, Azure DNS, cPanel, and Technitium; providers are configured in-app (not via env vars) and their credentials are encrypted at rest
-
Servers — cron/systemd tracking across Debian/Raspbian servers via a lightweight push agent (
agent/linux/), plus manual entries for things an agent can't see (Docker jobs, backups). The Servers page itself just lists registered servers and (admin-only) adds new ones / issues agent tokens; clicking a server opens its detail page with CPU/RAM/disk status, IP addresses, matching DNS names (looked up from the DNS module's cache), and its scheduled tasks — live hardware from Proxmox for VM/LXC-backed servers, or from the agent's own hardware report for everything else, both showing the same per-disk usage breakdown (an LXC's root filesystem read straight from the host; a QEMU VM's actual mounts via its guest agent, alongside the allocated size Proxmox already knew about without one). Proxmox-linked servers also get start/stop/restart buttons right on the detail page. The detail page also has an Admin Links section (operator/admin to add/edit/remove) for bookmarking that server's own admin UIs — Dockge, Webmin, Cockpit, Portainer, or anything else reachable by URL. Since not every server is a Proxmox VM, an admin can hide the "Proxmox link" card per server ("Not a VM? Hide this" / "+ Show Proxmox link options") — it stays visible regardless once a server actually is linked, so unlinking is always reachable. -
Tailscale, Proxmox, Synology, Semaphore, Gitea, and Docker each get their own top-level page (backed by the matching integration) instead of living inside a shared Integrations browsing view:
- Tailscale — device list with online/authorized status, and authorize/deauthorize/remove actions; a live device-count widget.
- Proxmox — VM/LXC status across every node in the cluster, with start/restart/shutdown/stop actions; a live running/total widget. Each online node also gets its own host-stats card — uptime, CPU usage/cores/ load average, RAM and swap usage, and per-storage usage (local, LVM-thin, ZFS, NFS, etc). Supports self-signed certificates (common in homelab setups).
- Synology — volume and disk health (read-only by design). Supports self-signed certificates.
- Semaphore — Ansible run status per template across every project, with a "Run" action to trigger a template; a live template-count widget (with a last-failed warning).
- Gitea — repo list with each repo's last CI run status, and re-running just the failed jobs in a run; a live repo-count widget (with a failing-build warning).
- Docker — container status across every Docker host Dockhand manages (one credential covers all of them), with start/stop/restart actions, a host filter, image-update status per container (from Dockhand's own cached update check, plus a button to trigger a fresh one), and a live running/total widget (with an updates-available count).
The Integrations page itself is now just a list of configured integrations (name/type/status, visible to every role) with an admin-only "Add integration" button and edit/enable/disable/delete actions per row — the six dedicated pages above are where you actually use each one.
-
Every table in the app is click-to-sort on any column (numbers, booleans, and dates/text sort correctly regardless of how the column formats them) and has an "Export CSV" button next to it that exports whatever's currently sorted/filtered. Tables that can realistically grow large (DNS zones/records, IP Addresses, Secrets, Servers, Audit Log, and each integration's device/container/guest/repo/template list) are paginated, 20 rows per page by default — adjustable under Settings → Display — and CSV export still covers every sorted/filtered row, not just the current page.
-
Settings (admin-only) — notification channels (Gotify, ntfy, SMTP, generic webhook) with per-channel test buttons, per-event toggles (DNS record added/updated/deleted, daily secret-expiry reminder and daily Tailscale key-expiry reminder — both sharing one configurable time/timezone), badge-color customization for both DNS providers and integration types, and a Display tab (date order, 12/24-hour clock, and rows-per-page for every paginated table) applied consistently across the app.
All six integrations follow the same config-in-UI + encrypted-credentials pattern, added (and edited — e.g. to rotate an expired API token without recreating the whole integration) through Integrations → Manage integrations. See INTEGRATIONS.md for exactly what credential to create and what access it needs in each target system, for every integration and DNS provider.
Verified for real, end to end: every module above — including all six
integrations, both their read-only views and their write actions
(start/stop/restart, trigger-a-run, authorize/deauthorize) — has been
exercised against the user's actual live homelab, not just built against
specs. That pass also found and fixed two real bugs: the Synology adapter
assumed HTTPS-only (the NAS is reached over plain HTTP), and the Tailscale
adapter read online/isExitNode fields that don't actually exist in the
real API response (fixed to derive them from connectedToControl and
enabledRoutes). See the git log for the full verification notes per
integration.
Requirements
- Node.js 20+
- An Authentik instance reachable from wherever this app runs
1. Set up an Authentik application
- Create an OAuth2/OpenID Provider:
- Redirect URI:
<APP_BASE_URL>/auth/callback - Scopes:
openid,email,profile
- Redirect URI:
- Create an Application using that provider, and assign the users/groups who should be able to sign in — Authentik controls who can authenticate; the app's own admin/operator/viewer roles control what they can do once in.
- Copy the provider's issuer URL, client ID, and client secret into
.env.
2. Local development
cp .env.example .env # fill in AUTHENTIK_*, SESSION_SECRET, CREDENTIALS_ENCRYPTION_KEY
npm install
npm run dev:server # http://localhost:3000 (API)
npm run dev:web # http://localhost:5173 (Vite dev server, proxies /api and /auth to :3000)
Visit http://localhost:5173 during development. Database migrations run
automatically on server start. SQLite data lands in ./data (gitignored).
Generate SESSION_SECRET and CREDENTIALS_ENCRYPTION_KEY with:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
3. Run with Docker
cp .env.example .env
# edit .env
docker compose -f docker-compose.dev.yml up -d --build # build locally
# or, once an image is published to your registry:
docker compose up -d
The app listens on HOST_PORT (default 3000); SQLite data persists in
./data on the host.