bobbanandClaude Sonnet 5
9c45a806c8
Third live integration: container status across every Docker host Dockhand manages, with start/stop/restart actions — matching the "dashboard + basic actions" depth from the plan. Talks to Dockhand's own aggregating REST API (bearer tokens, dh_...) rather than the raw Docker Engine API on each host directly, so one credential covers every host Dockhand is already connected to. Adapter built against Dockhand's real published OpenAPI spec (fetched from https://github.com/strausmann/mcp-dockhand/blob/main/docs/dockhand-openapi.json, 257 documented paths) since the instance itself isn't reachable from here — same "verify against the real shape, don't guess" approach as Gitea, just via the spec instead of a live instance: - GET /api/environments — the Docker hosts Dockhand knows about - GET /api/containers?env=<id>&all=true — containers per host ({id, name, image, state, status}) - POST /api/containers/{id}/{start,stop,restart}?env=<id> server/src/integrations/dockhand/adapter.ts fans the environments call out to one containers call per host (Promise.all) and flattens the result, tagging each container with its environment; one unreachable host returns an empty list for that host rather than failing the whole dashboard view. Follows the same config-in-UI + encrypted-credential pattern as Tailscale and Gitea. Verified: full build passes. Since Dockhand isn't reachable from here, ran a 14-check HTTP test against the live server instead of the real API — role gating, credential non-leakage, disabled-integration blocking, and (critically) re-confirmed the wrong_type crash-safety pattern holds for this third adapter type: hitting the Dockhand routes on a differently-typed integration row returns a clean 400 rather than crashing the process, and the server keeps responding to /health afterward. Real container data and the start/stop/restart actions still need verification once this app runs on the user's LAN where Dockhand is reachable. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Homelab Manager
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
Built so far:
- Monorepo scaffold, Tabler-themed app shell/navigation
- Authentik OIDC login, roles (first user to sign in becomes admin), audit log
- Secrets — expiry tracking for API tokens/certs/passwords
- IP Addresses (IPAM) — inventory of IPs across vendors/locations
- 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 & Tasks — 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) - Integrations → Tailscale — device list with online/authorized status, and authorize/deauthorize/remove actions; a live device-count widget on the Dashboard.
- Integrations → 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) on the Dashboard.
Both integrations follow the same config-in-UI + encrypted-credentials pattern as DNS providers, so the remaining ones slot into the same "Add integration" form as they're built.
Not yet built (see .claude/plans for the full delivery plan):
- Remaining live integrations: Proxmox, Synology, Semaphore, Dockhand
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.