WordPress nativ auf Ubuntu installieren: LAMP-Stack mit Apache, MariaDB und PHP-FPM (ohne Docker)

Wer WordPress produktiv auf einem eigenen Server betreiben möchte, steht vor einer grundlegenden Entscheidung: Container oder Bare Metal? Docker-Setups sind beliebt, aber der direkte Betrieb auf dem Host – also ein klassischer LAMP-Stack – hat klare Vorteile: weniger Abstraktionsschichten, einfacheres Debugging, volle Kontrolle über PHP-Konfiguration und systemd-Integration. Diese Anleitung zeigt dir, wie du WordPress 7.0 (Stand: Mai 2026) auf Ubuntu 24.04 LTS mit Apache 2.4, MariaDB 10.11 LTS und PHP 8.3-FPM installierst – vollständig ohne Docker, dafür produktionsreif mit TLS via Let's Encrypt, UFW-Firewall und systemd-Diensten.

Voraussetzungen

1. Ubuntu 24.04 LTS Server – frische Installation empfohlen, mindestens 1 GB RAM und 10 GB freier Speicher
2. Root- oder sudo-Zugang per SSH
3. Registrierter Domainname (z. B. example.com) – der DNS-A-Record muss bereits auf die Server-IP zeigen, bevor du certbot aufrufst
4. Internetverbindung des Servers (für apt, wordpress.org-Download und Let's Encrypt)
5. Kein laufender Webserver oder Port-80-Dienst auf dem Server

Schritt 1: System aktualisieren

Vor jeder Installation bringst du das System auf den aktuellen Stand – das verhindert Paketkonflikt-Fehler später:

sudo apt update && sudo apt upgrade -y

Verifizieren: Der Befehl endet ohne Fehler. Mit lsb_release -a prüfst du, dass tatsächlich Ubuntu 24.04 läuft.

Schritt 2: Apache, PHP 8.3-FPM und alle PHP-Module installieren

WordPress benötigt mehr als nur die PHP-Grundinstallation. Pflichtmodule wie php8.3-mysql, php8.3-xml und php8.3-mbstring sind für den Betrieb zwingend; optionale Module wie php8.3-imagick und php8.3-zip brauchst du für Medienverarbeitung und Plugin-Uploads. Installiere alles auf einmal:

sudo apt install -y apache2 \
  php8.3-fpm php8.3-mysql php8.3-xml php8.3-gd \
  php8.3-curl php8.3-mbstring php8.3-zip php8.3-intl \
  php8.3-bcmath php8.3-imagick php8.3-cli unzip curl

Verifizieren: php8.3 --version gibt die PHP-Version aus; php8.3 -m | grep mysql bestätigt das Datenbankmodul.

Schritt 3: MariaDB installieren und härten

MariaDB 10.11 LTS ist die aktuell empfohlene Version für neue Produktiv-Server (Support bis Februar 2028). Das Paket mariadb-server aus den Ubuntu-24.04-Repositories liefert genau diese Version:

sudo apt install -y mariadb-server
sudo systemctl enable --now mariadb

Direkt nach der Installation härtest du MariaDB mit dem interaktiven Skript. Es entfernt anonyme Benutzer, deaktiviert den Remote-Root-Login und löscht die Test-Datenbank – alles kritische Sicherheitslücken im Default-Zustand:

sudo mysql_secure_installation

Empfehlung: Root-Passwort setzen, alle Fragen mit „Y" beantworten.

Verifizieren: sudo systemctl status mariadb zeigt active (running).

Schritt 4: WordPress-Datenbank und Benutzer anlegen

Die Datenbank muss zwingend mit utf8mb4 angelegt werden – nur so werden Emojis und alle Unicode-Sonderzeichen korrekt gespeichert. Das ältere utf8-Charset in MySQL/MariaDB ist ein Dreibyte-Subset und verursacht beim Speichern von Emojis abgeschnittene Einträge oder Fehler:

sudo mysql -u root -p <<'SQL'
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'AENDERE_ZU_STARKEM_PASSWORT';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
SQL

Verifizieren: sudo mysql -u wpuser -p -e "SHOW DATABASES;" listet wordpress auf.

Schritt 5: Apache-Module für PHP-FPM aktivieren

Apache kommuniziert mit PHP-FPM über das FastCGI-Protokoll, dafür werden drei Module benötigt: proxy_fcgi für die FPM-Verbindung, setenvif für bedingte Umgebungsvariablen und rewrite für WordPress-Permalinks. Ohne diese Module liefert Apache 500-Fehler oder ignoriert die .htaccess-Regeln komplett:

sudo a2enmod proxy_fcgi setenvif rewrite
sudo a2enconf php8.3-fpm

Verifizieren: apache2ctl -M | grep proxy_fcgi zeigt das Modul als geladen.

Schritt 6: WordPress herunterladen und entpacken

WordPress wird als offizieller Tarball direkt von wordpress.org bezogen. Kein PPA, kein inoffizielles Paket – so hast du immer die aktuelle Version und volle Kontrolle über den Updatezeitpunkt:

cd /tmp
wget https://wordpress.org/latest.tar.gz
sudo mkdir -p /var/www/wordpress
sudo tar -xzf latest.tar.gz -C /var/www/
sudo chown -R www-data:www-data /var/www/wordpress
sudo find /var/www/wordpress/ -type d -exec chmod 755 {} \;
sudo find /var/www/wordpress/ -type f -exec chmod 644 {} \;

Die Eigentümerschaft www-data:www-data ist kein optionaler Schritt: Wenn Dateien root:root gehören, können Plugins nicht installiert werden und Medien-Uploads schlagen still fehl. Verzeichnisse erhalten 755, Dateien 644 – das Minimum für sichere WordPress-Berechtigungen.

Verifizieren: ls -la /var/www/wordpress/ zeigt www-data www-data als Eigentümer aller Dateien.

Schritt 7: wp-config.php erstellen und absichern

Kopiere die Beispieldatei und trage Datenbankzugangsdaten sowie zwei wichtige Produktivschalter ein:

sudo -u www-data cp /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php
sudo nano /var/www/wordpress/wp-config.php

Passe in der Datei folgende Werte an:

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'AENDERE_ZU_STARKEM_PASSWORT' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DISABLE_WP_CRON', true );  // Cron laeuft spaeter per Systemcrontab

Den Platzhalter-Salts-Block (acht define()-Zeilen) ersetzt du durch frisch generierte Werte. Niemals den Default-Platzhalter lassen – das ist ein bekanntes Sicherheitsrisiko:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

Die komplette Ausgabe des Befehls kopierst du in wp-config.php und ersetzt damit den gesamten Salt-Block.

Schritt 8: Apache-VirtualHost mit PHP-FPM-Socket konfigurieren

Der entscheidende Unterschied zu älteren Apache-PHP-Setups: PHP-FPM wird nicht über mod_php eingebunden, sondern über einen Unix-Socket mit dem proxy:unix-Handler. Das erlaubt separate Worker-Pools, einfacheres Neustarten von PHP ohne Apache-Reload und deutlich bessere Performance unter Last.

Erstelle die VirtualHost-Datei:

sudo nano /etc/apache2/sites-available/wordpress.conf

Inhalt der Datei:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/wordpress

    <Directory /var/www/wordpress>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/wordpress_error.log
    CustomLog ${APACHE_LOG_DIR}/wordpress_access.log combined
</VirtualHost>

Ersetze example.com durch deinen echten Domainnamen. Aktiviere die Site, deaktiviere den Standard-VirtualHost (sonst landet Traffic auf der Apache-Defaultseite statt auf WordPress) und teste die Konfiguration:

sudo a2ensite wordpress.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Verifizieren: apache2ctl configtest gibt Syntax OK aus. Der Reload muss fehlerfrei verlaufen.

Schritt 9: PHP-FPM Upload-Limits anpassen

Die PHP-Standardlimits blockieren Theme- und Plugin-Uploads sofort: 2 MB Upload-Größe und 30 Sekunden Ausführungszeit sind für produktives WordPress unzureichend. Die Einstellungen müssen in der FPM-spezifischen php.ini geändert werden – nicht in /etc/php/8.3/cli/php.ini:

sudo sed -i 's/upload_max_filesize = 2M/upload_max_filesize = 64M/' /etc/php/8.3/fpm/php.ini
sudo sed -i 's/post_max_size = 8M/post_max_size = 64M/' /etc/php/8.3/fpm/php.ini
sudo sed -i 's/max_execution_time = 30/max_execution_time = 120/' /etc/php/8.3/fpm/php.ini
sudo systemctl restart php8.3-fpm

Verifizieren: Nach abgeschlossener WordPress-Installation unter „Werkzeuge → Website-Statusbericht" prüfen, ob PHP-Limits als ausreichend gemeldet werden.

Schritt 10: Alle systemd-Services aktivieren und starten

Mit systemctl enable sorgst du dafür, dass alle drei Dienste nach einem Neustart automatisch wieder starten – ohne diesen Schritt steht dein Server nach dem nächsten Update oder Reboot still:

sudo systemctl enable apache2 mariadb php8.3-fpm
sudo systemctl start apache2 mariadb php8.3-fpm
sudo systemctl status apache2 mariadb php8.3-fpm

Verifizieren: Alle drei Dienste zeigen active (running) in grüner Schrift.

Schritt 11: UFW-Firewall konfigurieren

Gib nur die unbedingt nötigen Ports frei – SSH für Verwaltungszugang und Apache Full für HTTP/HTTPS. Alle anderen Ports bleiben geschlossen:

sudo ufw allow OpenSSH
sudo ufw allow 'Apache Full'
sudo ufw enable
sudo ufw status

Verifizieren: sudo ufw status zeigt Status: active und Regeln für OpenSSH (22/tcp) sowie Apache Full (80,443/tcp).

Schritt 12: TLS/HTTPS mit Let's Encrypt einrichten

HTTPS ist seit WordPress 6.x keine Option mehr, sondern Pflicht: Admin-Cookies werden ohne TLS als unsicher markiert, und manche Funktionen (z. B. REST-API mit bestimmten Plugins) verweigern den Dienst. Let's Encrypt liefert kostenlose, 90-tägige Zertifikate; certbot --apache kümmert sich automatisch um VirtualHost-Anpassung und Weiterleitung:

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

Certbot richtet dabei automatisch einen systemd-Timer ein, der zweimal täglich prüft, ob Zertifikate in den nächsten 30 Tagen ablaufen, und sie dann erneuert. Teste die automatische Erneuerung:

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

Verifizieren: sudo certbot renew --dry-run endet mit „Congratulations, all simulated renewals succeeded."

Schritt 13: WordPress-Cron per Systemcrontab ersetzen

Der eingebaute WP-Cron wird bei jedem Seitenaufruf mitgeprüft und verlangsamt spürbar die Ladezeit – besonders bei häufigen Besuchen. Du hast DISABLE_WP_CRON = true in der wp-config.php gesetzt; jetzt richtest du den echten System-Cron ein:

sudo crontab -u www-data -e

Füge diese Zeile ein (alle 5 Minuten):

*/5 * * * * /usr/bin/php /var/www/wordpress/wp-cron.php > /dev/null 2>&1

Mehr zum Thema Cron-Konfiguration findest du in der Anleitung Cron und crontab richtig nutzen – die Grundlagen sowie im Detail zu WordPress unter WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen.

Schritt 14: WordPress-Installation im Browser abschließen

Rufe im Browser deinen Domainnamen auf. Wenn alles korrekt konfiguriert ist, wirst du automatisch zum Installationsassistenten weitergeleitet:

https://example.com/wp-admin/install.php

Trage Sitetitel, Admin-Benutzernamen, ein starkes Passwort und die Admin-E-Mail-Adresse ein. Nach dem Klick auf „WordPress installieren" ist dein CMS einsatzbereit.

Verifizieren: Das WordPress-Dashboard unter https://example.com/wp-admin/ öffnet sich ohne Fehler. Unter „Werkzeuge → Website-Statusbericht" prüfst du, ob PHP, Datenbankverbindung und Dateiberechtigungen als „Gut" gemeldet werden.

Troubleshooting / Typische Fehler

500 Internal Server Error nach der VirtualHost-Aktivierung

Ursache fast immer: a2enmod proxy_fcgi setenvif rewrite wurde nicht ausgeführt oder Apache wurde nicht neu geladen. Prüfe mit sudo apache2ctl configtest und sudo tail -20 /var/log/apache2/wordpress_error.log.

403 Forbidden beim Aufruf der Domain

Häufigste Ursachen: AllowOverride All fehlt im <Directory>-Block, oder a2enmod rewrite wurde vergessen. Prüfe zusätzlich, ob 000-default.conf noch aktiv ist – dann landet der Traffic auf der Apache-Default-Seite statt auf WordPress.

Plugins und Theme-Uploads schlagen fehl

Zwei mögliche Ursachen: Falsche Dateiberechtigungen (Eigentümer nicht www-data) oder zu niedrige Upload-Limits in /etc/php/8.3/fpm/php.ini. Nach Änderung der Limits unbedingt sudo systemctl restart php8.3-fpm ausführen.

Permalinks funktionieren nicht (404 auf Posts)

Das rewrite-Modul ist nicht aktiv, oder AllowOverride All fehlt im VirtualHost. Aktiviere das Modul mit sudo a2enmod rewrite und lade Apache neu: sudo systemctl reload apache2.

Certbot schlägt fehl mit „Could not bind to IPv4"

Apache läuft noch auf Port 80 und blockiert certbot im Standalone-Modus. Mit certbot --apache (statt --standalone) nutzt certbot die Apache-Integration und benötigt keinen freien Port.

Datenbank-Verbindungsfehler nach der Installation

Prüfe Datenbankname, Benutzername und Passwort in wp-config.php gegen den beim CREATE USER-Befehl gesetzten Wert. MariaDB unter Ubuntu 24.04 verwendet standardmäßig Socket-Auth für root; der wpuser mit Passwort muss explizit angelegt worden sein.

Häufige Fragen

Warum PHP-FPM statt mod_php?

PHP-FPM läuft als eigenständiger Prozess-Pool außerhalb des Apache-Prozesses. Das erlaubt bessere Ressourcenisolation, separate User pro Site, einfacheres Neustarten ohne Apache-Reload und deutlich höhere Nebenläufigkeit unter Last. mod_php lädt PHP in jeden Apache-Worker-Prozess und skaliert unter hoher Last deutlich schlechter.

Kann ich MariaDB durch MySQL ersetzen?

Ja, WordPress unterstützt beide. Für Ubuntu 24.04 und neue Installationen ist MariaDB 10.11 LTS die empfohlene Wahl wegen längerer LTS-Zyklen (Support bis Februar 2028). Die SQL-Befehle zum Anlegen von Datenbank und Benutzer sind identisch.

Muss ich wp-config.php manuell erstellen?

Nein, der Web-Installer kann die Datei auch selbst anlegen – dazu muss der Webserver aber Schreibrechte im DocumentRoot haben. Wer Shell-Zugang hat, sollte den manuellen Weg über wp-config-sample.php wählen: So hat man die Salts sofort unter Kontrolle und muss keine temporären Schreibrechte vergeben.

Wie erneuert sich das Let's Encrypt-Zertifikat automatisch?

Ubuntu 24.04 richtet beim certbot-Install automatisch einen systemd-Timer (certbot.timer) ein, der zweimal täglich prüft, ob Zertifikate in den nächsten 30 Tagen ablaufen, und sie dann erneuert. Mit sudo certbot renew --dry-run lässt sich das vorab testen.

Wo liegen die wichtigsten Konfigurationsdateien?

Apache-VirtualHost: /etc/apache2/sites-available/wordpress.conf; PHP-FPM: /etc/php/8.3/fpm/php.ini und Pool: /etc/php/8.3/fpm/pool.d/www.conf; WordPress-Config: /var/www/wordpress/wp-config.php; MariaDB: /etc/mysql/mariadb.conf.d/; Apache-Logs: /var/log/apache2/wordpress_error.log.

Wie sichere ich WordPress regelmäßig?

Eine vollständige WordPress-Sicherung besteht aus zwei Teilen: Datenbankdump mit mysqldump und Dateiarchiv mit tar. Beide lassen sich per Cron automatisieren. Eine bewährte Strategie findest du unter MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump und rclone-Cloud-Sync.

Fazit

Ein nativer LAMP-Stack für WordPress ist kein veraltetes Konzept, sondern eine bewusste Designentscheidung: weniger Overhead, direkter Systemzugriff, einfachere Fehlersuche in Logs und volles Verständnis jeder Konfigurationsebene. Mit Apache 2.4, MariaDB 10.11 LTS und PHP 8.3-FPM auf Ubuntu 24.04 LTS bekommst du eine produktionsreife Basis, die über systemd-Services stabil läuft und mit certbot automatisch aktuelle TLS-Zertifikate hält. Den Übergang zu einer gehärteten Server-Grundkonfiguration – SSH-Keys, automatische Sicherheitsupdates und Fail2ban – empfiehlt die Anleitung VPS absichern und härten: UFW, SSH-Keys und Fail2Ban.

Weiterführende Anleitungen und Quellen

1. WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
2. WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
3. Let's Encrypt mit certbot – TLS-Zertifikate ohne Reverse-Proxy
4. Nextcloud nativ auf Ubuntu installieren (LEMP ohne Docker)
5. MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, rclone und Cloud-Sync
6. WordPress.org – Official Installation Guide: developer.wordpress.org
7. WordPress.org – Server Requirements: wordpress.org/about/requirements
8. Ubuntu.com – Install and Configure WordPress Tutorial: ubuntu.com