DEEN
← Wiki

Eigene Webseite hosten: der Weg über den VPS

Stand: 12. August 2026 · Anleitung · VPS · Website

Vorausgesetzt wird ein VPS mit SSH-Zugang und eingerichteter Firewall (s. „Erste Schritte auf dem eigenen VPS“) sowie eine Domain, deren A-Record schon auf die VPS-IP zeigt.

Webserver installieren

sudo apt update
sudo apt install nginx

Ruft man danach die eigene IP im Browser auf, erscheint die nginx-Standardseite, ein Zeichen, dass der Webserver läuft. Bei ufw gehört Port 80 automatisch zum vordefinierten Profil „Nginx Full“:

sudo ufw allow 'Nginx Full'

Eigene Domain einrichten

Eine neue Datei unter /etc/nginx/sites-available/<domain> anlegen, darin server_name auf die eigene Domain setzen und root auf das Verzeichnis mit den eigenen Dateien zeigen lassen. Danach per Symlink aktivieren und nginx neu laden:

sudo ln -s /etc/nginx/sites-available/<domain> /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

HTTPS mit Let's Encrypt

certbot erledigt Zertifikat und nginx-Konfiguration in einem Rutsch, kostenlos, mit automatischer Verlängerung:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d deine-domain.de

Von da an landen eigene Dateien per SFTP direkt im Verzeichnis der Domain, und jede Änderung ist sofort live. Passende VPS-Größen für genau diesen Zweck stehen unter /tarife.

Vorher prüfen: zeigt die Domain wirklich schon hierher?

Der mit Abstand häufigste Grund, warum certbot scheitert, ist ein A-Record, der noch nicht oder nicht mehr auf die richtige IP zeigt. Let’s Encrypt prüft die Domain von außen. Steht dort noch die alte Adresse, schlägt die Ausstellung fehl, und die Fehlermeldung deutet nicht darauf hin. Ein Blick vorher spart die Suche danach:

dig +short deine-domain.de
curl -sI http://deine-domain.de | head -1

DNS-Änderungen brauchen je nach Anbieter und bisheriger Gültigkeitsdauer Minuten bis Stunden. Wer gerade erst umgestellt hat, wartet besser, statt certbot mehrfach laufen zu lassen: Let’s Encrypt begrenzt die Zahl der Fehlversuche je Domain und Woche.

Ein vollständiger nginx-Server-Block

Damit die Datei unter /etc/nginx/sites-available/<domain> nicht geraten werden muss, hier eine funktionierende Minimalfassung für eine statische Seite:

server {
    listen 80;
    listen [::]:80;
    server_name deine-domain.de www.deine-domain.de;
    root /var/www/deine-domain.de;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

certbot ergänzt diese Datei später selbst um den HTTPS-Teil und die Weiterleitung von http auf https. Deshalb lohnt es sich nicht, den 443er-Block von Hand zu schreiben.

Rechte richtig setzen

Ein 403 nach dem ersten Aufruf ist fast immer ein Rechteproblem, kein nginx-Fehler. Der Webserver läuft als Benutzer www-data und muss das Verzeichnis lesen dürfen, dein eigener Benutzer soll hineinschreiben können:

sudo mkdir -p /var/www/deine-domain.de
sudo chown -R $USER:www-data /var/www/deine-domain.de
sudo find /var/www/deine-domain.de -type d -exec chmod 2755 {} +
sudo find /var/www/deine-domain.de -type f -exec chmod 644 {} +

Verlängerung testen statt hoffen

certbot richtet die automatische Verlängerung selbst ein. Ob sie funktioniert, merkt man ohne Test allerdings erst, wenn das Zertifikat nach 90 Tagen abgelaufen ist, und das fällt immer im ungünstigsten Moment auf. Der Probelauf kostet zehn Sekunden:

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

Wenn PHP und eine Datenbank dazukommen

Für WordPress, ein Forum oder ein eigenes PHP-Projekt braucht es zusätzlich PHP-FPM und meistens eine Datenbank. Beides läuft auf demselben VPS, verändert aber die Größenrechnung: eine statische Seite kommt mit der kleinsten Stufe aus, eine datenbankgestützte Anwendung mit mehreren gleichzeitigen Besuchern nicht.

sudo apt install php-fpm php-mysql mariadb-server
sudo mysql_secure_installation

Wichtig dabei: MariaDB soll nur lokal erreichbar bleiben. In der Standardkonfiguration ist das der Fall. Wer das ändert, öffnet die Datenbank ins Internet, und das ist selten beabsichtigt.