Nginx UI von 0xJacky: Go-Binärdatei, Vue-Oberfläche und AGPL-3.0 für die Nginx-Verwaltung

Was hinter dem Satz Yet another WebUI for Nginx steht

Die GitHub-Beschreibung von 0xJacky/nginx-ui lautet schlicht Yet another WebUI for Nginx. Das README nennt drei namentlich aufgeführte Mitwirkende, 0xJacky, Hintay und Akino, und verweist für die eigentliche Dokumentation auf nginxui.com. Eine öffentliche Demo liegt unter demo.nginxui.com, die Zugangsdaten stehen im README als admin und admin. Ob diese Instanz zurückgesetzt wird oder wie eng sie am aktuellen Code hängt, ist dort nicht angegeben.

Technisch ist der Aufbau zweigeteilt. Das Backend ist in Go geschrieben, das Frontend in Vue, und die Auslieferung erfolgt laut README als eine einzige ausführbare Datei. Das hat eine praktische Folge: Es gibt keinen separaten Applikationsserver und keine Laufzeitabhängigkeit, die auf dem Zielhost erst installiert werden müsste. Zum Zeitpunkt der Erfassung lag die letzte veröffentlichte Version bei v2.5.10 vom 21. August 2026, davor v2.5.9 und v2.5.8, beide im August 2026. Entwickelt wird im Branch dev.

Die README-Funktionsliste ist lang: Online-Statistiken zu CPU-Auslastung, Speicherauslastung, Load Average und Festplattennutzung, ein Web-Terminal, ein dunkler Modus und responsives Design. Wie die Messwerte erfasst werden und wie lange sie aufbewahrt werden, steht dort nicht.

sites-available und sites-enabled als Voraussetzung vor der Installation

Bevor Nginx UI zum ersten Mal läuft, verlangt das README eine bestimmte Verzeichnisstruktur. Angelegte Site-Konfigurationen landen im Ordner sites-available unterhalb des automatisch erkannten Nginx-Konfigurationsverzeichnisses. Für eine aktivierte Site wird ein Softlink nach sites-enabled gesetzt. Das entspricht der Debian-Konvention, und das README räumt ein, dass man die eigene Organisation der Dateien unter Umständen anpassen muss.

Auf Systemen, die nicht Debian oder Ubuntu sind, reicht das nicht. Das README zeigt dafür einen Ausschnitt für nginx.conf, der im http-Block sowohl /etc/nginx/conf.d/*.conf als auch /etc/nginx/sites-enabled einbindet. Wer nginx auf RHEL, Alpine oder BSD betreibt und die Konfiguration selbst geschrieben hat, fängt hier an.

Das ist eine echte Hürde und kein Detail. Eine Verzeichnisstruktur nachzuziehen heißt, bestehende Includes umzuschreiben und danach jeden vhost zu prüfen. Das README beziffert den Aufwand nicht und nennt keine Zahl unterstützter Layouts.

Konfigurations-Backup, Cluster-Spiegelung und verschlüsselter Export

Drei Funktionen stechen aus der Liste heraus, weil sie über das bloße Editieren hinausgehen. Nach jeder Änderung wird laut README automatisch eine Sicherung der Konfiguration angelegt, ergänzt um Versionsvergleich und Wiederherstellung. Damit lässt sich eine fehlgeschlagene Anpassung zurücknehmen, ohne ein externes Backup-System einzubinden.

Die Cluster-Verwaltung unterstützt Spiegeloperationen auf mehrere Knoten. Wie ein entfernter Knoten erreicht wird, ob dafür ein Agent installiert wird oder SSH genutzt wird, und was bei widersprüchlichen Konfigurationen passiert, bleibt im README offen. Auch eine Obergrenze für die Zahl der Knoten wird nicht genannt.

Der Export verschlüsselter Nginx- und Nginx-UI-Konfigurationen soll die Bereitstellung und Wiederherstellung auf einer neuen Umgebung beschleunigen. Das Verschlüsselungsverfahren und die Verwaltung der Schlüssel beschreibt das Quellmaterial nicht. Wer diese Funktion als Backup-Strategie einplant, sollte das vorher klären, denn ein Export, dessen Schlüssel nicht dokumentiert ist, hilft im Ernstfall nicht.

NgxConfigEditor, Ace Code Editor und der Test vor dem Reload

Zum Bearbeiten von Site-Konfigurationen bietet das README zwei Werkzeuge an. NgxConfigEditor ist ein selbst entwickelter Blockeditor, der Nginx-Konfigurationen in Blöcken darstellt statt als Rohtext. Daneben steht eine Variante des Ace Code Editor mit Nginx-Syntaxhervorhebung und dem, was das README LLM-Codevervollständigung nennt.

Der Blockeditor ist der interessantere Ansatz, weil er die Struktur der Direktiven sichtbar macht und damit eine Fehlerklasse vermeidet, die beim Tippen in einer Textdatei häufig auftritt. Der Ace-Weg ist näher an der Datei und damit näher an allen Direktiven, die ein Blockeditor vielleicht nicht abbildet. Welche Direktiven NgxConfigEditor nicht darstellen kann, sagt das README nicht.

Nach dem Speichern wird die Konfiguration laut Funktionsliste automatisch getestet und nginx anschließend neu geladen. Genau an dieser Stelle fehlt die wichtigste Angabe: Was geschieht, wenn der Test fehlschlägt, bleibt unbeschrieben. Ein Reload mit fehlerhafter Konfiguration ist bei nginx glimpflich, ein halb übernommener Zustand über mehrere Standorte hinweg ist es nicht. Auch das Anzeigen der Nginx-Protokolle in der Oberfläche ist ohne Angabe von Rotation oder Zugriffsbegrenzung dokumentiert.

ChatGPT-Assistent mit Deepseek-R1 und die MCP-Schnittstelle

Das README bewirbt einen Online-ChatGPT-Assistenten mit Unterstützung mehrerer Modelle, darunter eine für Deepseek-R1 spezifische Anzeige der Gedankenkette. Gedacht ist das als Hilfe beim Verstehen und Optimieren von Konfigurationen. Welche Modelle außerdem angebunden werden können und welcher API-Schlüssel oder Endpunkt dafür nötig ist, steht im README nicht.

Hinzu kommt eine Implementierung des Model Context Protocol. Sie stellt laut README Schnittstellen bereit, über die KI-Agenten mit Nginx UI interagieren, um Konfigurationen zu verwalten und Dienste zu steuern. Als Ermöglichung automatisierter Abläufe ist das nachvollziehbar, als Risiko ebenfalls: Ein Agent, der eine laufende Konfiguration ändern und den Dienst neu laden kann, arbeitet mit Wirkung auf den laufenden Betrieb.

Schutzmechanismen gegen eine Fehlkonfiguration durch den Agenten sind im Material nicht beschrieben. Es gibt keine dokumentierte Freigabestufe, kein Protokoll der Agentenaktionen und keine Begrenzung der erlaubten Operationen, soweit das README erkennen lässt. Wer die MCP-Schnittstelle aktiviert, sollte zuerst klären, welche Daten das Modell sieht, denn Nginx-Konfigurationen enthalten Hostnamen, Pfade und mitunter interne Adressen.

Drei Betriebswege: App-Datei, systemd und uozi/nginx-ui:latest

Für Linux nennt das README ein Installationsskript. Es verwendet standardmäßig Port 9000 für die Oberfläche und Port 9180 für die HTTP-Challenge, und es legt die Konfiguration unter /usr/local/etc/nginx-ui/app.ini ab. Die gebaute Datei lässt sich direkt mit nginx-ui -config app.ini starten, alternativ im Hintergrund über nohup. Bei Installation über das Skript steht ein systemd-Dienst bereit, gesteuert über systemctl mit start, stop oder restart für die Einheit nginx-ui.

Der Docker-Weg nutzt das Image uozi/nginx-ui:latest, das laut README auf dem aktuellen nginx-Image aufbaut. Werden die Ports 80 und 443 veröffentlicht, kann der Container den Nginx-Dienst auf dem Host ersetzen. Das README weist darauf hin, dass das nach /etc/nginx gemountete Volume beim ersten Start leer sein sollte.

Der Unterschied zwischen den Wegen ist größer als die Frage des Komforts. Die Binärdatei mit systemd verwaltet einen bestehenden Nginx; der Container bringt seinen eigenen mit und beansprucht die Standardports. Wer von einem älteren Image aktualisiert, findet auf der Dokumentationsseite eine Anleitung zur Docker-WebSocket-Korrektur mit Änderungen an nginx-ui.conf, die vor dem Ziehen eines neuen Tags gelesen werden sollte.

AGPL-3.0 und der manuelle Build mit Go 1.23 und jsoniter

Das Repository steht unter der GNU Affero General Public License Version 3. Für den praktischen Betrieb ist der Unterschied zur einfachen GPL der maßgebliche Punkt: Wer eine geänderte Fassung auf einem Netzwerkserver betreibt, muss den geänderten Quellcode den Nutzern dieses Servers zugänglich machen. Eine Weboberfläche, die über das Netz erreichbar ist und die man intern angepasst hat, fällt genau in diese Konstellation. Zu Support, Sicherheitszusagen oder Gewährleistung äußert sich die Lizenz nicht, und das README ergänzt dazu nichts.

Für Plattformen ohne offiziellen Build beschreibt das README den Weg aus dem Quellcode. Vorausgesetzt werden Make, Go 1.23 oder neuer sowie Node.js 21 oder neuer. Das Frontend wird im Verzeichnis app mit bun install und bun run build gebaut, das Backend im Projektstamm mit go generate und anschließend go build, ergänzt um den Build-Tag jsoniter.

Angaben zum Stand der kontinuierlichen Integration, zu einer automatisierten Testsuite oder zur Reproduzierbarkeit des Builds enthält das README nicht. Wer den Build in eine eigene Pipeline übernimmt, muss diese Lücke selbst schließen.

Redaktionelles Fazit

Nginx UI passt für Administratoren, die einen oder mehrere Nginx-Server über eine Weboberfläche bedienen wollen und die Debian-Struktur mit sites-available und sites-enabled bereits nutzen oder nginx.conf dafür anpassen können. Weniger geeignet ist es für Umgebungen, in denen die Netzwerk-Copyleft-Pflicht der AGPL-3.0 zum Hindernis wird, und für Teams, die eine KI-gestützte Konfigurationsänderung ohne dokumentierte Schutzmechanismen nicht zulassen dürfen. Zu prüfen sind vor dem Produktiveinsatz drei Punkte: ob der automatische Test nach dem Speichern einen fehlerhaften Reload tatsächlich verhindert, welche Daten der ChatGPT-Assistent und die MCP-Schnittstelle an externe Modelle weitergeben, und ob das nach /etc/nginx gemountete Volume beim ersten Containerstart leer ist.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes