So testen wir: echte Server, echte Ausgaben

Ein Selfhosting-Tutorial taugt nur so viel wie sein schwächster Befehl. Wenn in Schritt 6 ein Container nicht startet, hilft dir der Rest der Anleitung nichts mehr. Deshalb läuft hier jedes Rezept einmal komplett durch, bevor es online geht, und zwar auf einem Server, wie du ihn auch mieten kannst.

Die Testküche

Wir haben zwei Server bei netcup, die dauerhaft für Tests bereitstehen:

• einen VPS 1000 G12 mit geteilten Kernen, 8 GB RAM und Debian 13. Auf ihm wird jedes Tutorial geprüft. Das ist bewusst die kleine Maschine: Sie entspricht dem, was die meisten von euch für den Anfang bestellen. Was dort läuft, läuft auf einem größeren Server erst recht.
• einen Root-Server RS 1000 G12 mit dedizierten Kernen. Den brauchen wir, sobald ein Thema zwei Maschinen verlangt: einen Server-Umzug, eine Matrix-Föderation, ein Backup-Ziel, das wirklich woanders steht, oder einen Benchmark-Vergleich.

Auf beiden laufen Docker aus der offiziellen Paketquelle und Traefik als Reverse Proxy, genau wie in unseren Grundlagen-Tutorials beschrieben. Die Testdienste bekommen echte Subdomains und echte Let’s-Encrypt-Zertifikate. Ein Setup aus App und Anmeldedienst testen wir also mit zwei Hostnamen, so wie wir es dir auch empfehlen.

Eine Besonderheit kennen wir: Der VPS ist mit unserem eigenen Lynis-Tutorial gehärtet, unter anderem mit einer strengeren umask. Taucht ein Fehler nur dort auf, prüfen wir auf dem ungehärteten RS gegen, ob er an der Härtung liegt oder an der Anleitung.

Was „getestet“ hier heißt

Jeder Befehl im Artikel wurde auf dem Testserver ausgeführt. Die Ausgaben, die du in den Codeblöcken siehst, stammen aus genau diesen Läufen. Wir glätten sie nicht und schreiben sie nicht aus dem Gedächtnis nach, denn genau dabei schleichen sich Fehler ein. Echte IP-Adressen und Hostnamen ersetzen wir durch Platzhalter, sonst bleibt alles, wie es war.

Die Versionen stehen oben im Kasten „Getestet mit“, und die Image-Tags in den Compose-Dateien sind festgenagelt. Wenn du die Anleitung in einem halben Jahr nachkochst, bekommst du dieselben Zutaten, die wir hatten.

Manchmal finden wir beim Testen Dinge, die in keiner Doku stehen. Beim Vergleich der Reverse Proxys hat Nginx Proxy Manager zum Beispiel die Schalter für erzwungenes HTTPS verworfen, wenn man sie gleich beim Anlegen setzt. Das ist ein bekannter, seit Jahren offener Fehler. In solchen Fällen steht im Tutorial, wie du ihn umgehst, und nicht nur, wie es eigentlich sein sollte.

Was wir nicht testen können

Manches lässt sich von unserem Arbeitsplatz aus nicht vollständig prüfen. UDP-Verkehr ist so ein Fall: Videokonferenzen über WebRTC oder HTTP/3 brauchen einen Rückweg, den wir von dort nicht bekommen. Für HTTP/3 testen wir deshalb vom zweiten Server aus. Dabei fiel auch auf, dass die netcup-Firewall UDP-Antworten nicht von selbst durchlässt, was jetzt in unserer Firewall-Anleitung steht.

Mailversand ist der andere Fall. netcup sperrt ausgehende Mailports ab Werk, also prüfen wir Mails zuerst gegen einen lokalen Mail-Catcher. Wo wir etwas nicht Ende-zu-Ende prüfen konnten, schreiben wir das dazu.

Wie oft wir nachtesten

Software bewegt sich schnell, und ein Tutorial, das im Sommer stimmte, kann im Herbst schon veraltet sein. Darum gilt bei uns:

• Kurz vor der Veröffentlichung, höchstens eine Woche vorher, prüfen wir jeden Artikel noch einmal gegen die aktuellen Versionen.
• Apps, die oft große Sprünge machen, wie Nextcloud, Immich, Traefik oder mailcow, schauen wir uns häufiger an als ruhige Themen wie SSH oder Firewall-Grundlagen.
• Einmal im Quartal geht der ganze Bestand durch: Versionen, Links, Ausgaben, Screenshots.

Wann ein Artikel zuletzt überarbeitet wurde, steht direkt unter dem Titel und auf den Karten.

Wenn wir danebenliegen

Das passiert. Ein Beispiel aus dem November 2026: Oben im Artikel stand „Getestet mit … VPS 1000 G12“, unten in der Box „Im Test lief dieses Setup auf VPS 1000 G12.5“. Beides konnte nicht stimmen, denn getestet wird auf dem G12 und empfohlen wird das aktuelle Modell. Ein Hinweis von außen hat uns darauf gebracht, und am selben Tag war es auf allen Seiten korrigiert.

Wenn dir so etwas auffällt, oder wenn ein Befehl bei dir anders reagiert als beschrieben, schreib uns an feedback@serverkueche.de. Wir stellen es auf dem Testserver nach. Korrekturen gehen mit dem nächsten abendlichen Update online, und das Datum unter dem Titel zeigt dir, dass sich etwas geändert hat.

Wer hinter der Serverküche steht und wie sie sich finanziert, steht unter Über uns.