Raspberry Pi Webserver

Passende Hardware im Überblick

Boards – für einen Webserver reicht wenig, für Datenbanken hilft RAM:
Raspberry Pi 5 mit 8GB RAM – die Empfehlung (Link)*
Raspberry Pi 5 mit 16GB RAM – wenn Datenbank und Container dazukommen (Link)*
Raspberry Pi 5 mit 4GB RAM – reicht für statische Seiten locker (Link)*
Raspberry Pi 4 Starter-Set – der günstige Einstieg (Link)*
Raspberry Pi Zero 2 W – winziger Server für eine einzelne HTML-Seite (Link)*

Speicher – hier entscheidet sich die Lebensdauer:
Geekworm X1001 M.2-HAT für den Pi 5 (Link)*
Intenso M.2 NVMe SSD 500GB – günstig und ausreichend (Link)*
Crucial P310 NVMe SSD 500GB – die schnellere Variante (Link)*
SanDisk Extreme Portable SSD 1TB per USB (Link)*
SanDisk Extreme A2 128GB – wenn es doch die Karte sein soll (Link)*

Für den Dauerbetrieb rund um die Uhr:
Offizielles 27-W-Netzteil für den Pi 5 (Link)*
Geekworm X1200 USV – überbrückt Stromausfälle (Link)*
Waveshare PoE-HAT – Strom und Netzwerk über ein Kabel (Link)*
Passives Alu-Gehäuse – lautlos und ohne Lüfterausfall (Link)*

Kurz gesagt: Was bringt ein eigener Webserver auf dem Raspberry Pi?

Ein Raspberry Pi Webserver ist in wenigen Minuten eingerichtet – die Kurzfassung:

• Installation in einer Zeile: sudo apt install nginx oder sudo apt install apache2 – danach liefert der Pi bereits eine Testseite aus, erreichbar über seine IP-Adresse im Browser.
• Drei sinnvolle Kandidaten: Apache ist der Klassiker mit den meisten Anleitungen, Nginx der schlanke Schnelle, Caddy der Bequeme – er holt HTTPS-Zertifikate vollautomatisch.
• LAMP heißt: Apache, MariaDB und PHP zusammen. Damit laufen dynamische Seiten, Formulare und auch WordPress.
• Ehrlich bleiben: Als Bastel- und Testumgebung ist der Pi großartig, als öffentliche Besucherseite mit echtem Traffic die falsche Wahl.
• Der harte Teil ist nicht der Server, sondern die Erreichbarkeit von außen: Domain, DynDNS, Portfreigabe – und bei DS-Lite-Anschlüssen geht der klassische Weg gar nicht mehr.
• Pflicht bei Dauerbetrieb: eine SSD statt Speicherkarte und regelmäßige Updates. Logs schreiben eine SD-Karte in Monaten kaputt.

Was ein Raspberry Pi Webserver leisten kann – und was nicht

Ein Webserver ist nichts anderes als ein Programm, das auf Port 80 (HTTP) beziehungsweise Port 443 (HTTPS) lauscht und Dateien ausliefert, wenn jemand danach fragt. Diese Aufgabe ist so genügsam, dass selbst ein Zero 2 W damit nicht ins Schwitzen kommt. Der Flaschenhals sitzt fast nie beim Prozessor, sondern beim Speicher und bei der Internetleitung.

Sinnvolle Einsatzzwecke gibt es reichlich: ein internes Dashboard fürs Smart Home, eine Statusseite fürs Heimnetz, eine Landingpage zum Ausprobieren, eine PHP-Lernumgebung, die Dokumentation der eigenen Projekte oder eine kleine Weboberfläche für ein GPIO-Bastelprojekt. Auch als Vorschalt-Instanz für andere Dienste ist ein Webserver Gold wert – dazu weiter unten mehr beim Reverse Proxy.

Wo die Grenze verläuft, ist ebenso klar: Der Pi hängt an einem privaten Anschluss mit magerem Upload. Dazu kommen Stromausfälle, wechselnde IP-Adressen und die Tatsache, dass niemand eine Verfügbarkeitsgarantie gibt. Für eine Seite, die Geld verdienen soll, kostet ordentliches Hosting weniger als der Ärger. Der Pi ist dafür der beste Übungsplatz, den man für dieses Geld bekommt – wer hier Rechte, Zertifikate und Logs verstanden hat, versteht sie auf jedem Mietserver auch.

Raspberry Pi Webserver installieren – Schritt für Schritt

1. System vorbereiten: Aktuelles Raspberry Pi OS (seit Oktober 2025 auf Basis von Debian 13 „Trixie"), 64 Bit, gern die Lite-Variante ohne Desktop. Danach aktualisieren mit sudo apt update && sudo apt full-upgrade.
2. Feste Adresse vergeben: Der Server braucht eine statische IP oder eine feste DHCP-Reservierung im Router. Ohne sie zeigt jede Weiterleitung irgendwann ins Leere.
3. Webserver installieren: sudo apt install nginx für Nginx oder sudo apt install apache2 für Apache. Beides dauert weniger als eine Minute.
4. Testen: Im Browser die IP des Pi aufrufen, etwa http://192.168.178.50. Erscheint die Standardseite, ist die Grundinstallation fertig.
5. Eigene Seite ablegen: Die Dateien gehören nach /var/www/html. Die vorhandene index.html ersetzen: sudo nano /var/www/html/index.html. Nach dem Speichern reicht ein Neuladen im Browser.
6. Rechte setzen: Der Webserver läuft als Benutzer www-data. Mit sudo chown -R www-data:www-data /var/www/html und sudo chmod -R 755 /var/www/html sind die Rechte sauber verteilt.
7. Dienst im Griff behalten: sudo systemctl status nginx zeigt den Zustand, sudo systemctl reload nginx übernimmt Änderungen ohne Unterbrechung. Bei Fehlern hilft /var/log/nginx/error.log beziehungsweise /var/log/apache2/error.log.

Apache, Nginx oder Caddy – welcher Webserver auf den Pi?

Alle drei liefern dieselbe Seite aus. Der Unterschied liegt im Aufwand beim Einrichten und Absichern.

Eine Caddyfile besteht im Kern aus dem Domainnamen und darunter root * /var/www/html sowie file_server. Caddy besorgt daraufhin selbstständig ein Let's-Encrypt-Zertifikat und erneuert es rechtzeitig – genau der Punkt, der bei Apache und Nginx sonst den meisten Nerv kostet.

LAMP-Stack einrichten: Apache, MariaDB und PHP

Sobald Seiten mehr können sollen als nur festen Text anzeigen, braucht es PHP und eine Datenbank. Das Paket-Trio heißt traditionell LAMP: Linux, Apache, MariaDB, PHP. Debian 13 bringt Apache 2.4, PHP 8.4 und MariaDB 11.8 mit, alles direkt aus den Paketquellen.

1. Installieren: sudo apt install apache2 mariadb-server php libapache2-mod-php php-mysql
2. Datenbank absichern: sudo mariadb-secure-installation – Root-Passwort setzen, anonyme Benutzer und die Testdatenbank entfernen.
3. Datenbank anlegen: In sudo mariadb mit CREATE DATABASE web; und einem eigenen Benutzer arbeiten, niemals mit dem Root-Konto. Details dazu stehen in der MariaDB-Anleitung.
4. PHP prüfen: Eine Datei /var/www/html/info.php mit dem Inhalt <?php phpinfo(); anlegen, im Browser aufrufen – und danach wieder löschen. Sie verrät sonst zu viel über das System.

Wer statt Apache lieber Nginx nutzt, installiert zusätzlich php-fpm und verweist im Server-Block darauf. Funktional ist das Ergebnis identisch, die Konfiguration nur etwas expliziter.

WordPress auf dem Pi: gute Werkstatt, schlechte Bühne

WordPress läuft auf einem Pi 4 oder Pi 5 problemlos. Nach dem LAMP-Stack lädt man das Archiv von wordpress.org, entpackt es nach /var/www/html, legt Datenbank und Benutzer an und durchläuft die Installation im Browser. Auf einem Pi 5 mit SSD fühlt sich das Backend flüssig an.

Als Testumgebung ist das enorm nützlich: Themes ausprobieren, Plugins testen, ein Update vorab prüfen, ohne die echte Seite zu gefährden. Ein Klon der Live-Seite auf dem Pi im Heimnetz gehört zu den sinnvollsten Anwendungen überhaupt.

Für eine echte Besucherseite spricht dagegen fast alles dagegen. WordPress ist das meistangegriffene System im Netz; ein ungepflegter Pi mit offenem Port ist innerhalb von Stunden Ziel automatisierter Login-Versuche. Dazu kommen der schmale Upload, fehlende Backups außer Haus und der Umstand, dass Bilder und Caching den Pi deutlich stärker fordern als reine HTML-Dateien. Wer ernsthaft Besucher erwartet, mietet Hosting für ein paar Euro im Monat und nutzt den Pi als Werkstatt daneben.

Die schnellste und sicherste Variante bleibt ohnehin eine andere: statische Seiten. Reines HTML und CSS – oder das Ergebnis eines Generators wie Hugo oder Jekyll – braucht keine Datenbank und kein PHP und bietet damit auch keine Angriffsfläche.

Von außen erreichbar: Domain, DynDNS, Portfreigabe und HTTPS

Im Heimnetz ist alles einfach. Schwierig wird es, wenn die Seite auch von außen erreichbar sein soll. Dafür braucht es drei Dinge: einen Namen, einen Weg durch den Router und ein Zertifikat.

• Name statt Zahlen: Private Anschlüsse bekommen meist täglich eine neue IP-Adresse. DynDNS gleicht das aus, indem ein Dienst den aktuellen Stand laufend nachträgt – es gibt dafür kostenlose Anbieter. Eine eigene Domain lässt sich per CNAME darauf zeigen.
• Weg durch den Router: Eine Portfreigabe leitet Port 80 und 443 an den Pi weiter. Damit steht der Pi offen im Internet und wird ab der ersten Minute von Scannern abgeklopft – diese Entscheidung sollte bewusst fallen.
• Das DS-Lite-Problem: Viele Kabel- und Glasfaseranschlüsse liefern keine eigene IPv4-Adresse mehr, sondern teilen sie mit anderen Kunden. Eine IPv4-Portfreigabe ist dann technisch unmöglich – erkennbar an einer Router-Statusseite ohne echte öffentliche IPv4 oder an einem Adressbereich wie 100.64.x.x.
• HTTPS mit Let's Encrypt: Bei Apache und Nginx erledigt das certbot: sudo apt install certbot python3-certbot-apache, danach sudo certbot --apache. Das Zertifikat ist kostenlos und erneuert sich automatisch. Voraussetzung ist eine erreichbare Domain – oder die DNS-Validierung, die auch ohne offenen Port funktioniert.
• Der Ausweg ohne offenen Port: Ein Cloudflare Tunnel baut die Verbindung von innen nach außen auf. Kein Port muss geöffnet werden, HTTPS kommt mit, DS-Lite spielt keine Rolle mehr.
• Nur für einen selbst: Soll niemand sonst zugreifen, ist ein WireGuard-VPN oder Tailscale die sicherste Variante – der Server bleibt nach außen unsichtbar.

Reverse Proxy und Absicherung des Webservers

Auf einem Pi läuft selten nur eine Seite. Meist kommen weitere Dienste dazu, jeder mit eigenem Port: 8123 hier, 3001 dort. Ein Reverse Proxy räumt damit auf. Der Webserver nimmt alle Anfragen auf Port 443 entgegen und reicht sie intern weiter – dashboard.beispiel.de landet beim einen Dienst, status.beispiel.de beim anderen. Nach außen sichtbar ist nur ein Zugang mit einem Zertifikat. Nginx und Caddy sind dafür die üblichen Werkzeuge, besonders zusammen mit Docker.

Zur Absicherung gehören vier Punkte, die keine Diskussion vertragen: Updates regelmäßig einspielen, notfalls per unattended-upgrades. Kein root – Dienste laufen unter eigenen Benutzern, der SSH-Login über einen Schlüssel statt Passwort. Fail2ban (sudo apt install fail2ban) sperrt IP-Adressen nach mehreren Fehlversuchen aus. Und eine Firewall: sudo apt install ufw, danach nur die benötigten Ports freigeben. Mehr dazu im Artikel zum Absichern des Raspberry Pi.

Typische Fehler beim Webserver auf dem Raspberry Pi

• Port 80 ist schon belegt: Läuft bereits Pi-hole, Home Assistant oder ein anderer Dienst mit Weboberfläche, startet der neue Webserver nicht. sudo ss -tlnp zeigt, wer den Port hält – dann einen der beiden umziehen.
• Rechte im Webverzeichnis: Ein „403 Forbidden" liegt fast immer an falschen Eigentümern oder einem nicht durchsuchbaren Verzeichnis. Eigentümer www-data, Verzeichnisse 755, Dateien 644 – damit ist der Fall meist erledigt.
• SD-Karte als Speicher: Zugriffs- und Fehlerprotokolle schreiben pausenlos. Berichte aus der Community zeigen, dass Karten im Dauerbetrieb oft nach wenigen Monaten aufgeben. Eine NVMe-SSD löst das endgültig.
• Server ungeschützt im Netz: Portfreigabe eingerichtet, Standardpasswort behalten, Updates vergessen – diese Kombination endet regelmäßig in einem gekaperten Gerät.
• Änderungen wirken nicht: Konfigurationsdateien werden erst nach sudo systemctl reload aktiv. Bei Apache prüft sudo apachectl configtest vorher, ob die Datei fehlerfrei ist.
• Kein Backup, kein Wächter: Webverzeichnis, Konfiguration und Datenbank-Dump gehören regelmäßig gesichert – ein Backup auf ein anderes Gerät kostet Minuten. Und ein Server, der still stirbt, fällt oft tagelang nicht auf: Uptime Kuma meldet sich, sobald die Seite nicht mehr antwortet.

Häufige Fragen zum Webserver auf dem Raspberry Pi

Welches Raspberry Pi Modell brauche ich für einen Webserver?
Für statische Seiten genügt jedes Modell ab dem Zero 2 W. Sobald PHP, eine Datenbank oder WordPress dazukommen, sind ein Pi 4 mit 4 GB oder ein Pi 5 die deutlich angenehmere Grundlage.

Apache oder Nginx – was ist besser für Anfänger?
Apache, weil es für nahezu jedes Problem eine deutschsprachige Anleitung gibt und .htaccess vieles ohne Neustart erlaubt. Nginx lohnt sich, sobald Tempo oder ein Reverse Proxy im Vordergrund stehen.

Kann ich meine Website öffentlich auf dem Pi betreiben?
Technisch ja, sinnvoll nur selten. Upload-Rate, Ausfallsicherheit und Wartungsaufwand sprechen dagegen. Für Testseiten, Dashboards und Lernprojekte ist der Pi dagegen ideal.

Was mache ich bei einem DS-Lite-Anschluss?
Eine klassische IPv4-Portfreigabe funktioniert dort nicht. Entweder man bestellt beim Anbieter eine echte IPv4-Adresse, nutzt IPv6 – oder man umgeht das Thema komplett mit einem Cloudflare Tunnel oder einem VPN.

Wie bekomme ich kostenlos HTTPS?
Über Let's Encrypt. Bei Apache und Nginx per certbot, bei Caddy ganz ohne Zutun. Die Zertifikate gelten 90 Tage und werden automatisch erneuert.

Wie viele Besucher verträgt so ein Server?
Bei statischen Seiten sind Hunderte Aufrufe pro Minute kein Problem – begrenzend ist die Upload-Rate des Anschlusses, nicht der Pi. Mit WordPress und Datenbank sinkt die Zahl auf einen Bruchteil.

Wo liegen die Dateien meiner Website?
Standardmäßig in /var/www/html. Dorthin lassen sich Dateien per SFTP oder direkt über die Kommandozeile kopieren.

Fazit

Ein Raspberry Pi Webserver ist die günstigste Möglichkeit, Webtechnik wirklich zu verstehen – und gleichzeitig ein dauerhaft nützliches Werkzeug im Heimnetz. Unsere klare Empfehlung: Starte mit Nginx und einer rein statischen Seite, denn ohne PHP und Datenbank gibt es weder Angriffsfläche noch Wartungsaufwand. Wer HTTPS und eine eigene Domain will, nimmt Caddy – die automatische Zertifikatsverwaltung spart mehr Zeit, als jede Konfigurationsoptimierung je einbringt. WordPress darf auf den Pi, aber als Werkstatt hinter dem Router, nicht als öffentliche Bühne. Und für den Zugriff von außen führt der bequemste und sicherste Weg über einen Cloudflare Tunnel oder ein VPN statt über eine offene Portfreigabe. Zwei Dinge sind dabei nicht verhandelbar: eine SSD statt Speicherkarte und regelmäßige Updates.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)