Beiträge zum Tag #docker

Wer mit Home Assistant startet, scheitert oft schon an der ersten Frage: HA OS, Supervised, Container oder Core? Die Doku wirft vier Varianten in den Raum, ohne klar zu sagen, welche für wen taugt – und die falsche Wahl kostet später Nerven (fehlende Add-ons, Update-Chaos, kein Supervisor). Dieser Artikel vergleicht die vier Varianten ehrlich, gibt dir einen klaren Entscheidungsbaum und zeigt den Schnellstart für die zwei sinnvollsten Wege – HA OS auf einem Raspberry Pi und HA als Docker-Container. Basierend auf meinem eigenen Setup, in dem Home Assistant als HA OS in einer KVM-VM läuft. Du brauchst keine Vorkenntnisse, am Ende weißt du genau, welche Variante du installierst und warum.

Ein Homelab wächst meist chaotisch: hier ein Docker-Container, dort eine VM, dazwischen ein Reverse Proxy, den irgendwann keiner mehr versteht. Dieser Guide bündelt meine Artikel zu einem roten Faden – von der Virtualisierung über Container und Reverse Proxy bis zu Storage, Backups und automatisiertem Deployment. Alles aus echtem Setup auf einem Debian-Server, mit den Entscheidungen und Trade-offs, die ich wirklich getroffen habe (und denen, die ich verworfen habe). Du brauchst Linux-Grundlagen, aber keine Enterprise-Erfahrung. Am Ende hast du einen Plan, in welcher Reihenfolge du dein Homelab aufbaust – und weißt, welcher Artikel dich bei jedem Schritt im Detail abholt.

Ein Self-Hosted-Setup steht und fällt mit dem Backup – genauer: mit dem, das sich auch zurückspielen lässt. Wer seine App auf einem Postgres im Docker-Container betreibt, hat schnell einen pg_dump-Cronjob gebaut und fühlt sich sicher. Bis der erste echte Restore ansteht. Dieser Artikel zeigt mein Postgres-Backup-Setup aus dem laufenden Homelab: vom simplen logischen Dump über inkrementelles WAL-Archiving bis zu Point-in-Time-Recovery, verschlüsselt und off-site. Du brauchst Docker- und Basis-Linux-Kenntnisse – am Ende hast du ein Backup, dem du vertraust, weil du den Restore automatisiert testest.

Eigene MCP-Server entwickeln klingt komplex – ist es aber nicht. Mit FastMCP und Python schreibst du Tools in Minuten, die Claude direkt aufrufen kann. Dieser Artikel zeigt den Weg vom leeren Repo bis zum produktiven Remote-Server: stdio für Claude Code lokal, HTTP/SSE mit Auth für Homelab und Production. Basis ist der devmaker-MCP-Server, der diese Website steuert – praxiserprobt, kein Beispiel-Setup.

Watchtower verspricht automatische Docker-Updates ohne Aufwand – bis man merkt, dass GitLab nach einem Sprung über mehrere Hauptversionen seine Datenbank nicht mehr migriern kann und man keinen Überblick hat, was wann im Hintergrund geändert wurde. Dieser Artikel erklärt ehrlich, warum das originale Watchtower-Image kaum noch gepflegt wird, welche Probleme automatische Updates verursachen können und wie ein pragmatischer Update-Workflow mit Diun für Benachrichtigungen und gezieltem Watchtower-Einsatz im Opt-In-Modus aussieht.

Wagtail bringt keine Frontend-Meinung mit – und irgendwann schreibt man zum dritten Mal dieselbe Card-Komponente in Custom-CSS. Tailwind v4 mit daisyUI als Komponenten-Layer war mein Kompromiss: kein Bootstrap-Override-Wahnsinn, keine eigene CSS-Bibliothek von Null, kein Eingriff in den Django-Static-Workflow. Dieser Artikel zeigt das konkrete Setup für devmaker.net – mit npm-Watch im Dev, einem Multi-Stage-Dockerbuild in Production und den echten Stolperfallen, die ich dabei gemacht habe.

Docker läuft seit Jahren auf meinem Debian-Server – und LXC war bisher nur ein Begriff aus Proxmox-Tutorials. Nach einer ehrlichen Auseinandersetzung mit dem Thema ist klar: Docker und LXC sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Probleme. Dieser Artikel erklärt das mentale Modell hinter beiden Ansätzen, zeigt wie man Incus direkt auf Debian einrichtet und welche Services bei mir von Docker nach LXC wandern werden. Ohne Proxmox, ohne Canonical-Abhängigkeiten.

Nginx Proxy Manager läuft seit zwei Jahren bei mir als zentraler Reverse Proxy für knapp 30 interne Services. Dann kamen drei konkrete Pain Points: manuelle GUI-Klicks für jeden neuen Container, Config-Drift in einer SQLite-Datenbank und fehlende Middleware-Optionen. Drei Wochen Traefik v3-Test auf einer zweiten Maschine später ist das Ergebnis überraschend: kein klarer Sieger, sondern ein hybrider Ansatz. Dieser Artikel erklärt, warum beide Tools für unterschiedliche Szenarien die bessere Wahl sind.

ESPHome-Configs steuern Heizung, Sensoren und Lüftung – zu wichtig, um sie ohne Pipeline ins Produktivsystem zu pushen. Dieser Artikel zeigt ein pragmatisches GitLab-CI-Setup, das jede Config-Änderung validiert, Firmware für alle Geräte parallel baut und OTA-Updates nur auf main ausrollt. Inklusive Secrets-Management über GitLab-Variablen, Matrix-Builds für beliebig viele Devices und einem Breaking-Change-Detektor, der vor ESPHome-Major-Updates warnt. Kein Overkill, aber genug Sicherheit für ein produktives Smarthome.