Generator · openDesk
openDesk-Deployment-Konfigurator
Statt die über 30 Default-Dateien von openDesk zu durchsuchen: Wähle Umgebung, Domain, Ingress, Zertifikate und Storage, und der Konfigurator schreibt die passende Datei für deine Helmfile-Umgebung — nur mit Schlüsseln, die in openDesk 1.19.1 dokumentiert sind, und nur mit den Werten, die vom Standard abweichen. Passwörter fragt er nicht ab.
Vorlage übernehmen:
Kubernetes-Namespace, in den openDesk installiert wird.
Jede App bekommt eine Subdomain darunter (portal, files, chat …). Kürzer als 94 Zeichen.
Nur nötig, wenn E-Mail-Adressen nicht auf der Basisdomain enden sollen.
Muss im Cluster existieren (kubectl get clusterissuer).
Braucht Sticky-Bit-Support — local-path-provisioner und NFS eignen sich laut Doku nicht.
Optionen
Erweiterte Optionen▾
Für ausgehende Mails über einen vorhandenen Mailserver. Passwort als Umgebungsvariable SMTP_PASSWORD.
Für Produktion empfiehlt openDesk einen externen ICAP-Dienst statt des mitgelieferten ClamAV.
Spiegel gegen das Docker-Hub-Rate-Limit.
example.org ist ein Beispielwert — ersetze ihn durch deine eigene Domain.
Generierte Datei
# helmfile/environments/dev/values.yaml.gotmpl
# Erzeugt mit dem openDesk-Deployment-Konfigurator von LabKompass, Stand openDesk 1.19.1.
# Enthält nur Abweichungen von helmfile/environments/default/ — alles andere bleibt Standard.
# Geheimnisse gehören nicht in diese Datei: MASTER_PASSWORD (und ggf. SMTP_PASSWORD) als Umgebungsvariable setzen.
---
global:
domain: "opendesk.example.org"
Das bedeuten die Parameter
-e- Eigene Werte gehören laut openDesk in dev, test oder prod — nie in default. Die Umgebung bestimmt den Ordner der Datei und den Parameter -e.
global.domain- Ohne Angabe nutzt openDesk opendesk.internal; alternativ liest es die Umgebungsvariable DOMAIN.
cluster.service.type- Betrifft Jitsi-Videobridge, MatrixRTC-SFU, Dovecot und Postfix. Standard ist LoadBalancer.
Wohin die Datei gehört
openDesk lädt eigene Einstellungen aus helmfile/environments/<umgebung>/*.yaml.gotmpl — für eine Evaluierung also aus helmfile/environments/dev/. Die Dateien unter default/ sind die Referenz aller Optionen und werden nicht verändert. Der Dateiname ist frei, solange er auf .yaml.gotmpl endet; das Getting Started nennt values.yaml.gotmpl.
Warum keine Passwörter?
openDesk leitet die meisten internen Zugangsdaten aus dem MASTER_PASSWORD ab, das du als Umgebungsvariable setzt — es gibt dafür keinen Standardwert. Einige Schlüssel, etwa der Signierschlüssel von Synapse oder das TURN-Secret, kommen aus eigenen Umgebungsvariablen oder werden beim Deployment erzeugt. Auch das Passwort für ein Mail-Relay liest openDesk aus einer Umgebungsvariable (SMTP_PASSWORD). Geheimnisse gehören deshalb weder in die Konfigurationsdatei noch in ein Git-Repository, und der Konfigurator speichert keine Eingaben.
Alle Optionen im Überblick
| Option | Bedeutung | Erklärung |
|---|---|---|
-e | Helmfile-Umgebung | Eigene Werte gehören laut openDesk in dev, test oder prod — nie in default. Die Umgebung bestimmt den Ordner der Datei und den Parameter -e. |
global.domain | Basisdomain | Ohne Angabe nutzt openDesk opendesk.internal; alternativ liest es die Umgebungsvariable DOMAIN. |
cluster.service.type | Service-Typ für Dienste außerhalb des Ingress | Betrifft Jitsi-Videobridge, MatrixRTC-SFU, Dovecot und Postfix. Standard ist LoadBalancer. |
Häufige Fragen
Wie wurde die erzeugte Konfiguration geprüft?
Automatisierte Tests stellen sicher, dass jede erzeugte Einstellung ein Schlüssel aus dem openDesk-Repository am Tag v1.19.1 ist und die Datei gültiges YAML ergibt. Zusätzlich wurden am 11.10.2026 zwei erzeugte Dateien (volle Konfiguration und selbstsigniertes Testlabor) mit Helmfile 1.8.1 und Helm 3.21.4 in das Repository eingesetzt und der Helmfile-Zustand aufgelöst (helmfile list): Beide Dateien laden fehlerfrei, und die gewählten Schalter greifen — etwa abgeschaltete Apps oder die Trust-Konfiguration. Nicht getestet sind das Rendern der einzelnen Helm-Charts und ein echtes Deployment auf einem Cluster.
Deckt der Konfigurator alle Optionen ab?
Nein, bewusst nicht. Er bildet die Entscheidungen ab, die fast jede Installation trifft. Redis, Memcached, Objektspeicher, eigene Datenbank-Passwörter, SSO-Föderation oder Theming stehen in den Default-Dateien unter helmfile/environments/default/ und in den Guides zur Konfiguration und zum Produktivbetrieb.
Was ist der Unterschied zwischen dev, test und prod?
Technisch nur der Ordner, aus dem openDesk deine Dateien lädt, und der Parameter -e beim Ausrollen. Getrennte Umgebungen helfen, Einstellungen für Test und Produktion sauber auseinanderzuhalten — die Datei aus dem Ordner default nutzt du dafür nicht.
Werden meine Eingaben gespeichert?
Nein. Die Datei entsteht in deinem Browser. In der Adresszeile landen nur unkritische Auswahlfelder wie Umgebung oder Ingress-Typ, keine Domains, Hostnamen oder Benutzernamen.
Passende Tools
openDesk Readiness Check →
Kubernetes-Cluster, Helm, Helmfile, DNS, Ingress, TLS, Storage, Secrets und Backups für openDesk prüfen — mit lesenden Prüfbefehlen und Urteil, das Selbstauskunft und geprüfte Punkte trennt.
openDesk-Infrastruktur-Planer →
Nutzer, Nodes, CPU, RAM und Speicher eingeben: Abgleich mit den offiziellen openDesk-Mindestanforderungen, Richtwerte je Anwendung, Plausibilitätsprüfung und Checkliste — Annahmen klar markiert.
openDesk-Fehlerdiagnose →
Pods hängen, Ingress liefert 502, Login oder SSO scheitert, Video bleibt schwarz? Symptom wählen und lesende kubectl- und helm-Befehle mit Deutung abarbeiten — Ursachen als Hypothesen.