Self-hosted homelab dashboard — one container, one browser tab, live widgets from a plugin store.
Selbstgehostetes Homelab-Dashboard — ein Container, ein Browser-Tab, Live-Widgets aus dem Plugin-Store.

🇬🇧 English · 🇩🇪 Deutsch

📰 What's new / Neuigkeiten → CHANGELOG.md

🇬🇧 English

SelfDashboard is your personal control center for homelab and self-hosting: one Docker container, one browser tab — instead of a dozen open admin UIs. Widgets are plugins with real backends (Docker, FRITZ!Box, CrowdSec, calendar, mail …), installed from a Plugin Store and configured entirely in the UI. It is not a plain bookmark page and not a YAML-config dashboard.

Part of the Self family (SelfMailer, SelfStream, SelfArchiver …) — same design system, same deploy style (GHCR → Unraid).

TL;DR — live widgets via plugin store · multiple dashboards · login + 2FA + multi-user · kiosk mode for wall tablets · AES-256-GCM-encrypted credentials · single container · no external DB.

📑 Table of contents

Features · Plugins · How it compares · Architecture · Dashboards & widgets · Kiosk mode · Android app · Login & multi-user · Troubleshooting · Documentation · Quick start · Unraid · Configuration · Backups · Security · Tech stack · Development · Roadmap

✨ Features

Example layout below — SelfMailer calendar, clock, weather, FRITZ! history & power, AdGuard, bookmarks, Zoraxy, media, Uptime Kuma, WireGuard, CrowdSec, two Unraid servers, notes and the navbar mail badge. Every widget is a plugin, freely arrangeable and configurable.

🧩 Plugins & updates

• Volume-only plugin system — install from the Plugin Store (GitHub) or as ZIP; no widgets baked into the image
• Plugin updates — the store compares versions; badge + Update all, no image rebuild; Ctrl+F5 after an update
• Auto-index store — drop a plugin folder into plugins-pack/<id>/ and push; plugins-index.json regenerates automatically
• Central error log — Settings → Logs: app, API and plugin errors (filter, export, 3–30 day retention), automatic for every registered plugin

📋 Dashboards & design

• Multiple dashboards, each with its own URL (/dashboard/home, /dashboard/server)
• 6 color themes (Dark, Light, Nord, Catppuccin, Dracula, Solarized) + custom colors per dashboard
• Custom logo per dashboard; background images — navbar wallpaper + dashboard (1 or 2 JPG/PNG images) with readability overlay
• Drag & drop, free resizing, per-widget zoom, padding and height
• Dashboard zoom (60 %–150 %), adjustable grid spacing and outer padding
• Navbar options — icon only, text only or both; toggle dashboard tabs
• Responsive layout — phone / tablet / desktop grid based on dashboard width; optional per-widget overrides; compact navbar search (full-width row) on narrow viewports
• Unit system — global metric (°C, km/h) / imperial (°F, mph) / auto switch (Settings → General); Weather, FRITZ! Smart Home, Homematic and Google Home widgets pick up the choice (auto follows locale, defaults to metric)

✉️ Navbar mail (IMAP)

• Unread badge in the navbar — multiple accounts, Synology/MailPlus-friendly, encrypted passwords, click opens webmail

🔐 Security & platform

• Login & multi-user — SQLite auth, admin/user roles, plugin whitelist, optional TOTP 2FA
• Secure by default — non-root container, AES-256-GCM-encrypted credentials, SSRF guard on all proxy plugins
• Kiosk mode — public /kiosk URL, view-only full screen for wall tablets, optional password
• Multilingual — German & English interface
• Single container — Next.js 15, no external database (embedded SQLite for auth), no Redis
• Unraid ready — Community Apps template included

🧩 Plugins

Widgets are not bundled in the image — install them from the Plugin Store or upload a ZIP. Each plugin has its own README (EN/DE) under plugins-pack/<id>/. Install & folders: docs/PLUGINS.md · develop plugins: docs/PLUGIN_DEV.md.

Plugins marked (Beta) are new integrations that have not yet been tested against every server version — feedback (with the service version) is welcome.

All plugin READMEs are bilingual (EN/DE). Brand logos in the store via homarr-labs/dashboard-icons.

⚖️ How it compares

Heimdall, Homarr, Dashy and Homepage are all great projects — SelfDashboard just focuses on something different: live widgets with real backends, built-in auth and a kiosk mode, all configured in the UI.

A good fit if you want

• Live, interactive widgets (Docker control, FRITZ!Box, CrowdSec, calendar, mail) — not just links
• Multi-user with real auth / 2FA and a wall-tablet kiosk
• To configure everything in the UI instead of editing config files

Maybe not for you if

• You just want a simple bookmark/start page (Heimdall or Homepage are lighter for that)
• You can't run a Docker container, or prefer a purely static config-file workflow
• You need a large, established plugin ecosystem today — SelfDashboard's is younger and still growing

⚠️ Note: plugin server code runs with the app's privileges (no sandbox yet) — only install plugins you trust.

🧭 Architecture

 GitHub, branch main (catalog)            Host volume /app/plugins/custom
 plugins-pack/plugins-index.json          per plugin: plugin.json
 plugins-pack/<id>/widget.js                          + widget.js
                   (+ server.mjs)                     (+ server.mjs for some)
          │                                      ▲            │
          └──── Store: Install / Update ─────────┘            │ browser loads widget.js
                                                              ▼
 ┌─────────────────────── Docker image (core) ─────────────────────────┐
 │  Next.js UI · Plugin Store · dashboards                              │
 │  Built-in APIs: calendar, mail, docker, crowdsec, fritzbox, weather …│
 │  Gateway /api/plugins/{id}/…  ← plugin server.mjs                    │
 └──────────────────────────────────┬───────────────────────────────────┘
                                    │
                     Host volume /app/data
           dashboards · auth DB · calendar · central log

App update vs. plugin update

🖥️ Dashboards & widgets

Managing dashboards

Each dashboard gets its own URL. Navigate between dashboards via the tab bar in the navbar or through Settings → Dashboards.

Widget controls

In Edit Mode (✏️ button), hover over any widget to see controls:

Responsive layout (phone, tablet & desktop)

The dashboard uses three layout bands based on the dashboard grid width (the track that holds the widgets — not only the outer browser window):

How to tune it: enter Edit mode (✏️), open a widget's ⚙️ settings. Below the plugin-specific options, "Layout: phone & tablet" lets you set optional phone row height / min height and tablet position & size. Leave fields empty to keep using the desktop layout values for that band.

On narrow viewports (about ≤ 1024 px) the navbar web search moves to a second row at full width so it is not squeezed into the corner next to zoom and actions.

Plugins can optionally read the layoutMode prop ('phone' | 'tablet' | 'desktop') for their own responsive UI — see docs/PLUGIN_DEV.md.

Settings overview

• General — language (DE/EN), dashboard title, navbar web search, navbar mail badge, navbar display style, dashboard tab visibility, unit system (metric/imperial/auto)
• Users — change password, 2FA (TOTP), kiosk / wall tablet (admin). Admins also manage users and the plugin whitelist here.
• Dashboards — create, edit, delete dashboards; toggle tab visibility per dashboard; set emoji or custom PNG icon
• Design — navbar display style; grid spacing; navbar background (JPG/PNG + overlay); dashboard background (off / 1 image / 2 images side by side + overlay); logo upload; color theme; custom color overrides
• Email — IMAP accounts, navbar badge, poll interval, connection test
• Logs — central error log for support and debugging: filter by level, source, plugin; download .txt / JSONL; retention 3 / 7 / 30 days. Every plugin registered via registerPlugin logs render failures and failed /api/* calls automatically. Mail uses the same log with plugin id mail. Details: docs/LOGGING.md.

📺 Kiosk mode (wall tablet)

Public view-only display for a wall-mounted tablet or guest browser — separate from the normal logged-in dashboard. Ideal for a kitchen display, wall tablet or shared screen on your LAN.

📱 Android app

The SelfDashboard Android app shows the dashboard full screen on wall tablets. It contains no backend code of its own — it only displays your SelfDashboard web app.

🔐 Login & multi-user

SelfDashboard requires login. On first start (no users yet) you are redirected to /setup to create the admin account. Existing dashboard.json in appdata is migrated to that admin automatically (backup: dashboard.json.pre-auth-migrated).

🩺 Troubleshooting

📚 Documentation

🚀 Quick start (Docker)

docker run -d \
  --name selfdashboard \
  --restart unless-stopped \
  -p 3000:3000 \
  -e TZ=Europe/Berlin \
  -v /mnt/user/appdata/selfdashboard:/app/data \
  -v /mnt/user/appdata/selfdashboard/plugins:/app/plugins/custom \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/s3lfcod3r/selfdashboard:latest

Or with docker compose (see docker-compose.yml):

git clone https://github.com/s3lfcod3r/selfdashboard.git
cd selfdashboard
docker compose up -d

Open http://<host>:3000 → /setup creates the admin account → Plugin Store → From GitHub, install the widgets you need → + to place them → Ctrl+F5 if a widget stays blank.

• Required: map /app/data (dashboard.json, calendar, logs) and /app/plugins/custom (installed plugins). Without the plugins folder, the store can install files but they will not persist.
• Optional: Docker socket — Docker plugin only; CrowdSec mount — CrowdSec plugin only.
• Image tags: the Unraid template uses ghcr.io/s3lfcod3r/selfdashboard:latest. The plugin catalog is loaded from GitHub branch main (SELFDASHBOARD_PLUGINS_GITHUB_REF, normally left as-is).
• LAN services: if your widgets talk to LAN addresses (AdGuard, Pi-hole, FRITZ!, Home Assistant …), set SELFDASHBOARD_ALLOW_PRIVATE_URLS=1.

📦 Unraid

Add the template from https://raw.githubusercontent.com/s3lfcod3r/selfdashboard/main/unraid/selfdashboard.xml or import it under Docker → Add Container → Template.

Both Config Storage and Plugins Storage are required for a normal setup. After a plugin update: Store → Update → Ctrl+F5. After an app update: pull new image, restart — layouts and installed plugins stay on the volumes.

⚠️ Secret key: set a fixed SELFDASHBOARD_SECRET_KEY and never change it afterwards — it encrypts all stored credentials. Changing it makes them unreadable.

⚠️ Permissions: the container runs non-root. The template sets PUID/PGID 99/100 (nobody:users); on start the entrypoint remaps to your PUID/PGID and chowns /app/data + /app/plugins/custom automatically (opt-out: SELFDASHBOARD_SKIP_CHOWN=1). CrowdSec tip: set PUID/PGID to the same values as your CrowdSec container — then SelfDashboard owns and reads crowdsec.db directly, surviving nightly backups that restart CrowdSec (no chmod needed).

⚠️ LAN access: the template pre-sets SELFDASHBOARD_ALLOW_PRIVATE_URLS=1 (recommended in a home network), so widgets can reach LAN services.

⚠️ Self-signed HTTPS: leave NODE_TLS_REJECT_UNAUTHORIZED empty; 0 disables certificate checks for all outgoing HTTPS. Details: unraid/README.md.

⚙️ Configuration

Environment variables, mostly with the prefix SELFDASHBOARD_, plus a few runtime and plugin variables.

💾 Backups

Back up both host folders regularly — ideally offline / immutable, so ransomware on the mount cannot take data and key:

• /app/data — per-user dashboards (users/), images moved out of widget settings (blobs/, e.g. bookmark icons), auth DB (auth/auth.db), calendar, central log and the auto-generated key files (.calendar-key, .secret-salt)
• /app/plugins/custom — installed plugins

Also keep your SELFDASHBOARD_SECRET_KEY in a password manager — without it, stored credentials cannot be decrypted.

Restore — stop the container, copy the backup back into the mapped folders, start again:

docker stop selfdashboard
cp -a /path/to/backup/selfdashboard/. /mnt/user/appdata/selfdashboard/
docker start selfdashboard

🛡️ Security

SelfDashboard is built for a trusted home LAN. A security review (2026-06) hardened the auth and plugin surfaces; the points below matter if you expose the app beyond your LAN.

Hardened in code

• Login brute-force: failed attempts are counted persistently per account in SQLite (10 / 15 min → temporary lockout) — survives restarts, independent of client IP, so spoofing X-Forwarded-For does not bypass it
• Spoofable proxy headers are ignored unless SELFDASHBOARD_TRUST_PROXY=1
• Admin actions require completed MFA: user/role/plugin-grant management is blocked for sessions that have not passed the second factor
• Rate limits on change password and disable TOTP; TOTP replay protection (each code valid once)
• TOTP secrets encrypted at rest (AES-256-GCM via SELFDASHBOARD_SECRET_KEY) — a leaked auth.db alone cannot mint valid 2FA codes
• Credentials encrypted — calendar, mail and widget passwords/tokens sealed with AES-256-GCM; the browser only sees ciphertext
• Per-install salt — the key derivation uses a random salt that every installation generates once in /app/data/.secret-salt (no environment variable); keep it in your backups
• Docker container actions (start/stop/restart) require an admin with completed MFA — read-only listing stays available to widget users
• Plugin pack extraction validates every zip entry against path traversal (zip-slip) and enforces entry-count limits
• Plugin SVG assets are served with Content-Disposition: attachment, X-Content-Type-Options: nosniff and a locked-down CSP (no stored XSS via SVGs)
• Remote plugin integrity: if plugins-index.json ships a sha256 per file, every downloaded file (incl. executable server.mjs) is verified before it is written
• Internal identity headers (x-sd-user-id / x-sd-role) are stripped from client requests and not echoed on responses
• Env password reset is ignored in production unless SELFDASHBOARD_ENABLE_ENV_RESET=1
• SSRF guard on all outbound requests: loopback / link-local / cloud-metadata always blocked, private/LAN IPs blocked by default (opt in with SELFDASHBOARD_ALLOW_PRIVATE_URLS=1); CalDAV re-checks the resolved IP before connecting (DNS-rebinding protection), like IMAP/FRITZ!
• Non-root container, reproducible npm ci build, container HEALTHCHECK

Operator responsibilities / when exposing publicly

• Use HTTPS and set SELFDASHBOARD_SECURE_COOKIES=1 — over the internet, session cookies must be Secure
• Strip internal headers at the reverse proxy: drop incoming x-sd-user-id, x-sd-role and x-sd-kiosk request headers (defense in depth)
• TLS verification for IMAP/FRITZ! can be disabled per connection — leave it on unless you have a specific reason
• Use a strong admin password and a fixed SELFDASHBOARD_SECRET_KEY
• Docker socket = host root equivalent — mount it only for trusted admins and never expose it; read-only does not protect
• :latest + Watchtower (label in docker-compose.yml) rolls out new images without human approval — consider pinning a fixed version tag and removing the label for this powerful container

Deliberate trade-offs (documented)

• Plugin code runs with full server privileges — uploaded/remote server.mjs files execute in the Node process without a sandbox. Only install plugins you trust and treat the admin account as equivalent to shell access.
• Secure cookies are off by default so plain-HTTP LAN setups keep working
• Known lower-priority follow-ups: script-src still allows 'unsafe-inline' 'unsafe-eval'; DNS-rebinding/TOCTOU on generic outbound fetches would need connection pinning

Security update history → CHANGELOG.md (entries marked 🔒).

🧱 Tech stack

🛠️ Development

npm ci
npm run dev                    # Next.js dev server in the repo root
npm run lint                   # ESLint
npm run build                  # production build (vendors builtin plugins first)
npm run publish:plugin-pack    # build plugins-pack/ for the store
npm run generate:plugins-index # regenerate plugins-pack/plugins-index.json

Tests:

npm run test

Docker image build: docs/DOCKER_BUILD.md · plugin development: docs/PLUGIN_DEV.md.

🗺️ Roadmap

• Volume-only plugin system · GitHub Plugin Store · ZIP upload · auto-generated index
• Multiple dashboards · 6 themes · backgrounds · responsive phone/tablet/desktop layout
• Login · multi-user · TOTP 2FA · kiosk mode
• Non-root container · AES-256-GCM credentials · SSRF guard (private IPs blocked by default)
• Central error log
• Vitest test setup with first SSRF tests
• Plugin sandbox (plugin server code currently runs with app privileges)
• Nonce-based CSP instead of 'unsafe-inline' 'unsafe-eval'
• Connection pinning against DNS rebinding on outbound fetches
• Beta plugins tested against more server versions

⬆ back to top

🇩🇪 Deutsch

SelfDashboard ist dein persönliches Kontrollzentrum für Homelab und Self-Hosting: ein Docker-Container, ein Browser-Tab — statt zwölf geöffneter Admin-Oberflächen. Widgets sind Plugins mit echtem Backend (Docker, FRITZ!Box, CrowdSec, Kalender, Mail …), werden aus einem Plugin-Store installiert und komplett in der Oberfläche eingerichtet. Es ist keine reine Lesezeichenseite und kein Dashboard mit YAML-Konfiguration.

Teil der Self-Familie (SelfMailer, SelfStream, SelfArchiver …) — gleiches Design-System, gleicher Deploy-Stil (GHCR → Unraid).

Kurz — Live-Widgets aus dem Plugin-Store · mehrere Dashboards · Login + 2FA + Mehrbenutzer · Kiosk-Modus fürs Wand-Tablet · AES-256-GCM-verschlüsselte Zugangsdaten · ein Container · keine externe DB.

📑 Inhaltsverzeichnis

Funktionen · Plugins · Vergleich · Architektur · Dashboards & Widgets · Kiosk-Modus · Android-App · Login & Mehrbenutzer · Fehlerbehebung · Dokumentation · Schnellstart · Unraid · Konfiguration · Backups · Sicherheit · Tech-Stack · Entwicklung · Roadmap

✨ Funktionen

Beispiel-Layout unten — SelfMailer-Kalender, Uhr, Wetter, FRITZ! Verlauf & Strom, AdGuard, Lesezeichen, Zoraxy, Media, Uptime Kuma, WireGuard, CrowdSec, zwei Unraid-Server, Notizzettel und E-Mail-Badge in der Navbar. Jedes Widget ist ein Plugin, frei anordbar und einstellbar.

🧩 Plugins & Updates

• Plugin-System nur per Volume — Installation aus dem Plugin-Store (GitHub) oder als ZIP; keine Widgets im Image
• Plugin-Updates — der Store vergleicht Versionen; Badge + Alle aktualisieren, kein Image-Rebuild; danach Strg+F5
• Auto-Index-Store — Plugin-Ordner nach plugins-pack/<id>/ legen und pushen; plugins-index.json wird automatisch neu erzeugt
• Zentrales Protokoll — Einstellungen → Protokoll: App-, API- und Plugin-Fehler (Filter, Export, 3–30 Tage Aufbewahrung), automatisch für jedes registrierte Plugin

📋 Dashboards & Design

• Mehrere Dashboards, jedes mit eigener URL (/dashboard/home, /dashboard/server)
• 6 Farbthemen (Dark, Light, Nord, Catppuccin, Dracula, Solarized) + eigene Farben pro Dashboard
• Eigenes Logo pro Dashboard; Hintergrundbilder — Navbar-Hintergrund + Dashboard (1 oder 2 JPG/PNG) mit Lesbarkeits-Overlay
• Drag & Drop, freies Skalieren, Zoom, Innenabstand und Höhe pro Widget
• Dashboard-Zoom (60 %–150 %), einstellbare Grid-Abstände und Außenrand
• Navbar-Optionen — nur Icon, nur Text oder beides; Dashboard-Tabs ein-/ausblendbar
• Responsives Layout — Handy / Tablet / Desktop-Raster je nach Dashboard-Breite; optionale Overrides pro Widget; Navbar-Suche auf schmalen Bildschirmen in eigener voller Zeile
• Einheitssystem — globales Metrisch (°C, km/h) / Imperial (°F, mph) / Automatisch (Einstellungen → Allgemein); die Wetter-, FRITZ! Smart Home-, Homematic- und Google-Home-Widgets übernehmen die Wahl (automatisch folgt der Sprache, Standard metrisch)

✉️ Navbar E-Mail (IMAP)

• Ungelesen-Badge in der Navbar — mehrere Konten, Synology/MailPlus-tauglich, verschlüsselte Passwörter, Klick öffnet das Webmail

🔐 Sicherheit & Plattform

• Login & Mehrbenutzer — SQLite-Anmeldung, Admin-/Nutzer-Rollen, Plugin-Freigaben, optional TOTP-2FA
• Sicher ab Werk — Container ohne Root, AES-256-GCM-verschlüsselte Zugangsdaten, SSRF-Schutz in allen Proxy-Plugins
• Kiosk-Modus — öffentliche URL /kiosk, Nur-Ansicht im Vollbild fürs Wand-Tablet, optional mit Passwort
• Mehrsprachig — Deutsch & Englisch
• Ein Container — Next.js 15, keine externe Datenbank (eingebettetes SQLite für die Anmeldung), kein Redis
• Unraid-tauglich — Community-Apps-Vorlage dabei

🧩 Plugins

Widgets stecken nicht im Image — Installation über den Plugin-Store oder per ZIP-Upload. Jedes Plugin hat eine eigene README (DE/EN) unter plugins-pack/<id>/. Installation & Ordner: docs/PLUGINS.md · Plugins entwickeln: docs/PLUGIN_DEV.md.

Mit (Beta) markierte Plugins sind neue Integrationen, die noch nicht gegen jede Server-Version getestet sind — Rückmeldungen (mit Versionsangabe) sind willkommen.

Alle Plugin-READMEs sind zweisprachig (DE/EN). Marken-Logos im Store via homarr-labs/dashboard-icons.

⚖️ Vergleich

Heimdall, Homarr, Dashy und Homepage sind alle super Projekte — SelfDashboard setzt einfach einen anderen Schwerpunkt: Live-Widgets mit echtem Backend, eingebaute Anmeldung und ein Kiosk-Modus, alles in der Oberfläche eingerichtet.

Passt gut, wenn du willst

• Live-Widgets, die wirklich etwas tun (Docker-Steuerung, FRITZ!Box, CrowdSec, Kalender, Mail) — nicht nur Links
• Mehrbenutzer mit echter Anmeldung / 2FA und einen Kiosk fürs Wand-Tablet
• Alles in der Oberfläche einrichten statt Config-Dateien zu bearbeiten

Vielleicht nichts für dich, wenn

• du nur eine einfache Lesezeichen-/Startseite willst (dafür sind Heimdall oder Homepage schlanker)
• du keinen Docker-Container betreiben kannst oder einen rein statischen Config-Datei-Ablauf bevorzugst
• du heute ein großes, etabliertes Plugin-Angebot brauchst — das von SelfDashboard ist jünger und wächst noch

⚠️ Hinweis: Plugin-Server-Code läuft mit den Rechten der App (noch keine Sandbox) — installiere nur Plugins, denen du vertraust.

🧭 Architektur

 GitHub, Branch main (Katalog)            Host-Volume /app/plugins/custom
 plugins-pack/plugins-index.json          pro Plugin: plugin.json
 plugins-pack/<id>/widget.js                          + widget.js
                   (+ server.mjs)                     (+ server.mjs bei manchen)
          │                                      ▲            │
          └── Store: Installieren / Aktualisieren┘            │ Browser lädt widget.js
                                                              ▼
 ┌─────────────────────── Docker-Image (Kern) ─────────────────────────┐
 │  Next.js-Oberfläche · Plugin-Store · Dashboards                      │
 │  Eingebaute APIs: Kalender, Mail, Docker, CrowdSec, FRITZ!, Wetter … │
 │  Gateway /api/plugins/{id}/…  ← server.mjs des Plugins               │
 └──────────────────────────────────┬───────────────────────────────────┘
                                    │
                     Host-Volume /app/data
           Dashboards · Anmelde-DB · Kalender · zentrales Protokoll

App-Update vs. Plugin-Update

🖥️ Dashboards & Widgets

Dashboards verwalten

Jedes Dashboard hat eine eigene URL. Zwischen Dashboards wechselst du per Tab in der Navbar oder über Einstellungen → Dashboards.

Widget-Steuerung

Im Bearbeitungsmodus (✏️-Button) mit der Maus über ein Widget fahren, dann erscheinen die Bedienelemente:

Responsives Layout (Handy, Tablet & Desktop)

Das Dashboard schaltet anhand der Raster-Breite (der Bereich mit den Widgets — nicht nur die Breite des Browserfensters) zwischen drei Modi:

Anpassen: Bearbeitungsmodus (✏️) aktivieren, beim Widget ⚙️ öffnen. Unter den Plugin-Optionen kannst du bei „Layout: Handy & Tablet“ optional Höhe / Mindesthöhe für die Handy-Ansicht sowie Tablet-Position und -Größe setzen. Felder leer lassen = für diesen Modus die Werte vom Desktop-Layout übernehmen.

Bei schmalen Bildschirmen (ca. ≤ 1024 px) rutscht die Navbar-Websuche in eine zweite Zeile in voller Breite, damit sie nicht neben Zoom und Buttons eingequetscht wird.

Plugins können optional die Prop layoutMode ('phone' | 'tablet' | 'desktop') für ihre eigene Darstellung nutzen — siehe docs/PLUGIN_DEV.md.

Einstellungen im Überblick

• Allgemein — Sprache (DE/EN), Dashboard-Titel, Navbar-Websuche, E-Mail-Badge in der Navbar, Navbar-Darstellung, Sichtbarkeit der Dashboard-Tabs, Einheitssystem (metrisch/imperial/auto)
• Benutzer — Passwort ändern, 2FA (TOTP), Kiosk / Wand-Tablet (Admin). Admins verwalten hier zusätzlich Benutzer und Plugin-Freigaben.
• Dashboards — Dashboards erstellen, bearbeiten, löschen; Tab-Sichtbarkeit pro Dashboard; Emoji oder eigenes PNG-Icon setzen
• Design — Navbar-Darstellung; Grid-Abstände; Navbar-Hintergrund (JPG/PNG + Overlay); Dashboard-Hintergrund (aus / 1 Bild / 2 Bilder nebeneinander + Overlay); Logo hochladen; Farbthema; Farben einzeln anpassen
• E-Mail — IMAP-Konten, Navbar-Badge, Abfrage-Intervall, Verbindungstest
• Protokoll — zentrales Fehlerprotokoll für Support und Fehlersuche: Filter nach Stufe, Quelle, Plugin; Download .txt / JSONL; Aufbewahrung 3 / 7 / 30 Tage. Jedes per registerPlugin eingebundene Plugin protokolliert Darstellungsfehler und fehlgeschlagene /api/*-Aufrufe automatisch. E-Mail nutzt dasselbe Protokoll mit Plugin-ID mail. Details: docs/LOGGING.md.

📺 Kiosk-Modus (Wand-Tablet)

Öffentliche Nur-Ansicht für ein Wand-Tablet oder einen Gast-Browser — getrennt vom normalen Dashboard mit Login. Ideal für Küchendisplay, Wand-Tablet oder einen gemeinsamen Bildschirm im LAN.

📱 Android-App

Die SelfDashboard Android-App zeigt das Dashboard bildschirmfüllend auf Wand-Tablets. Sie enthält keinen eigenen Backend-Code — sie zeigt nur deine SelfDashboard-Web-App an.

🔐 Login & Mehrbenutzer

SelfDashboard verlangt eine Anmeldung. Beim ersten Start (noch kein Benutzer) landest du auf /setup und legst das Admin-Konto an. Ein vorhandenes dashboard.json im Appdata-Ordner wird automatisch diesem Admin zugeordnet (Sicherung: dashboard.json.pre-auth-migrated).

🩺 Fehlerbehebung

📚 Dokumentation

🚀 Schnellstart (Docker)

docker run -d \
  --name selfdashboard \
  --restart unless-stopped \
  -p 3000:3000 \
  -e TZ=Europe/Berlin \
  -v /mnt/user/appdata/selfdashboard:/app/data \
  -v /mnt/user/appdata/selfdashboard/plugins:/app/plugins/custom \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/s3lfcod3r/selfdashboard:latest

Oder mit docker compose (siehe docker-compose.yml):

git clone https://github.com/s3lfcod3r/selfdashboard.git
cd selfdashboard
docker compose up -d

http://<host>:3000 öffnen → /setup legt das Admin-Konto an → Plugin-Store → Von GitHub die gewünschten Widgets installieren → mit + aufs Dashboard legen → Strg+F5, falls ein Widget leer bleibt.

• Pflicht: /app/data (dashboard.json, Kalender, Protokoll) und /app/plugins/custom (installierte Plugins) einbinden. Ohne Plugin-Ordner gehen Store-Installationen beim Neustart verloren.
• Optional: Docker-Socket — nur für das Docker-Plugin; CrowdSec-Mount — nur für das CrowdSec-Plugin.
• Image-Tags: die Unraid-Vorlage nutzt ghcr.io/s3lfcod3r/selfdashboard:latest. Der Plugin-Katalog kommt vom GitHub-Branch main (SELFDASHBOARD_PLUGINS_GITHUB_REF, normalerweise unverändert lassen).
• Dienste im LAN: sprechen deine Widgets LAN-Adressen an (AdGuard, Pi-hole, FRITZ!, Home Assistant …), SELFDASHBOARD_ALLOW_PRIVATE_URLS=1 setzen.

📦 Unraid

Vorlage von https://raw.githubusercontent.com/s3lfcod3r/selfdashboard/main/unraid/selfdashboard.xml hinzufügen oder unter Docker → Add Container → Template importieren.

Config Storage und Plugins Storage sind für den Normalbetrieb beide nötig. Nach einem Plugin-Update: Store → Aktualisieren → Strg+F5. Nach einem App-Update: neues Image ziehen, neu starten — Layouts und installierte Plugins bleiben auf den Volumes.

⚠️ Geheimschlüssel: festen SELFDASHBOARD_SECRET_KEY setzen und danach nie ändern — er verschlüsselt alle gespeicherten Zugangsdaten. Eine Änderung macht sie unlesbar.

⚠️ Rechte: der Container läuft ohne Root. Die Vorlage setzt PUID/PGID 99/100 (nobody:users); beim Start passt der Entrypoint auf deine PUID/PGID an und setzt den Besitzer von /app/data + /app/plugins/custom automatisch (abschaltbar mit SELFDASHBOARD_SKIP_CHOWN=1). CrowdSec-Tipp: PUID/PGID auf dieselben Werte wie dein CrowdSec-Container setzen — dann besitzt und liest SelfDashboard die crowdsec.db direkt, auch nach nächtlichen Backups, die CrowdSec neu starten (kein chmod nötig).

⚠️ LAN-Zugriff: die Vorlage setzt SELFDASHBOARD_ALLOW_PRIVATE_URLS=1 bereits (im Heimnetz empfohlen), damit Widgets Dienste im LAN erreichen.

⚠️ Selbstsigniertes HTTPS: NODE_TLS_REJECT_UNAUTHORIZED leer lassen; 0 schaltet die Zertifikatsprüfung für alle ausgehenden HTTPS-Verbindungen ab. Details: unraid/README.md.

⚙️ Konfiguration

Umgebungsvariablen, meist mit dem Präfix SELFDASHBOARD_, dazu einige Laufzeit- und Plugin-Variablen.

💾 Backups

Beide Host-Ordner regelmäßig sichern — am besten offline / unveränderbar, damit Ransomware auf dem Mount nicht Daten und Schlüssel erwischt:

• /app/data — Dashboards pro Benutzer (users/), aus Widget-Einstellungen ausgelagerte Bilder (blobs/, z. B. Bookmark-Icons), Anmelde-DB (auth/auth.db), Kalender, zentrales Protokoll und die automatisch erzeugten Schlüsseldateien (.calendar-key, .secret-salt)
• /app/plugins/custom — installierte Plugins

Bewahre außerdem deinen SELFDASHBOARD_SECRET_KEY im Passwort-Manager auf — ohne ihn lassen sich gespeicherte Zugangsdaten nicht mehr entschlüsseln.

Wiederherstellen — Container stoppen, die Sicherung zurück in die eingebundenen Ordner kopieren, wieder starten:

docker stop selfdashboard
cp -a /path/to/backup/selfdashboard/. /mnt/user/appdata/selfdashboard/
docker start selfdashboard

🛡️ Sicherheit

SelfDashboard ist für ein vertrauenswürdiges Heimnetz gebaut. Eine Sicherheitsprüfung (06/2026) hat Anmeldung und Plugin-Schnittstellen gehärtet; die folgenden Punkte zählen, sobald du die App über das LAN hinaus erreichbar machst.

Im Code gehärtet

• Login-Brute-Force: Fehlversuche werden dauerhaft pro Konto in SQLite gezählt (10 / 15 Min → vorübergehende Sperre) — übersteht Neustarts, unabhängig von der Client-IP, ein gefälschter X-Forwarded-For-Header umgeht es nicht
• Fälschbare Proxy-Header werden ignoriert, außer SELFDASHBOARD_TRUST_PROXY=1
• Admin-Aktionen verlangen abgeschlossene MFA: Benutzer-/Rollen-/Plugin-Verwaltung ist für Sitzungen ohne zweiten Faktor gesperrt
• Rate-Limits für Passwort ändern und TOTP abschalten; TOTP-Replay-Schutz (jeder Code gilt nur einmal)
• TOTP-Geheimnisse verschlüsselt gespeichert (AES-256-GCM über SELFDASHBOARD_SECRET_KEY) — eine abgeflossene auth.db allein erzeugt keine gültigen 2FA-Codes
• Zugangsdaten verschlüsselt — Kalender-, Mail- und Widget-Passwörter/-Tokens mit AES-256-GCM versiegelt; der Browser sieht nur Geheimtext
• Eigener Salt pro Installation — die Schlüsselableitung nutzt einen Zufalls-Salt, den jede Installation einmalig in /app/data/.secret-salt erzeugt (keine Umgebungsvariable); im Backup mitsichern
• Docker-Container-Aktionen (Start/Stopp/Neustart) verlangen einen Admin mit abgeschlossener MFA — die reine Liste bleibt für Widget-Nutzer sichtbar
• Entpacken von Plugin-Paketen prüft jeden Zip-Eintrag gegen Path-Traversal (Zip-Slip) und begrenzt die Anzahl der Einträge
• Plugin-SVG-Dateien werden mit Content-Disposition: attachment, X-Content-Type-Options: nosniff und strenger CSP ausgeliefert (kein gespeichertes XSS über SVGs)
• Integrität von Remote-Plugins: liefert plugins-index.json einen sha256 pro Datei, wird jede heruntergeladene Datei (inkl. ausführbarer server.mjs) vor dem Schreiben geprüft
• Interne Identitäts-Header (x-sd-user-id / x-sd-role) werden aus Client-Anfragen entfernt und nicht in Antworten zurückgegeben
• Passwort-Reset per Umgebungsvariable wird im Produktivbetrieb ignoriert, außer SELFDASHBOARD_ENABLE_ENV_RESET=1
• SSRF-Schutz bei allen ausgehenden Anfragen: Loopback / Link-Local / Cloud-Metadaten immer blockiert, private/LAN-IPs standardmäßig blockiert (Freigabe mit SELFDASHBOARD_ALLOW_PRIVATE_URLS=1); CalDAV prüft die aufgelöste IP vor dem Verbinden erneut (Schutz gegen DNS-Rebinding), wie IMAP/FRITZ!
• Container ohne Root, reproduzierbarer npm ci-Build, Container-HEALTHCHECK

Deine Aufgaben als Betreiber / bei öffentlicher Erreichbarkeit

• HTTPS nutzen und SELFDASHBOARD_SECURE_COOKIES=1 setzen — über das Internet müssen Sitzungs-Cookies Secure sein
• Interne Header am Reverse-Proxy entfernen: eingehende x-sd-user-id-, x-sd-role- und x-sd-kiosk-Header verwerfen (zusätzliche Absicherung)
• TLS-Prüfung für IMAP/FRITZ! lässt sich pro Verbindung abschalten — lass sie an, außer es gibt einen konkreten Grund
• Ein starkes Admin-Passwort und einen festen SELFDASHBOARD_SECRET_KEY nutzen
• Docker-Socket = Root-Zugriff auf den Host — nur für vertrauenswürdige Admins einbinden und nie nach außen freigeben; nur lesend schützt nicht
• :latest + Watchtower (Label in docker-compose.yml) spielt neue Images ohne menschliche Freigabe ein — für diesen mächtigen Container besser eine feste Version pinnen und das Label entfernen

Bewusste Kompromisse (dokumentiert)

• Plugin-Code läuft mit vollen Server-Rechten — hochgeladene/Remote-server.mjs-Dateien laufen ohne Sandbox im Node-Prozess. Installiere nur vertrauenswürdige Plugins und behandle das Admin-Konto wie Shell-Zugriff.
• Secure-Cookies sind standardmäßig aus, damit reine HTTP-Setups im LAN funktionieren
• Bekannte nachrangige Punkte: script-src erlaubt noch 'unsafe-inline' 'unsafe-eval'; DNS-Rebinding/TOCTOU bei allgemeinen ausgehenden Anfragen bräuchte Connection-Pinning

Verlauf der Sicherheitsupdates → CHANGELOG.md (Einträge mit 🔒).

🧱 Tech-Stack

🛠️ Entwicklung

npm ci
npm run dev                    # Next.js-Entwicklungsserver im Repo-Ordner
npm run lint                   # ESLint
npm run build                  # Produktions-Build (bindet vorher die eingebauten Plugins ein)
npm run publish:plugin-pack    # plugins-pack/ für den Store bauen
npm run generate:plugins-index # plugins-pack/plugins-index.json neu erzeugen

Tests:

npm run test

Docker-Image bauen: docs/DOCKER_BUILD.md · Plugins entwickeln: docs/PLUGIN_DEV.md.

🗺️ Roadmap

• Plugin-System nur per Volume · GitHub-Plugin-Store · ZIP-Upload · automatisch erzeugter Index
• Mehrere Dashboards · 6 Themes · Hintergrundbilder · responsives Handy/Tablet/Desktop-Layout
• Login · Mehrbenutzer · TOTP-2FA · Kiosk-Modus
• Container ohne Root · AES-256-GCM-Zugangsdaten · SSRF-Schutz (private IPs standardmäßig blockiert)
• Zentrales Fehlerprotokoll
• Vitest-Testgerüst mit ersten SSRF-Tests
• Plugin-Sandbox (Plugin-Server-Code läuft derzeit mit den Rechten der App)
• Nonce-basierte CSP statt 'unsafe-inline' 'unsafe-eval'
• Connection-Pinning gegen DNS-Rebinding bei ausgehenden Anfragen
• Beta-Plugins gegen weitere Server-Versionen testen

⬆ nach oben

⚖️ Lizenz / License

🇩🇪 Alle Rechte vorbehalten. © 2026 s3lfcod3r / SelfCoder

Du darfst die Software privat und nicht-kommerziell installieren und benutzen (z. B. im Homelab, über Docker oder Unraid).

Ohne schriftliche Erlaubnis verboten: kommerzielle Nutzung · Kopieren · Verändern · Weitergeben · Einbauen in eigene Projekte (auch Closed Source) · Verkaufen.

Details: LICENSE

🇬🇧 All rights reserved. © 2026 s3lfcod3r / SelfCoder

You may install and use the software privately and non-commercially (e.g. in your home lab, via Docker or Unraid).

Not permitted without written permission: commercial use · copying · modifying · redistributing · incorporating into other projects (including closed source) · selling.

Details: LICENSE