Beszel 2026 selbst hosten: Agents, private Netzwerke und Backups

Die kürzeste Beszel-Demo belegt lediglich, dass ein Prozess auf Port 8090 lauscht. Für den produktiven Betrieb braucht es belastbarere Nachweise. Dieses Szenario muss auch nach dem Austausch des Containers funktionieren: Einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden.

Beszel wird für einen klaren Zweck eingesetzt: leichtgewichtiges Server-Monitoring in einem kleinen Container. Die häufigste Falle bei der Bereitstellung besteht darin, dass der Hub Port 45876 auf einem Agent nicht erreichen kann oder sich dessen SSH-Key geändert hat. Deshalb verdienen der Umgang mit der öffentlichen URL und der dauerhafte Zustand ebenso viel Aufmerksamkeit wie der Start des Images.

Die Laufzeitgrenze von Beszel festlegen

Prozessgesundheit und Produktgesundheit sind bei Beszel zwei verschiedene Dinge. Port 8090 kann antworten, während die Transaktion aus Sicht des Benutzers weiterhin fehlschlägt. Der Netzwerkvertrag für Beszel sieht auf jeder überwachten Maschine einen Beszel-Agent vor. Halte private Endpoints im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und gib Beszel ein Service-Credential mit eingeschränkten Berechtigungen.

Führe diese Readiness-Prüfung nach wesentlichen Konfigurationsänderungen durch: Einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden. Halte aufwendige externe Checks aus Liveness-Probes heraus, damit ein Ausfall eines Providers keine Restart-Schleife auslöst. Bei der Kapazitätsplanung sollten die Anzahl der Agents, die Aufbewahrungsdauer der Metriken, der Hub-Speicher und die Netzwerkerreichbarkeit jedes Agents über seinen dedizierten Port erfasst werden. Das bildet die tatsächliche Belastung von Beszel besser ab als Seitenaufrufe.

Die öffentliche Origin eindeutig festlegen

Browser, API-Client und Beszel müssen sich auf eine gemeinsame Origin einigen. Damit das gewährleistet ist, route den Hub über HTTPS und halte die Agent-Ports privat. Bewahre Host und Protokoll der ursprünglichen Anfrage, während Port 8090 nicht als konkurrierende öffentliche Adresse verfügbar ist.

Die Anleitung zur Fehlersuche bei nicht erreichbaren Websites hilft dabei, eine nicht erreichbare Route von einer antwortenden Anwendung zu unterscheiden. Diese Unterscheidung ist hier entscheidend: Der Hub kann Port 45876 auf einem Agent nicht erreichen oder dessen SSH-Key hat sich geändert. Nur das erste Problem lässt sich durch Änderungen am Ingress beheben; für das zweite müssen Beszel-Logs, der Zustand oder der Workload untersucht werden.

Die erste produktionsnahe Instanz betreiben

Der erste Container sollte sich einfach löschen und neu erstellen lassen. Halte Daten außerhalb der beschreibbaren Container-Schicht, binde Port 8090 nur dort, wo der Proxy ihn erreichen kann, und übergib die Konfiguration zur Laufzeit.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Fixiere das Image nach dem ersten Test auf eine konkrete Version. Lies den frühesten Startfehler statt der abschließenden Restart-Meldung, überprüfe jeden Mount mit docker inspect und verfolge die Logs, während du einen Agent registrierst, CPU-, Speicher- und Festplatten-Charts anzeigst, einen Schwellwert-Alarm auslöst und den Agent nach einem Neustart des Hubs wieder verbindest. Diese Abfolge unterscheidet einen fehlerhaften Image-Befehl von einem Problem mit einer Abhängigkeit oder Berechtigung.

Logs, die die nächste Frage beantworten

Ein grüner Container ist notwendig, aber nicht ausreichend. Die Service-Level-Indikator ist der erfolgreiche Abschluss von „einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden“. Wahrscheinliche Belastungssignale sind die Anzahl der Agents, die Aufbewahrungsdauer der Metriken, der Hub-Speicher und die Netzwerkerreichbarkeit jedes Agents über seinen dedizierten Port.

Change Control ist wichtig, weil Hub- und Agent-Versionen gemeinsam getestet werden sollten: Protokolländerungen können wie unbemerkte Monitoring-Lücken aussehen. Bewahre das alte Image auf, teste Migrationen mit kopiertem Zustand und dokumentiere, ob ein Rollback nach einer Änderung des Schemas unterstützt wird. Wenn der Hub Port 45876 auf einem Agent nicht erreichen kann oder dessen SSH-Key geändert wurde, diagnostiziere die erste Grenze, die sich von der funktionierenden Umgebung unterscheidet.

Ein produktiver Abnahmelauf für Beszel

Erstelle vor dem ersten Einsatz durch echte Benutzer ein Release-Arbeitsblatt für Beszel. Es muss das fixierte Image, Port 8090, die kanonische Origin, persistente Pfade und die verantwortliche Person für einen Beszel-Agent auf jeder überwachten Maschine nennen. Hänge das erwartete Ergebnis dieser Transaktion an: Einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden.

Verwende das Arbeitsblatt nach einem normalen Austausch und nach einer sauberen Wiederherstellung. Die Wiederherstellung gilt nur dann als erfolgreich, wenn Systeme, Historie und Alarme zurückkehren und jeder wiederhergestellte Agent erneut aktuelle Metriken sendet. Erfasse außerdem einen kurzen Ressourcenverlauf für die Anzahl der Agents, die Aufbewahrungsdauer der Metriken, den Hub-Speicher und die Netzwerkerreichbarkeit jedes Agents über seinen dedizierten Port. Bewahre ihn neben dem Release auf, damit künftige Kapazitätsänderungen mit demselben Workload verglichen werden können.

Füge einen kontrollierten Fehlerfall hinzu: Verweigere der Test-Identität vorübergehend den Zugriff auf einen Beszel-Agent auf jeder überwachten Maschine. Bestätige, dass Beszel das Problem an der richtigen Grenze meldet, stelle den gültigen Zustand wieder her und führe die Transaktion erneut aus. Damit wird die Sichtbarkeit von Fehlern geprüft, nicht nur der Erfolg. So verhinderst du, dass eine gesund aussehende Oberfläche einen defekten Worker, Callback oder eine fehlerhafte Datenbankverbindung verbirgt.

Die Wiederherstellung von Beszel vor dem Start planen

Erfasse jedes dauerhafte Artefakt: Hub-Daten, Benutzer, Systeme und Alarmkonfiguration. Binde /beszel_data vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Beziehe auch Konfigurationen ein, die die Interpretation gespeicherter Daten verändern, nicht nur das größte Verzeichnis.

Lege die Aufbewahrungsdauer fest, kopiere Backups vom Host weg und führe eine Wiederherstellung in einer sauberen Umgebung durch. Der Beszel-Drill ist abgeschlossen, wenn Systeme, Historie und Alarme zurückkehren und jeder wiederhergestellte Agent erneut aktuelle Metriken sendet. Wenn Snapshots Teil des Plans sind, dokumentiere mithilfe der Anleitung zu PITR im Vergleich zu Snapshots, welche Daten mit welchem Mechanismus wiederhergestellt werden können.

Temporären Setup-Zugriff schließen

Analysiere die Aktion, die Beszel ausführt, und nicht nur dessen Login-Formular. Der risikoreichste Fehler besteht hier darin, Agent-Listener ohne Netzwerk-Kontrollen im Internet zu veröffentlichen. Setze folgende Grenze um: Halte Agent-Listener in privaten Netzwerken und schütze das Hub-Konto sowie die Enrollment-Keys.

Beszel benötigt in dieser Ausgangskonfiguration kein verpflichtendes Bootstrap-Secret. Schütze stattdessen das tatsächliche Administrator-Konto oder die vorgelagerte Authentifizierung. Behebe einen Berechtigungsfehler nicht, indem du den Container als Root ausführst oder den Host weitreichend mountest. Auch Ressourcenlimits gehören zum Security-Design, wenn Benutzer die Anzahl der Agents, die Aufbewahrungsdauer der Metriken, den Hub-Speicher und die Netzwerkerreichbarkeit jedes Agents über seinen dedizierten Port beeinflussen können.

Wiederholbare Infrastrukturarbeiten zu Dockup verlagern

Für Beszel ist Dockup besonders an der Grenze zwischen einem Image und einem dauerhaften Service nützlich. Es hält die Route zu 8090, TLS, Secret-Werte und Storage über Container-Austausche hinweg zusammen, unabhängig davon, ob die Compute-Ressourcen zu Dockup oder zu deinem angebundenen Server gehören.

Schließe mit dem anwendungsspezifischen Teil ab: Route den Hub über HTTPS und halte die Agent-Ports privat; verbinde und teste einen Beszel-Agent auf jeder überwachten Maschine; und führe diese Prüfung aus: Einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden. Bewahre das Ergebnis als Deployment-Check auf, damit das nächste Image-Update anhand des Verhaltens und nicht anhand des Container-Status bewertet wird.

Häufig gestellte Fragen

Was benötigt Beszel für einen produktiven Betrieb?

Route den Beszel-Container auf Port 8090 über eine einzige HTTPS-Origin. Die zugehörige Netzwerkanforderung ist ein Beszel-Agent auf jeder überwachten Maschine. Betrachte Beszel erst dann als bereit, wenn du einen Agent registrieren, CPU-, Speicher- und Festplatten-Charts anzeigen, einen Schwellwert-Alarm auslösen und den Agent nach einem Neustart des Hubs wieder verbinden kannst.

Welche Beszel-Daten gehören in ein Backup?

Sichere /beszel_data persistent und nimm Hub-Daten, Benutzer, Systeme und Alarmkonfiguration in dasselbe Recovery-Manifest auf. Eine saubere Beszel-Wiederherstellung ist nur dann erfolgreich, wenn Systeme, Historie und Alarme zurückkehren und jeder wiederhergestellte Agent erneut aktuelle Metriken sendet.

Benötigt Beszel HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für die öffentliche Beszel-Origin und halte Port 8090 auf der internen Route. Wende die Beszel-Einstellung korrekt an: Route den Hub über HTTPS und halte die Agent-Ports privat. Bei Beszel schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.

Wie sollte ein Beszel-Upgrade getestet werden?

Stelle den aktuellen Beszel-Zustand in einer isolierten Umgebung wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass Hub- und Agent-Versionen gemeinsam getestet werden sollten, weil Protokolländerungen wie unbemerkte Monitoring-Lücken aussehen können. Behalte das vorherige Beszel-Image, bis die Grenzen der Datenmigration und des Rollbacks geklärt sind.