Website-Verwaltung (Sites)¶

Die Website-Verwaltung ermöglicht die vollständige Konfiguration von Websites, einschließlich PHP-Einstellungen, Nginx-Direktiven, Preview-Domains, Zugriffsbeschränkungen und Deployment-Optionen.

Übersicht¶

Die Site-Tabelle zeigt alle konfigurierten Websites mit Thumbnail-Vorschau, Status und Konfigurationsdetails.

Angezeigte Spalten¶

Spalte	Beschreibung
Vorschau	Thumbnail-Bild der Website
Domain	Primäre Domain der Website
Kunde	Zugeordneter Kunde
Linux-Benutzer	System-Benutzername
PHP-Version	Aktive PHP-Version
Status	Aktiv oder Deaktiviert
Document Root	Pfad zum Web-Verzeichnis

Website erstellen¶

Klicken Sie auf Website erstellen
Füllen Sie das Formular aus:

Feld	Pflicht	Beschreibung
Abonnement	Ja	Zugehöriges Hosting-Abonnement
Domain	Ja	Domain der neuen Website
PHP-Version	Ja	PHP-Version (z. B. 8.1, 8.2, 8.3, 8.4)
Document Root	Nein	Unterverzeichnis (Standard: Domain-Root)

Klicken Sie auf Erstellen

Das System konfiguriert automatisch:

Nginx-Vhost mit Sicherheitsrichtlinien
PHP-FPM-Pool unter dem Linux-Benutzer
SSL-Zertifikat via Let's Encrypt (falls aktiviert)
open_basedir-Beschränkung
Upload-Verzeichnis-Schutz (PHP-Execution blockiert)

Website bearbeiten¶

Klicken Sie auf den Bearbeiten-Button (Stift-Icon) einer Website, um die Konfiguration zu öffnen.

Tab: Allgemein¶

Feld	Beschreibung
Domain	Primäre Domain der Website (änderbar)
PHP-Version	PHP-Version wechseln
PHP-Handler	FPM oder CGI
Document Root	Web-Verzeichnis anpassen
Status	Website aktivieren/deaktivieren
www ↔ Bare-Domain-Weiterleitung	Automatische 301-Weiterleitung zwischen `www.domain` und `domain` (aus / zu www / zu Bare-Domain). Details, inklusive der Schutzprüfung gegen eine gegenläufige Weiterleitung der Anwendung selbst: Kunden-Handbuch → Websites verwalten

Domain ändern¶

Die primäre Domain einer Website kann direkt im Bearbeitungs-Modal geändert werden.

Vorgehensweise¶

Öffnen Sie Webseiten und klicken Sie auf den Bearbeiten-Button der gewünschten Website
Ändern Sie das Domain-Feld auf die neue Domain
Klicken Sie auf Speichern

Was automatisch passiert¶

Schritt	Beschreibung
Nginx-Vhost	Alter Vhost wird entfernt, neuer mit der neuen Domain erstellt
WordPress-URLs	Falls WordPress installiert ist, werden `siteurl` und `home` automatisch per Search-Replace aktualisiert (alle Tabellen)
Panel-Datenbank	Domain in `sites`, `wordpress_installations` und `domains` Tabelle wird aktualisiert
PHP-FPM	Pool bleibt unverändert (gleicher Linux-Benutzer)
Dateien	Alle Dateien bleiben am gleichen Ort — nur die Domain-Zuordnung ändert sich

Validierung¶

Die neue Domain muss ein gültiges Format haben (z. B. example.com, shop.mein-hosting.de)
Die Domain darf nicht bereits von einer anderen Website verwendet werden
Die Änderung ist sofort wirksam — kein Neustart nötig

Nach der Domain-Änderung¶

SSL muss für die neue Domain manuell aktiviert werden (unter Domains → SSL aktivieren)
DNS muss auf den Server zeigen, bevor SSL beantragt werden kann
Bestehende Domain-Aliase und Subdomains bleiben erhalten

Hinweis

Stellen Sie sicher, dass der DNS-A-Record der neuen Domain auf die IP-Adresse des Servers zeigt, bevor Sie SSL aktivieren. Andernfalls schlägt die Zertifikatserstellung fehl.

Tab: PHP-Konfiguration¶

Hier können PHP-Einstellungen pro Website angepasst werden:

Einstellung	Beschreibung
memory_limit	Maximaler Arbeitsspeicher pro PHP-Prozess
max_execution_time	Maximale Ausführungszeit in Sekunden
request_terminate_timeout	Hartes Zeitlimit, nach dem ein hängender PHP-FPM-Worker abgebrochen wird (Sekunden). Fängt Skripte ab, die trotz max_execution_time nicht enden.
PHP-FPM Slow-Log	Protokolliert PHP-Requests, die länger als der Schwellwert laufen, mit Stacktrace — hilft, langsame Stellen im Code zu finden.
max_input_time	Maximale Eingabezeit
post_max_size	Maximale POST-Größe
upload_max_filesize	Maximale Upload-Dateigröße
max_input_vars	Maximale Anzahl Eingabevariablen
max_file_uploads	Maximale Anzahl gleichzeitiger Uploads
display_errors	Fehleranzeige (nur für Entwicklung!)
error_reporting	Fehler-Reporting-Level
session.gc_maxlifetime	Session-Lebensdauer
opcache.enable	OPcache aktivieren
open_basedir	Pfadbeschränkung
disable_functions	Deaktivierte PHP-Funktionen

disable_functions

Die Standard-Sicherheitseinstellungen deaktivieren gefährliche Funktionen wie exec, passthru, shell_exec, system, popen und proc_open. Ändern Sie diese nur, wenn Sie die Sicherheitsauswirkungen verstehen.

Tab: Nginx-Direktiven¶

Eigene Nginx-Konfigurationsanweisungen können im Textfeld hinzugefügt werden. Diese werden in den server-Block der Vhost-Konfiguration eingefügt.

Beispiele:

# Zusätzliche Header
add_header X-Frame-Options "SAMEORIGIN";

# Umleitungsregel
location /old-page {
    return 301 /new-page;
}

Syntax-Prüfung

Das System validiert die Nginx-Konfiguration vor dem Speichern. Bei Syntaxfehlern wird die Änderung abgelehnt.

Vorschau-Adresse¶

Eine Website kann unter einer zweiten Adresse erreichbar gemacht werden, während ihre eigentliche Domain noch auf einen anderen Server zeigt — der Standardfall bei Migrationen, bei denen der Kunde die neue Seite fertig bauen will, bevor er die Domain umstellt.

Zwei Quellen für die Adresse:

Quelle	Voraussetzung
Vom Kunden angegebener Name, z. B. `aufbau.kunden-domain.de`	Ein einzelner A-Record in der Zone des Kunden, der auf diesen Server zeigt. Kein Wildcard nötig, funktioniert auch bei extern verwalteten Zonen
Automatisch erzeugt: `preview-<hash>.<panel-domain>`	DNS-Wildcard-Eintrag `*.<panel-domain>` (A/AAAA) auf diesen Server

Der Wildcard ist damit optional. Er wird nur noch für die automatisch erzeugten Namen gebraucht — und für Staging-Klone, die weiterhin ausschließlich einen erzeugten Namen verwenden. Der Hinweis dazu steht unter Einstellungen → Panel → Panel-URL.

SSL: Für jede Vorschau-Adresse holt das Panel ein eigenes Let's-Encrypt-Zertifikat per HTTP-01 — einzelne Hostnamen brauchen keinen DNS-Zugriff. Der Versuch läuft beim Einschalten und danach einmal täglich erneut, weil die übliche Reihenfolge „erst einschalten, Adresse ablesen, dann Record anlegen" ist. Vorher läuft die Vorschau über http://; sobald das Zertifikat steht, wird auch die in WordPress gespeicherte Adresse von http auf https gezogen. Die Erneuerung übernimmt der certbot-Timer, nicht der SSL-Worker des Panels.

DNS-Prüfung: Der Dialog zum Einschalten prüft den eingegebenen Namen gegen DNS und meldet vier Zustände — zeigt hierher, zeigt auf einen anderen Server, kein A-Record, nicht prüfbar. Der letzte Zustand ist Absicht: bleibt die DNS-Abfrage unbeantwortet oder kennt das Panel keine öffentliche Server-IP, wird keine Aussage getroffen, statt einen fehlenden Record zu behaupten. Bei den beiden mittleren Zuständen zeigt der Dialog den fertigen Record zum Kopieren.

WordPress: Beim Einschalten werden siteurl und home der WordPress-Installationen der Website (inklusive serialisierter Verweise in den Inhalten) auf die Vorschau-Adresse umgestellt, beim Abschalten zurück auf die Domain. Ohne das würde WordPress jeden Aufruf auf die noch nicht erreichbare Domain umleiten. Staging-Installationen sind ausgenommen.

Berechtigung: perm_preview_url im Paket. Der Schalter im WordPress-Toolkit sitzt in der Kachel der Installation.

Staging (Test-Kopie)¶

Staging klont Dateien und Datenbanken einer Website in eine getrennte Umgebung mit eigenem Vhost. Die Live-Seite und ihre Datenbank werden dabei nicht angefasst; Push-to-Live überträgt die Kopie später zurück (der Agent sichert vorher die Produktion).


Berechtigung	`perm_staging` im Paket
Verzeichnis	`/var/www/customers/<user>/.staging_<site-id>`
Vhost	`/etc/nginx/sites-enabled/<user>-staging-<adresse-mit-bindestrichen>.conf`
Adresse	vom Kunden angegeben, sonst erzeugt (`preview-<hash>.<panel-domain>`, braucht Wildcard)
Datenbanken	je Produktions-DB eine Kopie, Zuordnung in `sites.staging_dbs` (JSON)

HTTPS: Der Staging-Vhost läuft über http://, solange für seine Adresse kein echtes Zertifikat vorliegt, und bekommt den HTTPS-Teil erst, wenn eines da ist. Vorher war das anders und jede Staging-Umgebung begrüßte den Kunden mit einer Zertifikatswarnung — der HTTP-Teil leitete bedingungslos auf HTTPS um, während der HTTPS-Teil auf das Platzhalter-Zertifikat zurückfiel (behoben in 2.9.96). Das Zertifikat holt das Panel per HTTP-01 und rendert den Vhost danach neu; der tägliche SSL-Lauf wiederholt beides, falls der DNS-Record erst später kommt.

PHP-Version: Der Staging-Vhost verwendet die Version, die auf dem Server tatsächlich installiert ist, nicht die in der Datenbank hinterlegte. Steht an der Website z. B. 8.3, der Server hat aber nur 8.4, zeigte der fastcgi_pass früher auf einen Socket, den es nie gab — Staging antwortete mit 502 (behoben in 2.9.96).

Nach einem Reload kurz warten

nginx -s reload kehrt sofort zurück, der Reload selbst läuft asynchron. Eine Prüfung unmittelbar nach dem Anlegen trifft noch den Default-Vhost und sieht wie ein Fehler aus. Am Antwort-Header X-Robots-Tag: noindex erkennt man, ob wirklich der Staging-Vhost geantwortet hat.

Aufräumen: Löschen entfernt Verzeichnis, Vhost und Staging-Datenbanken. Zum Prüfen, ob etwas zurückblieb: die Zahl der *-staging-*.conf unter /etc/nginx/sites-enabled/ muss zu SELECT count(*) FROM sites WHERE staging_active=true passen.

Tab: Zugriffsbeschränkungen¶

IP-Beschränkung: Zugriff nur von bestimmten IP-Adressen erlauben
Passwortschutz: Verzeichnisse per HTTP-Authentifizierung schützen

Tab: Logs¶

Zugriff auf die letzten Einträge der Website-Logs:

Access-Log — Zugriffsprotokolle
Error-Log — Fehlerprotokolle

Die Logs können direkt im Browser eingesehen oder heruntergeladen werden.

Website aktivieren / deaktivieren¶

Klicken Sie auf den Status-Schalter in der Detailansicht
Deaktivierte Websites zeigen eine Standard-Fehlerseite
Die Nginx-Konfiguration wird automatisch aktualisiert

Website löschen¶

Klicken Sie auf das Löschen-Symbol
Bestätigen Sie die Löschung

Dateien beachten

Beim Löschen einer Website werden die Nginx-Konfiguration und der PHP-FPM-Pool entfernt. Die Website-Dateien im Home-Verzeichnis bleiben optional erhalten.

Composer-Verwaltung¶

Für Websites mit PHP-Projekten steht Composer direkt im Panel zur Verfügung:

Öffnen Sie die Website-Details
Navigieren Sie zum Tab Composer
Verfügbare Aktionen:
composer install — Abhängigkeiten installieren
composer update — Abhängigkeiten aktualisieren
Die Ausgabe wird in Echtzeit angezeigt

Node.js- und Python-Apps¶

Neben PHP kann eine Website als Node.js- oder Python-App betrieben werden. Die App läuft als eigener systemd-Dienst auf einem internen Port; nginx leitet die Anfragen dorthin weiter (Reverse-Proxy). Die Nutzung wird pro Paket über die Berechtigung Node.js/Python freigeschaltet.

Anlegen¶

Beim Erstellen der Website unter App-Typ Node.js oder Python wählen. Dann erscheinen:

Start-Befehl — der Befehl, der die App startet (z. B. npm start oder gunicorn app:app). Der zugewiesene Port steht als $PORT bereit.
Port — interner Port; leer lassen für automatische Vergabe.
Umgebungsvariablen — eine KEY=VALUE pro Zeile.

Verwalten (App-Runtime)¶

Über die Aktion App verwalten an der Website öffnet sich das App-Runtime-Fenster:

Status (aktiv / gestoppt / fehlgeschlagen) mit Starten / Stoppen / Neustart
Start-Befehl, Port und Umgebungsvariablen bearbeiten — Speichern konfiguriert neu und startet die App
Abhängigkeiten installieren — npm install (Node.js) bzw. pip install -r requirements.txt in einem venv (Python), ausgeführt als Website-Benutzer
Logs — die letzten Ausgaben des App-Dienstes (journald)
Runtime-Version — die Node-/Python-Version pro App wählbar (Standard = System-Version)

Runtime-Versionen¶

Beim Anlegen und im App-Runtime-Fenster lässt sich pro App eine Runtime-Version wählen. Als Admin können Sie direkt weitere Versionen bereitstellen:

Node.js — Eingabe der Major-Version (z. B. 20); enconf lädt das offizielle Binary herunter und legt es unter /opt/enconf/runtimes/node/<major>/ ab.
Python — Eingabe der Minor-Version (z. B. 3.12); enconf installiert das Distributionspaket python3.<minor>-venv.

Danach steht die Version in der Auswahl bereit. Node-Apps nutzen dann das gewählte node/npm; Python-Apps bauen ihr venv mit dem gewählten Interpreter.

Git-Deployment¶

Für automatisiertes Deployment via Git:

Öffnen Sie die Website-Details
Navigieren Sie zum Tab Git
Konfigurieren Sie:
Repository-URL — HTTPS oder SSH
Branch — Zu deployender Branch (z. B. main)
Auto-Deploy — Automatisches Deployment bei Push (Webhook)
Deploy-Key — SSH-Schlüssel für private Repositories
Klicken Sie auf Jetzt deployen für manuelles Deployment

Deploy-Hooks

Nach dem Git-Pull können automatisch Befehle ausgeführt werden (z. B. composer install, npm run build).

Fehlerseiten (Error Documents)¶

Eigene Fehlerseiten können für die Standard-HTTP-Fehlercodes konfiguriert werden:

403 — Zugriff verweigert
404 — Seite nicht gefunden
500 — Interner Serverfehler
502 — Bad Gateway
503 — Dienst nicht verfügbar