Plattform:
Tages-Workshop

Dein eigener Server — von null online

Von „ich habe keinen Server" bis zum ersten eigenen Dienst live unter Domain — sicher. Roter Faden: erst eine Website online bringen, dann n8n als echten Dienst. In 10 Stufen, ab null.

Worum geht's?

Ein eigener Server klingt nach „nur für Profis" — ist es aber nicht. Für ein paar Euro im Monat mietest du einen VPS (virtuellen Server), den du komplett selbst kontrollierst: deine Daten, dein Standort, deine Regeln.

Du lernst hier den kompletten Weg von null: Server mieten → per SSH einloggen & absichern → Domain verbinden → Reverse Proxy mit HTTPS → einen echten Dienst betreiben → ihn mit Updates, Backups & Monitoring am Laufen halten. Docker (aus dem ersten Workshop) nutzen wir nur kurz als Werkzeug — im Fokus steht der Server.

Dieses Portal ist beides: Live-Präsentation für den Workshop und Selbstlern-Kurs zum Durchklicken. Dein Fortschritt wird lokal gespeichert.

? Für wen ist ein eigener Server wichtig?

Überall, wo man Dienste datensouverän selbst betreiben will — raus aus der Abo- und US-Cloud-Abhängigkeit.

🧰
Selbstmacher & KMU
Eigene Tools (n8n, Wikis, Clouds) in eigener Hand statt Abo.
🤝
Vereine / NPOs
DSGVO-konforme, günstige Dienste selbst betreiben.
💻
Entwickler:innen
Eigene Staging-, Demo- & Hobby-Projekte live stellen.
🛡️
Datenschutz-Bewusste
Daten auf dem eigenen Server in der EU statt US-Cloud.
🌍
Souveränität
Volle Kontrolle über Standort, Updates & Zugriff.
🐳
Docker-Absolventen
Jetzt der echte Server, auf dem die Container laufen.

🗺️ Von null bis online — die Reise

Zwei Phasen: erst der schnelle, sichtbare Win (eine Website live), dann der echte Dienst.

Skizze
Phase 1VPS mieten
Phase 1SSH & absichern
Phase 1Website + Domain + HTTPS
Phase 2n8n als Dienst
Phase 2Updates · Backups · Monitoring

Phase 1 (Stufen 1–7): Server steht, erste Website sicher live unter deiner Domain. Phase 2 (8–10): echter Dienst (n8n) + sauberer Betrieb.

🧵 Roter Faden: erst Website, dann n8n

Schneller Win zuerst: In Phase 1 bringen wir eine schlichte Website live — dein erstes Erfolgserlebnis unter eigener Domain mit HTTPS. In Phase 2 stellst du dann n8n (quelloffene Automatisierung) als echten, dauerhaften Dienst daneben — hinter denselben Reverse Proxy. Genau so wächst ein echter Server.

🪜 Die 10 Stufen

Voraussetzung: Terminal-Grundlagen (siehe Terminal-Basics); Docker (Workshop 1) hilft, ist aber kein Muss. Keine Server-Vorkenntnisse nötig. Module 1–4 funktionieren als kompakter Halbtag „Server aufsetzen & absichern".
Stufe 1

Was ist ein VPS — und warum ein eigener Server?

Ein eigener virtueller Server für ein paar Euro im Monat — und wann sich das gegenüber Shared Hosting oder großer Cloud lohnt.

1 Was ist ein VPS?

VPS = Virtual Private Server: ein eigener, virtueller Server in einem Rechenzentrum, den du komplett kontrollierst — rund um die Uhr online, mit eigener IP-Adresse und vollem Root-Zugriff.

Dein eigener Computer im Netz. Du bekommst eine frische Linux-Maschine (wir nehmen Ubuntu LTS), auf der du installieren und betreiben kannst, was du willst — anders als bei Shared Hosting, wo der Anbieter alles vorgibt.

2 VPS vs. Shared Hosting vs. große Cloud

Drei Wege, etwas online zu betreiben — der VPS ist der Sweet Spot aus Kontrolle und Einfachheit.

📦
Shared Hosting
Billig & einfach, aber stark eingeschränkt: kein root, nur was der Anbieter erlaubt. Eigene Dienste? Meist nicht.
🖥️
VPS ★
Eigener Server, voller root-Zugriff, feste Kosten (~4–8 €/Monat). Volle Freiheit bei überschaubarem Aufwand — der Sweet Spot.
☁️
Große Cloud (AWS & Co.)
Maximal flexibel & skalierbar, aber komplex und mit überraschenden Kosten. Für den Anfang Overkill.

3 Was du brauchst

🖥️
Ein VPS
~4–8 €/Monat (z. B. Hostinger/Hetzner). Das Mieten zeigt Stufe 2.
🌐
Eine Domain
~10 €/Jahr bei einem Registrar — für HTTPS & schöne Adressen.
⌨️
Terminal-Basics
SSH läuft im Terminal — Grundlagen reichen (Terminal-Schulung).
⏱️
1–2 Stunden
So lange dauert der Weg von null bis zur ersten Seite live.

✓ Geschafft, wenn du …

Stufe 2

VPS mieten & einrichten

In wenigen Minuten zum eigenen Ubuntu-Server — hier am Beispiel Hostinger, übertragbar auf Hetzner & Co.

1 Provider wählen & VPS bestellen

Es gibt viele gute Anbieter. Wir zeigen den Ablauf an Hostinger — bei Hetzner, Netcup & Co. ist er fast identisch.

  • Plan: ein kleiner VPS reicht zum Start — 1–2 vCPU, ~4 GB RAM, etwas SSD.
  • Betriebssystem: Ubuntu LTS (Long-Term-Support) — stabil, riesige Community, das nutzen wir hier.
  • Standort: ein EU-Rechenzentrum (z. B. Deutschland) — gut für Datenschutz & Latenz.
  • Nach dem Bestellen bekommst du die IP-Adresse + erste Zugangsdaten (root-Passwort oder Key).

Hostinger VPS ansehen ↗ (Affiliate-Link — unterstützt FL Pro, kostet dich nichts extra)

Hostinger — VPS anlegen
Hostinger VPS-Plan-Auswahl: drei KVM-Pläne (KVM 1/2/4) mit Monatspreis und Ausstattung — vCPU-Kerne, RAM, NVMe-Speicher, Bandbreite
Plan-Auswahl bei Hostinger (KVM-Pläne). Betriebssystem (Ubuntu LTS) und Rechenzentrum wählst du danach im Bestellschritt. Übertragbar auf Hetzner & Co.

Versionsstand: Hostinger-Oberfläche · Stand Juni 2026 (UIs ändern sich).

2 Was du jetzt in der Hand hast

Nach dem Bestellen hast du drei Dinge: eine IP-Adresse (z. B. 203.0.113.10), einen Benutzer (meist root) und ein Passwort oder einen Key. Damit loggst du dich gleich per SSH ein (Stufe 3).

Ein frischer Server ist noch ungesichert (offener SSH-Port, root per Passwort). Das ist normal — wir härten ihn in Stufe 4, direkt nach dem ersten Login.

✓ Geschafft, wenn du …

Stufe 3

Erster Zugang per SSH & SSH-Keys

Sicher auf den Server einloggen — und Passwörter durch Schlüssel ersetzen.

1 Was ist SSH — und der erste Login

🔑 Tiefer einsteigen: die eigene Schulung SSH von Anfang an erklärt Schlüssel, ~/.ssh/config, Tunnel & Härtung Schritt für Schritt.

SSH (Secure Shell) ist eine verschlüsselte Verbindung, über die du den Server aus der Ferne im Terminal bedienst — als säßest du davor.

Der Login-Befehl ist überall gleich — ssh ist in Windows 10/11, macOS und Linux eingebaut:

Terminal — erster Login
› ssh root@203.0.113.10 # beim ersten Mal: Fingerprint mit „yes" bestätigen # dann das Passwort vom Provider eingeben → du bist drauf ✓
🪟 Windows: nutze das Windows Terminal oder PowerShell — ssh ist seit Windows 10 dabei.
macOS: öffne die Terminal-App — ssh ist vorinstalliert.
🐧 Linux: dein Terminal — ssh ist vorinstalliert.
Terminal — SSH-Login
Aufnahme folgt · img/stufe-3/01-ssh-login.pngErster ssh root@…-Login inkl. Fingerprint-Abfrage. IP blurren.
Der erste Login auf den frischen Server.

2 SSH-Keys statt Passwort

Passwörter kann man raten. Ein SSH-Schlüsselpaar ist deutlich sicherer — und bequemer (kein Tippen mehr).

Skizze
🔒 Privater Schlüsselbleibt auf deinem Rechner — nie weitergeben
🔓 Öffentlicher Schlüsselliegt auf dem Server (authorized_keys)

Beim Login beweist dein privater Key, dass der öffentliche auf dem Server zu dir gehört — ohne dass je ein Passwort übers Netz geht.

Schlüssel erzeugen & übertragen
› ssh-keygen -t ed25519 -C "dein-name" # einmalig: Schlüsselpaar erzeugen › ssh-copy-id root@203.0.113.10 # öffentlichen Key auf den Server
🪟 Windows: ssh-copy-id fehlt manchmal — dann den Inhalt von ~/.ssh/id_ed25519.pub manuell in die Datei ~/.ssh/authorized_keys auf dem Server kopieren.
Aufnahme — Key erzeugen & einloggen
🎬 Aufnahme folgt · img/stufe-3/02-key-setup.mp4ssh-keygen → ssh-copy-id → passwortloser Login. IP blurren.
Transkript: Schlüsselpaar mit ssh-keygen erzeugen, öffentlichen Key per ssh-copy-id auf den Server bringen, danach loggt ssh root@… ohne Passwort ein.

3 Bequemer Login mit ~/.ssh/config

Statt jedes Mal IP und Benutzer zu tippen, gib deinem Server einen Namen:

📄~/.ssh/config (auf deinem Rechner)
Host meinserver
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
Danach reicht ssh meinserver. Das Abschalten des Passwort-Logins (nur noch Key) machen wir in Stufe 4 — erst wenn der Key-Login sicher klappt, sonst sperrst du dich aus.

✓ Geschafft, wenn du …

Stufe 4

Server absichern

Die nicht verhandelbaren Basics, bevor irgendwas online geht: Updates, ein sudo-User statt root, Firewall.

1 System aktualisieren & eigener Benutzer

Zuerst alle Pakete aktuell — dann weg vom root-Dauerbetrieb: ein eigener Benutzer mit sudo-Rechten.

als root auf dem Server
› apt update && apt upgrade -y # alles aktuell › adduser max # neuen Benutzer anlegen › usermod -aG sudo max # ihm sudo-Rechte geben
Richte deinen SSH-Key auch für max ein (ssh-copy-id max@…) und logge dich künftig als max ein — sudo nur, wenn nötig, nicht mehr dauerhaft als root.

2 root- & Passwort-Login abschalten

Sobald der Key-Login als max klappt: Passwort- und root-Login aus.

🔒/etc/ssh/sshd_config (anpassen)
PermitRootLogin no
PasswordAuthentication no
Danach sudo systemctl restart ssh. Ab jetzt kommt nur noch rein, wer den passenden Key hat.
Reihenfolge ist kritisch: bleib in einem zweiten Terminal eingeloggt und teste den Key-Login zuerst — dann erst Passwort-Login abschalten. Sonst sperrst du dich aus.

3 Firewall, fail2ban & Auto-Updates

Nur die Ports offen, die du brauchst — der Rest dicht.

Skizze
22 SSH 80 HTTP 443 HTTPS 5678 n8n 5432 DB alles andere

ufw lässt nur SSH (22), HTTP (80) und HTTPS (443) durch. Dienste wie n8n oder Datenbanken bleiben intern — erreichbar nur über den Reverse Proxy (Stufe 7).

Firewall + Härtung
› sudo ufw allow OpenSSH › sudo ufw allow 80,443/tcp › sudo ufw enable # Firewall aktiv › sudo apt install -y fail2ban unattended-upgrades
ufw status
Aufnahme folgt · img/stufe-4/01-ufw-status.pngsudo ufw status mit den erlaubten Ports.
Die aktive Firewall — nur 22/80/443 offen.
fail2ban sperrt IPs nach zu vielen Fehlversuchen; unattended-upgrades zieht Sicherheits-Patches automatisch.

✓ Geschafft, wenn du …

Stufe 5

Phase-1-Win: erste Website live

Dein erstes Erfolgserlebnis — eine statische Seite über die Server-IP, ausgeliefert von einem nginx-Container.

1 Eine Seite ausliefern

Wir nehmen einen winzigen nginx-Container (Docker kennst du aus Workshop 1) und legen ihm deine HTML-Dateien hinein.

auf dem Server
› mkdir -p ~/site › echo "<h1>Hallo von meinem Server!</h1>" > ~/site/index.html › docker run -d --name web --restart unless-stopped \ -v ~/site:/usr/share/nginx/html:ro -p 80:80 nginx:alpine
Jetzt im Browser http://203.0.113.10 (deine Server-IP) öffnen — deine Seite ist live! 🎉

2 Was hier passiert

  • -v ~/site:/usr/share/nginx/html:ro — dein Ordner landet (nur lesbar) im Container, wo nginx ihn ausliefert.
  • -p 80:80 — Port 80 (HTTP) des Servers zeigt auf den Container. Darum erreichst du die Seite direkt über die IP.
  • --restart unless-stopped — der Container kommt nach einem Reboot von selbst wieder.
Noch über die nackte IP und nur http. Als Nächstes geben wir der Seite eine richtige Domain (Stufe 6) und HTTPS (Stufe 7).

✓ Geschafft, wenn du …

Stufe 6

Domain verbinden (DNS)

Aus der nackten IP wird eine echte Adresse — wie DNS funktioniert und wie du den A-Record setzt.

1 Wie DNS funktioniert

DNS ist das Telefonbuch des Internets: es übersetzt deine Domain in die IP-Adresse deines Servers.

Skizze
Browserdeinedomain.de
DNSschaut nach …
A-Record→ 203.0.113.10
Serverantwortet

Ein A-Record verknüpft die Domain mit der IPv4-Adresse deines Servers (AAAA = IPv6).

2 Den A-Record setzen

Im DNS-Bereich deines Domain-Anbieters legst du Einträge an, die auf deine Server-IP zeigen:

🌐DNS-Einträge beim Registrar
Typ   Name   Wert
A     @      203.0.113.10     # die Hauptdomain
A     www    203.0.113.10     # www-Variante
A     n8n    203.0.113.10     # Subdomain für später (Stufe 8)
@ steht für die Domain selbst. Subdomains wie n8n legst du gleich mit an — die brauchen wir für den echten Dienst.
Registrar — DNS-Verwaltung
Aufnahme folgt · img/stufe-6/01-dns-a-record.pngDNS-Maske beim Anbieter mit A-Record. Domain & IP blurren.
A-Record anlegen — bei jedem Registrar ähnlich.
Propagation: DNS-Änderungen brauchen je nach TTL ein paar Minuten bis Stunden, bis sie überall ankommen. Mit ping deinedomain.de prüfst du, ob schon deine IP zurückkommt.

✓ Geschafft, wenn du …

Stufe 7

Reverse Proxy & HTTPS

Eine zentrale Tür für alle Dienste — mit automatischem HTTPS. Wir nehmen den Nginx Proxy Manager.

1 Warum ein Reverse Proxy?

Niemand soll Ports tippen. Ein Reverse Proxy nimmt alle Anfragen auf 80/443 entgegen, kümmert sich um HTTPS und verteilt nach Domain an den richtigen Dienst.

Skizze
Browserdeinedomain.de
n8n.deinedomain.de
Reverse ProxyNPM :443
Diensteweb :80
n8n :5678

Eine Tür (Port 443) für alles. Pro Domain/Subdomain ein „Proxy-Host" → der passende Container. Das Zertifikat holt der Proxy automatisch.

2 Nginx Proxy Manager starten

NPM ist ein Reverse Proxy mit einfacher Web-Oberfläche — ideal zum Einstieg.

🔀docker-compose.yml — Nginx Proxy Manager
services:
  npm:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports: [ "80:80", "443:443", "81:81" ]   # 81 = Admin-Web-UI
    volumes: [ "./data:/data", "./letsencrypt:/etc/letsencrypt" ]
Nach docker compose up -d erreichst du die Admin-Oberfläche unter http://203.0.113.10:81 — das Standard-Login beim ersten Start sofort ändern!

3 Proxy-Host + HTTPS anlegen

In der NPM-Oberfläche legst du pro Domain einen „Proxy Host" an — und holst das Zertifikat mit zwei Klicks.

  • Domain Names: deinedomain.de
  • Forward Hostname/Port: der Website-Container (z. B. web : 80) — im selben Docker-Netz wie NPM
  • SSL-Tab: „Request a new SSL Certificate" + „Force SSL" → Let's-Encrypt-Zertifikat, automatisch erneuert
Nginx Proxy Manager — Proxy Host + SSL
Nginx Proxy Manager: „Add Proxy Host
Ablauf: Neuen Proxy Host anlegen, Domain eintragen, Ziel web:80, dann im SSL-Tab ein Let's-Encrypt-Zertifikat anfordern und „Force SSL" aktivieren — die Seite ist danach unter https:// erreichbar.
Port-Wechsel: Der Website-Container aus Stufe 5 darf Port 80 jetzt nicht mehr selbst belegen (kein -p 80:80 mehr) — der Proxy hört auf 80/443 und leitet intern an den Container weiter.

✓ Geschafft, wenn du …

Stufe 8

Der echte Dienst: n8n

Phase 2: ein dauerhafter, nützlicher Dienst neben der Website — n8n als zweite Subdomain hinter denselben Proxy.

1 n8n als Container starten

Jetzt der echte Dienst. n8n startest du wie in Workshop 1 — mit einem Volume für die Workflows und im selben Docker-Netz wie der Proxy.

🐳docker-compose.yml — n8n
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      N8N_HOST: n8n.deinedomain.de
      WEBHOOK_URL: https://n8n.deinedomain.de/
    volumes: [ "n8n_data:/home/node/.n8n" ]
    networks: [ web ]
volumes: { n8n_data: {} }
networks: { web: { external: true } }
Das Volume n8n_data hält deine Workflows. networks: web ist dasselbe Netz, in dem auch der Nginx Proxy Manager läuft (einmalig mit docker network create web anlegen) — so erreicht der Proxy n8n über den Namen n8n.
Kein -p nach außen! n8n bekommt keinen offenen Port — erreichbar wird es nur über den Proxy (Stufe 7). Genau so soll es sein: die Firewall bleibt zu.

2 Hinter den Proxy hängen

Wie in Stufe 7 — nur eine zweite Subdomain. In NPM einen neuen Proxy-Host anlegen:

  • Domain Names: n8n.deinedomain.de (der A-Record dafür steht schon aus Stufe 6)
  • Forward Hostname/Port: n8n : 5678
  • SSL: Let's-Encrypt-Zertifikat anfordern + „Force SSL"
Browser — n8n unter eigener Domain
Aufnahme folgt · img/stufe-8/01-n8n-unter-domain.pngn8n-Oberfläche unter https://n8n.deinedomain.de. Domain blurren.
n8n läuft jetzt als echter Dienst hinter HTTPS.
Geschafft — Phase 2 steht: Neben der Website läuft jetzt n8n als dauerhafter Dienst, sicher unter https://n8n.deinedomain.de. Genau so betreibt FL Pro seine Dienste.

✓ Geschafft, wenn du …

Stufe 9

Updates & Backups

Den Dienst aktuell und sicher zurückrollbar halten — mit Watchtower für n8n und automatischen Backups als Sicherheitsnetz.

1 Updates: System + Container

Zwei Ebenen aktuell halten: das Betriebssystem und deine Container.

Updates
› sudo apt update && sudo apt upgrade -y # System › docker compose pull && docker compose up -d # Container auf neue Images
Dank Volumes bleiben Daten beim Container-Update erhalten — nur die Container werden ersetzt. (System-Updates kann unattended-upgrades aus Stufe 4 automatisch erledigen.)

2 Watchtower: n8n automatisch aktuell

n8n bringt fast im Wochentakt Updates — die von Hand zu ziehen, nervt. Watchtower übernimmt das automatisch.

🔄docker-compose.yml — Watchtower
services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes: [ "/var/run/docker.sock:/var/run/docker.sock" ]
    command: --cleanup --schedule "0 0 4 * * *"   # täglich 04:00 Uhr
Watchtower prüft nachts auf neue Images, zieht sie und startet die Container neu — --cleanup räumt alte Images weg.
Bequem, aber mit doppeltem Boden: stabiler Tag (kein :next), Changelog im Blick (Major-Versionen können DB-Migrationen bringen). Watchtower braucht den Docker-Socket = privilegiert. Darum immer zusammen mit automatischem Backup (§3) — dann ist ein misslungenes Update kein Drama.

3 Backups als Sicherheitsnetz

Gerade mit Auto-Updates gilt: ein nächtliches Backup, das du zurückspielen kannst.

nächtliches Backup (Cron)
› docker run --rm -v n8n_data:/data -v /home/max/backups:/backup busybox \ tar czf /backup/n8n-$(date +%F).tgz /data
Sichert das Volume in eine datierte .tgz. Per Cron regelmäßig laufen lassen und die Sicherungen auch weg vom Server kopieren. Restore = Volume aus dem tar wiederherstellen — so ist ein kaputtes Update jederzeit umkehrbar.

✓ Geschafft, wenn du …

Stufe 10

Monitoring & gesund halten

Läuft alles? Ein Blick-Dashboard für die Verfügbarkeit plus die wichtigsten Server-Checks im Terminal.

1 Uptime-Kuma: dein Status-Dashboard

Uptime-Kuma prüft regelmäßig, ob deine Dienste erreichbar sind — mit hübschem Dashboard, Statusseite und Alerts (E-Mail/Telegram).

Uptime-Kuma starten
› docker run -d --name uptime-kuma --restart unless-stopped \ -v uptime-kuma:/app/data --network web louislam/uptime-kuma:1 # dann als status.deinedomain.de hinter den Proxy hängen (wie n8n in Stufe 8)
Uptime-Kuma — Dashboard
Aufnahme folgt · img/stufe-10/01-uptime-kuma.pngDashboard mit Monitoren für Website + n8n. Domains blurren.
Auf einen Blick: ist alles grün?
Lege Monitore für deinedomain.de und n8n.deinedomain.de an. Fällt etwas aus, bekommst du sofort eine Nachricht.

2 Server-Gesundheit per CLI

Für den schnellen Blick brauchst du kein extra Tool — vier Befehle reichen.

Server-Checks
› htop # CPU/RAM live › df -h # freier Speicherplatz › docker stats # Last je Container › journalctl -u docker -e # letzte Docker-Logs
Mehr Komfort? Beszel (leicht) oder Netdata (mächtig) liefern Ressourcen-Dashboards. Die „Profi-Liga" ist Grafana + Prometheus — für den Anfang aber Overkill.

3 Sicherheits-Recap & wie es weitergeht

Die fünf Dinge, die deinen Server sicher halten — als Merkliste fürs Gewissen:

🔑
SSH-Keys statt Passwort
Und Passwort-Login abgeschaltet.
👤
Kein root-Login
Eigener sudo-User für den Alltag.
🚪
Firewall
Nur 22/80/443 offen, Dienste nur hinter dem Proxy.
🔄
Updates + Backups
Automatisch & zurückrollbar (Stufe 9).
📈
Monitoring
Du merkst Ausfälle, bevor andere es tun.
Wie es weitergeht: Self-Hosting ist der Unterbau des Tracks „Souveräne IT / Self-Hosting". Als Nächstes: n8n richtig nutzen, dann lokale & souveräne KI und IT-Sicherheit — alles läuft jetzt auf deinem eigenen Server.

✓ Geschafft, wenn du …

Bonus

Server-Spickzettel

Die wichtigsten Befehle zum Mitnehmen. (Zählt nicht für den Fortschritt.)

▶ SSH & Dateien

ssh user@server
Auf den Server einloggen.
ssh-keygen -t ed25519
Schlüsselpaar erzeugen.
ssh-copy-id user@server
Öffentlichen Key übertragen.
scp datei user@server:~
Datei auf den Server kopieren.
~/.ssh/config
Server-Alias für ssh name.
nano datei
Datei im Terminal bearbeiten.

🧩 Server & Docker

sudo apt update && upgrade
System aktualisieren.
sudo ufw status
Firewall-Regeln ansehen.
systemctl status <dienst>
Läuft der Dienst?
docker compose up -d
Stack starten.
docker compose pull
Updates holen (dann up -d).
df -h · htop
Platz & Last prüfen.

★ Gute Gewohnheiten

  • SSH-Keys statt Passwort, kein root-Login, Firewall an.
  • Dienste nur hinter dem Reverse Proxy — kein offener Port nach außen.
  • Automatische Backups, bevor du Auto-Updates (Watchtower) anschaltest.
  • Secrets in eine .env, nie im Klartext in geteilte Dateien.
Lernkontrolle

Quiz

10 Fragen quer durch die Stufen. Ab 8 richtigen Antworten schaltest du dein Zertifikat frei.

Frage 1 von 10
…
Abschluss

Dein Zertifikat

Glückwunsch! Trage deinen Namen ein und drucke das Zertifikat (oder speichere als PDF).

FL
Florian Ludwig
AI Consultant · Kutzschbach INNOVATIONS
Zertifikat
Self-Hosting / VPS
Hiermit wird bestätigt, dass
Dein Name hier
den Workshop „Self-Hosting & VPS — von null zum ersten eigenen Dienst" erfolgreich abgeschlossen hat.
—Datum
★GEPRÜFT
Florian LudwigAI Consultant · Kutzschbach INNOVATIONS