Zum Inhalt springen 
Ich zeige dir in zwei Sätzen, wie du plesk ubuntu sauber installierst und für Hosting einsatzbereit machst. Mit dieser Anleitung richtest du Plesk sicher ein, vermeidest typische Fehler und setzt schnell Websites, E‑Mail und Datenbanken auf.
Zentrale Punkte
- Voraussetzungen: Unterstützte Ubuntu-Versionen, RAM, CPU, Speicherplatz prüfen.
- Installation: System aktualisieren, Firewall-Ports öffnen, Installer starten.
- Sicherheit: SSL, Updates, Fail2Ban und Firewall direkt nach der Einrichtung aktivieren.
- Konfiguration: Admin-Zugang, Lizenz, Domains, E‑Mail und Datenbanken anlegen.
- Performance: PHP-Version wählen, HTTP/2 aktivieren, Caching und Monitoring nutzen.
Was ist Plesk? Kurz erklärt
Plesk ist ein Control‑Panel für Server, mit dem ich Websites, Datenbanken, E‑Mail und Sicherheitsfunktionen zentral verwalte. Ich arbeite per Browser und erledige Routineaufgaben ohne lange Konsoleingaben. Für Einsteiger bringt die Oberfläche klare Menüs, Profis schätzen Automatisierung und Erweiterungen. Ich installiere Module wie WordPress Toolkit, Backup oder Monitoring mit wenigen Klicks. Auf Ubuntu läuft Plesk zuverlässig und erhält regelmäßig Updates.
Systemvoraussetzungen und Kompatibilität
Bevor ich Plesk installiere, prüfe ich die Hardware und die unterstützte Ubuntu-Version. Für produktive Setups setze ich auf 2 GB RAM oder mehr und mindestens 40–50 GB Speicherplatz. Eine saubere Netzwerkverbindung spart mir Ärger während des Downloads der Pakete. Ich halte die Maschine so schlank wie möglich und verzichte auf andere Panels. Die folgende Tabelle zeigt die wichtigsten Werte auf einen Blick.
| Komponente | Minimum | Empfehlung | Hinweis |
|---|---|---|---|
| Ubuntu | 18.04/20.04/22.04 LTS (64‑bit) | 20.04 oder 22.04 LTS | LTS‑Versionen bekommen lange Updates |
| CPU | 1 GHz, 64‑bit | 2+ vCPU | Mehr Kerne beschleunigen Builds |
| RAM | 1 GB + 1 GB Swap | 2–4 GB RAM | Mehr RAM für WordPress‑Hosting |
| Speicher | 20 GB | 40–80 GB | Genug Platz für Backups |
| Netz | Ausgehend HTTP/HTTPS offen | Niedrige Latenz | Wichtig für Updates und Installer |
Server vorbereiten: sauberes Ubuntu
Ich starte auf einem frischen Server ohne andere Panels wie cPanel oder Webmin. Das vermeidet Paketkonflikte und spart mir spätere Fehlersuche. Einen Hostnamen setze ich korrekt, ideal als FQDN wie panel.deinedomain.tld. Die Paketquellen halte ich minimal und aktiv lasse ich nur die Standard-Repositories. Für professionelle Projekte achte ich auf SSD-Speicher und ausreichend I/O‑Leistung.
Schritt 1: System aktualisieren
Ich aktualisiere zuerst das System, damit Bibliotheken und Kernel aktuell sind. So schließe ich Sicherheitslücken und minimiere Inkompatibilitäten. Das Update läuft zügig durch und erfordert nur bei Kernel-Änderungen einen Neustart. Nach dem Reboot prüfe ich die Erreichbarkeit per SSH. Die folgenden Befehle nutze ich auf Ubuntu vor jeder Installation:
sudo apt update && sudo apt upgrade -y
[ -e /var/run/reboot-required ] && sudo reboot
Schritt 2: Firewall öffnen
Ich erlaube die wichtigsten Ports in UFW, damit Web und Panel erreichbar sind. Neben 80/443 für Websites braucht Plesk eigene Verwaltungsports. Nach dem Freischalten teste ich die Erreichbarkeit später über den Browser. Eine klare Übersicht hilft bei Prüfungen und Audits. Die Tabelle zeigt die üblichen Regeln:
| Port | Protokoll | Zweck | Kommentar |
|---|---|---|---|
| 80 | TCP | HTTP | Webzugriff ohne SSL |
| 443 | TCP | HTTPS | Webzugriff mit TLS |
| 8443 | TCP | Plesk Panel | Login ins Dashboard |
| 8880 | TCP | Plesk HTTP | Unverschlüsselter Zugang (selten) |
| 8447 | TCP | Installer | Updates und Add‑ons |
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 8443/tcp
sudo ufw allow 8880/tcp
sudo ufw allow 8447/tcp
sudo ufw enable
sudo ufw reload
Schritt 3: Werkzeuge und Installer
Für den Download nutze ich wget oder curl, je nach Vorliebe. Fehlt wget, installiere ich es mit einem kurzen Befehl. Anschließend lade ich den Installer von Plesk herunter und mache ihn ausführbar. Ich halte die Konsole offen, damit ich Rückmeldungen sofort sehe. So bleibt der Ablauf nachvollziehbar:
sudo apt install -y wget
wget https://autoinstall.plesk.com/plesk-installer
sudo chmod 755 plesk-installer
Schritt 4: Plesk Installation starten
Ich starte die Installation wahlweise in der Konsole oder per Web-Interface. Für eine geführte Einrichtung nutze ich gerne die Webvariante, die mir direkt eine URL ausgibt. Im Browser wähle ich die empfohlene Komponentenauswahl, setze die Sprache und bestätige die Lizenzbedingungen. Alternativ arbeite ich mit dem One‑Click‑Installer und lasse Standardmodule automatisch setzen. Die folgenden Befehle stehen zur Wahl:
sudo ./plesk-installer --web-interface
# oder One‑Click
sh <(curl https://autoinstall.plesk.com/one-click-installer || wget -O - https://autoinstall.plesk.com/one-click-installer)
Schritt 5: Ersteinrichtung im Browser
Nach der Installation rufe ich https://SERVER-IP:8443 auf und melde mich mit Root oder dem Admin-Konto an. Ich setze einen klaren Administratornamen, die Benachrichtigungs-E‑Mail und ein starkes Passwort. Fehlt mir eine Lizenz, aktiviere ich schnell die Testversion und entscheide später. Ich prüfe außerdem Zeitzone, Sprache und Hostname in den Werkzeugeinstellungen. So startet das Panel sofort mit sinnvollen Defaults.
Sicherheit sofort einrichten
Direkt nach dem Login aktiviere ich SSL per Let’s Encrypt für das Panel und meine Domains. Ich aktualisiere Komponenten über den Plesk‑Updater, damit Sicherheitsfixes sofort aktiv sind. Fail2Ban und die Plesk‑Firewall reduzieren Angriffsflächen deutlich. Zusätzlich setze ich starke Passwortregeln und deaktiviere ungenutzte Services. Mit diesen Schritten senke ich das Risiko bereits am ersten Tag.
Websites, E‑Mail, Datenbanken verwalten
Ich lege zuerst die Domain an und ordne sie einem Webspace zu. Danach richte ich ein SSL‑Zertifikat, eine PHP-Version und die Datenbank für die Anwendung ein. Für WordPress nutze ich das Toolkit, das Updates, Security‑Checks und Staging bietet. E‑Mail‑Konten setze ich mit Quotas und Spam‑Schutz auf. Für einen strukturierten Start hilft mir dieser erste Schritte Leitfaden mit praxistauglicher Reihenfolge, inklusive Checkliste.
PHP 8.2 für Performance
Für schnelle Websites wähle ich eine moderne PHP-Version wie 8.2 und aktiviere PHP‑FPM. Ich prüfe Kompatibilität meiner Anwendungen und schalte bei Bedarf zwischen Versionen pro Domain. OPcache sollte aktiv sein, um Antwortzeiten spürbar zu senken. Fehlerprotokolle lese ich in Plesk, um Erweiterungen gezielt anzupassen. Einen tieferen Einblick gibt dieser Beitrag zu PHP 8.2 in Plesk mit handfesten Tipps.
HTTP/2 aktivieren
Für kürzere Ladezeiten aktiviere ich HTTP/2 im Webserver und nutze TLS mit einer aktuellen Cipher‑Suite. Besonders bei vielen Assets bringt das Protokoll deutliche Vorteile. Ich teste die Konfiguration mit gängigen Tools und beobachte Latenzen im Monitoring. Bei Bedarf minimiere ich Ressourcen oder nutze Kompression. Eine praktische Anleitung zur HTTP/2 Unterstützung hilft bei sinnvollen Einstellungen.
Automation, Backups und Monitoring
Ich richte regelmäßige Backups ein, lokal und bei Bedarf in Remote‑Speicher wie S3‑kompatible Ziele. Rotationen verhindere ich durch klare Aufbewahrungsregeln und Benachrichtigungen bei Fehlern. Das Plesk Monitoring zeigt mir Last, RAM und Dienste an, sodass ich Engpässe schnell erkenne. Für wiederkehrende Aufgaben nutze ich Aufgabenplaner und Hooks. So bleibt das Hosting planbar und ich spare Zeit im Alltag.
DNS, Mail und Zustellbarkeit richtig einrichten
Damit E‑Mails zuverlässig ankommen, richte ich DNS sauber ein. Ich setze A/AAAA‑Records für die Domains, einen PTR‑Record (Reverse DNS) für die Server‑IP und korrekte MX‑Records. Über Plesk aktiviere ich SPF (TXT‑Record v=spf1), DKIM‑Signaturen und DMARC mit einer moderaten Policy (z. B. p=quarantine) zum Start. Die HELO‑Identität des Mailservers muss zum Hostnamen passen. Für ausgehende Mails begrenze ich Raten, um Spam‑Risiken zu senken, und ich überwache Bounces. Betreibe ich den DNS nicht in Plesk, übertrage ich die Einträge exakt zum Registrar/externen DNS.
# Beispiel SPF (nur Server + erlaubte Provider)
v=spf1 ip4:SERVER-IP include:_spf.provider.tld -all
# Minimaler DMARC-Record (vorsichtig starten)
v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1
Nutze ich Plesk als Mailserver, öffne ich zusätzlich die Mail‑Ports und aktiviere TLS. Ich nehme IMAPS/SMTPS in die Client‑Doku auf und empfehle moderne Ports (587/465) statt Port 25 für Submission.
# Optional: Mail- und DNS-Ports in UFW (nur wenn benötigt!)
sudo ufw allow 25,465,587/tcp # SMTP/SMTPS/Submission
sudo ufw allow 110,995/tcp # POP3/POP3S
sudo ufw allow 143,993/tcp # IMAP/IMAPS
sudo ufw allow 53/tcp
sudo ufw allow 53/udp
sudo ufw reload
Benutzer, Abonnements und Service-Pläne
Für Ordnung und Skalierbarkeit strukturiere ich Plesk mit Service‑Plänen und Abonnements. Ich definiere Limits (Domains, Speicher, E‑Mail‑Konten, Datenbanken) und lege daraus Pläne an. Kunden oder Projekte erhalten je ein Abonnement, inklusive eigenem Systembenutzer und FTP/SFTP‑Zugang. Mit Hostingeinstellungen‑Vorlagen automatisiere ich PHP‑Version, Webserver‑Modus und Standardverzeichnisse. Für Agenturen oder Reseller setze ich Rollen und Berechtigungen granular, damit nur benötigte Bereiche sichtbar sind. So vermeide ich Wildwuchs und kann Ressourcen zuverlässig kalkulieren.
Webserver‑Stack feintunen
Plesk nutzt in der Regel Nginx vor Apache als Reverse‑Proxy. Für reine statische Seiten oder Headless‑Setups kann Nginx‑only sinnvoll sein. Ich aktiviere HTTP/2, setze Kompression (gzip oder brotli, wenn verfügbar) und optimiere Keep‑Alive‑Werte. In Domainspezifischen Einstellungen kontrolliere ich Caching‑Header, Proxy‑Puffer und Web Application Firewall (WAF/ModSecurity). Für viele gleichzeitige Verbindungen erhöhe ich Worker‑Verbindungen und beobachte die Auswirkungen im Monitoring. Bei CMS‑Last schalte ich PHP‑FPM pro Domain ein und setze passende pm.max_children‑Werte, basierend auf RAM und durchschnittlicher Anfragezahl.
# Orientierung für PHP-FPM (pro Domain, anpassen!)
pm = dynamic
pm.max_children = 8
pm.max_requests = 500
pm.max_spare_servers = 4
Datenbanken und Performance
Ich bevorzuge MariaDB als Drop‑in‑Ersatz für MySQL und aktiviere das Slow‑Query‑Log, um Flaschenhälse zu finden. Für mehr Leistung passe ich InnoDB‑Parameter an, teste Änderungen und messe mit realistischen Lastprofilen. Größere Instanzen profitieren von einer separaten Datenplatte und einer Remote‑DB, um Web und Datenbank zu entkoppeln. Backups plane ich inkrementell und vermeide Vollbackups zur Hauptlastzeit.
# Beispiel my.cnf (Richtwerte, abhängig von RAM/Workload)
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT
tmp_table_size = 128M
max_heap_table_size = 128M
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
Netzwerk, IPv6 und Hostname
Ich vergebe einen FQDN als Hostname, der per A/AAAA auf die Server‑IP zeigt. Reverse DNS (PTR) setze ich konsistent, damit Mailserver und Scanner den Host als vertrauenswürdig einstufen. Hat der Server IPv6, konfiguriere ich AAAA‑Records und teste mit Ping und Webzugriff. Für Geo‑nahe Latenz und schnelle TLS‑Handshakes lohnt sich ein Blick auf die Netzwerklage (Region, Provider, Peering). In Cloud‑Umgebungen dokumentiere ich Security‑Groups zusätzlich zur UFW, damit keine Regel doppelt blockiert.
Automatisierung per CLI und Aufgaben
Neben dem GUI nutze ich die Plesk‑CLI für Skripte und wiederkehrende Aufgaben. So dokumentiere ich Änderungen als Code und kann Setups reproduzieren. Ich versioniere meine Skripte und teste sie zuerst auf einer Staging‑Instanz.
# Einmaliger Login-Link für das Panel (praktisch nach Installation)
sudo plesk login
# Admin-Passwort setzen/ändern
sudo plesk bin admin --set-password -passwd 'SicheresPasswort!'
# Domain automatisiert anlegen (Beispiel)
sudo plesk bin domain --create example.tld -owner admin -ip 203.0.113.10 -ssl true
# Regelmäßige Updates via Cron (außerhalb Wartungsfenster vermeiden)
sudo plesk installer update
# Reparatur-Werkzeug bei Problemen
sudo plesk repair all -y
Ich plane Cronjobs für Backups, Berichte und Health‑Checks. Für Projekte nutze ich Hooks (z. B. nach Domain‑Erstellung), um Standard‑Dateien, Git‑Deploys oder Sicherheitsprofile automatisch auszuspielen.
Migration und Umzug
Ziehe ich von einem anderen Server um, senke ich zuerst die DNS‑TTL, damit das Umschalten schneller greift. Mit dem Plesk‑Migrator prüfe ich Quell‑ und Zielumgebung, übernehme Domains, Datenbanken, E‑Mails und Cronjobs. Ich plane ein Wartungsfenster und teste die Zielumgebung mit einer Hosts‑Datei‑Anpassung, bevor ich DNS umstelle. Während der Umstieg läuft, friere ich Änderungen am Quellsystem ein (Code‑Freeze), um Dateninkonsistenzen zu vermeiden. Nach dem Cut‑over überwache ich Logs und Zustellraten und rolle bei Bedarf selektiv zurück.
Wartung, Updates und Rollback‑Strategie
Ich aktiviere unattended‑upgrades für Sicherheitsupdates und plane Plesk‑Komponentenupdates ins Wartungsfenster. Vor jeder größeren Änderung ziehe ich ein Snapshot oder ein vollständiges Backup, inklusive Datenbanken und Mail. Ich teste Restore‑Prozesse regelmäßig und dokumentiere sie. Für reibungslose Updates halte ich das System schlank, entferne alte PHP‑Versionen und räume Log‑Dateien auf (Logrotate, Journald‑Limits). Kritische Dienste beobachte ich mit Benachrichtigungen, damit ich frühzeitig reagieren kann.
# Sicherheitsupdates automatisieren (Ubuntu)
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Loggröße einschränken (Journald, Beispiel)
sudo sed -i 's/#SystemMaxUse=.*/SystemMaxUse=500M/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald
Erweiterte Sicherheit und Härtung
Neben Firewall, SSL und Fail2Ban sichere ich SSH mit Schlüssel‑Authentifizierung ab und deaktiviere Passwort‑Logins. Ich setze 2‑Faktor‑Authentifizierung für Plesk‑Accounts, erzwinge starke Passwörter und begrenze API‑Zugriffe. In der WAF aktiviere ich ein aktuelles Regelset und beobachte Fehlalarme, um sinnvolle Ausnahmen pro Anwendung zu definieren. Unbenutzte Systemdienste deaktiviere ich konsequent. Für Webmail aktiviere ich Brute‑Force‑Schutz und sichere die Standard‑URLs, damit Bots weniger Angriffsfläche finden.
# SSH härtung (Beispiel)
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload sshd
Stolperfallen und Fehlerbehebung
Wenn das Panel nicht erreichbar ist, prüfe ich zuerst die Firewall und rufe die IP mit Port 8443 auf. Zeigt der Browser Zertifikatswarnungen, setze ich ein gültiges Let’s‑Encrypt‑Zertifikat für das Panel. Lizenzfehler löse ich, indem ich die Lizenz neu eintrage oder temporär die Testlizenz aktiviere. Bei Paketkonflikten half mir oft ein frisches System ohne andere Panels. Reicht der Speicher nicht, verschiebe ich Backups oder erweitere das Volume.
Bei hartnäckigen Problemen starte ich den Reparaturlauf und lese gezielt Logs. Webfehler analysiere ich über die Domain‑Logs in Plesk, Panel‑Probleme im sw‑cp‑Server‑Log, Mailfehler in Postfix/Dovecot‑Logs. Mit ss/netstat prüfe ich Ports, mit systemctl den Status von Diensten. Wenn ein Restore scheitert, teste ich einzelne Komponenten (z. B. nur DB) und erhöhe die Verbosität.
# Ports und Dienste prüfen
sudo ss -ltnp | grep -E ':80|:443|:8443|:25|:587'
sudo systemctl status sw-cp-server psa httpd apache2 nginx mariadb postfix dovecot
# Plesk reparieren
sudo plesk repair installation -y
sudo plesk repair web -y
sudo plesk repair mail -y
# Panel-Logs (Beispielpfade)
sudo journalctl -u sw-cp-server -n 200 --no-pager
sudo tail -n 200 /var/log/plesk/panel.log
Kurz zusammengefasst
Mit dieser Anleitung installiere ich Plesk auf Ubuntu zügig, sicher und reproduzierbar. Ich prüfe zuerst die Voraussetzungen, aktualisiere das System, öffne die Ports und starte den Installer. Danach setze ich Admin‑Zugang, Lizenz und SSL, richte Websites, E‑Mail und Datenbanken ein und aktiviere Schutzfunktionen. Für Tempo wähle ich PHP 8.2, schalte HTTP/2 frei und beobachte die Ressourcen. So läuft meine Ubuntu‑Instanz stabil, performant und wartbar – bereit für echte Projekte.
