CloudBeaver 2026 selbst hosten: Datenbanktreiber, Workspace und Zugriff

Die kürzeste CloudBeaver-Demo weist nach, dass ein Prozess auf Port 8978 lauscht. Für den Production-Betrieb sind belastbarere Nachweise erforderlich. Das folgende Szenario muss auch nach dem Austausch des Containers erfolgreich sein: die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen.

CloudBeaver wird mit einem klaren Ziel eingesetzt: als browserbasierter Datenbank-Client für Postgres, MySQL und weitere Datenbanken. Die häufigste Bereitstellungsfalle besteht darin, dass Workspace-Berechtigungen fehlschlagen oder der Container-DNS Datenbank-Hosts nicht auflösen kann. Deshalb müssen der Umgang mit der öffentlichen URL und der dauerhafte Zustand ebenso sorgfältig behandelt werden wie der Start des Images.

CloudBeaver auf einem leeren Host wiederherstellen

Liste den Zustand auf, bevor der erste echte Datensatz erstellt wird: Workspace, Benutzer, Verbindungsdefinitionen und Credentials-Speicher. Binde /opt/cloudbeaver/workspace vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um nachzuweisen, dass dieser Pfad tatsächlich persistent ist. Bestätige das Mount, indem du harmlose Daten schreibst, CloudBeaver ersetzt und die Daten anschließend wieder ausliest.

Snapshots sind für ein schnelles Rollback wertvoll. Wenn der Host oder das Volume verloren geht, ist jedoch ein unabhängiges Backup erforderlich. Stelle die Daten in einer leeren Umgebung mit dem gepinnten Image wieder her und prüfe, ob Workspace, Benutzer, Treiber und Verbindungen zurückkehren, während jede zugrunde liegende Datenbank ihrem eigenen Backup-Plan folgt. Verwende persistente Volumes und Snapshots, um diese beiden Wiederherstellungsmechanismen getrennt zu halten.

CloudBeaver mit beobachtbaren Standardwerten starten

Der folgende Befehl macht die Container-Grenze sichtbar, ohne so zu tun, als würden damit alle externen Services bereitgestellt.

docker run -d \
  --name cloudbeaver \
  --restart unless-stopped \
  -p 127.0.0.1:8978:8978 \
  -v cloudbeaver-data:/opt/cloudbeaver/workspace \
  -e CB_SERVER_NAME=CloudBeaver \
  dbeaver/cloudbeaver:latest

Bevor du den Ingress öffnest, prüfe die aufgelöste Umgebung, die Mounts und den Listener. Ergänze die geprüften Verbindungseinstellungen für private Routen sowie die Datenbanktreiber für jede Zieldatenbank und verwende für private Services private Namen. Ein erfolgreicher Start ist erst erreicht, wenn du die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen kannst – nicht, wenn docker ps lediglich Up ausgibt.

Wovon CloudBeaver abhängt

Der CloudBeaver-HTTP-Prozess lauscht auf 8978. Belasse diesen Port im Application Network und veröffentliche ausschließlich die Plattformroute. Der Netzwerkvertrag für CloudBeaver umfasst private Routen und Datenbanktreiber für jede Zieldatenbank. Halte private Endpunkte im internen DNS, erlaube nur die erforderlichen ausgehenden Verbindungen und gib CloudBeaver ein Service-Credential mit begrenztem Berechtigungsumfang.

Halte die Grenze in einem kurzen Vertrag fest: Wer besitzt die Anforderung, welches Credential wird verwendet, welches Timeout ist akzeptabel und woran ist ein Fehler erkennbar? Führe anschließend diese Transaktion aus: die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen. Beobachte währenddessen den Workspace-Zustand, Treiber-Downloads, parallele Sessions und die Netzwerklatenz zu jeder Datenbank, denn diese Auslastung liefert eine bessere Ausgangsgröße als ein unbeschäftigter Container.

Interne und externe URLs richtig zuordnen

Die öffentliche Grenze für CloudBeaver sollte aus einem kanonischen Hostnamen, automatischem TLS und genau einem internen Ziel auf 8978 bestehen. Setze die Server-URL und Proxy-Header für den öffentlichen HTTPS-Ursprung, damit Clients zu einer Adresse zurückkehren, die der Service erkennt.

Wenn die Abnahmetransaktion fehlschlägt, klassifiziere den ersten Fehler. DNS-, Zertifikats- und 502-Probleme gehören auf die TLS-Validierungs-Checkliste. Die Bedingung „Workspace-Berechtigungen schlagen fehl oder der Container-DNS kann Datenbank-Hosts nicht auflösen“ gehört auf die Seite der Anwendung – und zwar erst, nachdem eine Anfrage CloudBeaver erfolgreich erreicht hat.

Ein Production-Abnahmelauf für CloudBeaver

Mache den Traffic des ersten Benutzers nicht zum Abnahmetest für CloudBeaver. Bereite harmlose Beispieldaten vor und führe die vollständige Aktion aus: „die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen“. Notiere die exakte öffentliche URL, das Ergebnis, die Image-Referenz und das Log-Intervall, die mit diesem Lauf verbunden sind.

Ersetze den Container und wiederhole den Test, ohne die Daten neu aufzubauen. Stelle anschließend auf einem leeren Host wieder her. Die Wiederherstellungsbedingung lautet, dass Workspace, Benutzer, Treiber und Verbindungen zurückkehren, während jede zugrunde liegende Datenbank ihrem eigenen Backup-Plan folgt. Beobachte bei jedem Durchlauf den Workspace-Zustand, Treiber-Downloads, parallele Sessions und die Netzwerklatenz zu jeder Datenbank und definiere einen Alert für die Verschlechterung der Transaktion statt für Metriken eines unbeschäftigten Containers.

Eine letzte Prüfung sollte absichtlich fehlschlagen: Verweigere der Testidentität vorübergehend den Zugriff auf private Routen und Datenbanktreiber für jede Zieldatenbank. Prüfe, ob die daraus entstehende CloudBeaver-Meldung die relevante Grenze benennt, statt eine Datenlöschung oder einen endlosen Neustart auszulösen. Stelle die gültige Bedingung wieder her und bestätige, dass dieselbe Beispieltransaktion erfolgreich ist. Nimm diese kurze Übung in die Release-Checkliste auf.

Einen gesund wirkenden CloudBeaver diagnostizieren

Die erste nützliche Betriebsmetrik für CloudBeaver ist die Frage, ob die Einrichtung des Administrators abgeschlossen, der benötigte Treiber installiert, eine Verbindung über den privaten Hostnamen hergestellt und eine schreibgeschützte Abfrage ausgeführt werden kann. Ergänze diese Metrik um Sättigungssignale für Workspace-Zustand, Treiber-Downloads, parallele Sessions und die Netzwerklatenz zu jeder Datenbank. Ein reiner Prozess-Probe sollte keine teuren Abhängigkeiten aufrufen und den Container nicht neu starten, nur weil ein Upstream kurzfristig nicht verfügbar ist.

Behandle Upgrades als Datenänderungen, denn Workspace-Migrationen und Treiberkompatibilität von CloudBeaver sollten vor einer Änderung der Image-Version getestet werden. Pinne Versionen, übe den Vorgang mit wiederhergestelltem Zustand und halte das vorherige Image verfügbar, bis ein Rollback weiterhin möglich ist. Wenn Workspace-Berechtigungen fehlschlagen oder der Container-DNS Datenbank-Hosts nicht auflösen kann, sichere die Logs vor dem Neustart. Sie enthalten normalerweise die ursächliche Meldung.

CloudBeaver-spezifische Sicherheitsentscheidungen

Übernimm keine Sicherheitsannahmen aus einem lokalen Tutorial. Das spezifische Risiko bei CloudBeaver besteht darin, anonymen Zugriff auf Production-Datenbankverbindungen zu erlauben. In Production sollte die anonyme Administration daher deaktiviert, individuelle Benutzer verwendet und Datenbankkonten nur mit den Berechtigungen ausgestattet werden, die die jeweilige Verbindung benötigt.

CB_SERVER_NAME steuert das Verhalten, nicht die Vertraulichkeit. Prüfe Typ und Wert und speichere echte CloudBeaver-Credentials getrennt. Begrenze den Datei- und Netzwerkzugriff, schütze Setup-Endpunkte und definiere Upload-, Request- oder Ausführungsgrenzen für Workspace-Zustand, Treiber-Downloads, parallele Sessions und die Netzwerklatenz zu jeder Datenbank.

Auch ein Dockup-Deployment benötigt einen CloudBeaver-Abnahmetest

Das One-Click-CloudBeaver-Deployment von Dockup sollte den Austausch sicher machen: Die Route zeigt weiterhin auf 8978, Secrets sind nicht in das Image eingebaut und persistente Pfade stehen im neuen Container wieder zur Verfügung. Dasselbe Deployment kann auf Dockup Compute oder einer angebundenen Maschine ausgeführt werden.

Schließe die anwendungsspezifischen Arbeiten ab, indem du private Routen und Datenbanktreiber für jede Zieldatenbank verbindest und testest, die kanonische öffentliche Adresse anwendest und diese Abnahmeprüfung ausführst: die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen. Ergänze das Wiederherstellungsergebnis im Runbook, bevor echte Benutzer zugreifen.

Häufig gestellte Fragen

Was benötigt CloudBeaver für ein Production-Deployment?

Führe den CloudBeaver-Container auf Port 8978 über einen einzigen HTTPS-Ursprung. Die unterstützende Netzwerkanforderung besteht aus privaten Routen und Datenbanktreibern für jede Zieldatenbank. Erkläre CloudBeaver erst dann für bereit, wenn du die Einrichtung des Administrators abschließen, den benötigten Treiber installieren, über den privaten Hostnamen verbinden und eine schreibgeschützte Abfrage ausführen kannst.

Welche CloudBeaver-Daten gehören in ein Backup?

Mache /opt/cloudbeaver/workspace persistent und nimm Workspace, Benutzer, Verbindungsdefinitionen und Credentials-Speicher in dasselbe Wiederherstellungsmanifest auf. Eine saubere CloudBeaver-Wiederherstellung ist erst dann erfolgreich, wenn Workspace, Benutzer, Treiber und Verbindungen zurückkehren, während jede zugrunde liegende Datenbank ihrem eigenen Backup-Plan folgt.

Benötigt CloudBeaver hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für den öffentlichen CloudBeaver-Ursprung und belasse Port 8978 auf der internen Route. Wende die CloudBeaver-Einstellung korrekt an: Setze die Server-URL und Proxy-Header für den öffentlichen HTTPS-Ursprung. Bei CloudBeaver schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, ursprungsabhängiges Client-Verhalten.

Wie sollte ein CloudBeaver-Upgrade getestet werden?

Stelle den aktuellen CloudBeaver-Zustand in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass Workspace-Migrationen und Treiberkompatibilität von CloudBeaver vor einer Änderung der Image-Version getestet werden. Behalte das vorherige CloudBeaver-Image, bis die Grenzen der Datenmigration und des Rollbacks verstanden sind.