VPS für Entwickler: Testumgebungen
Eine Testumgebung sorgt dafür, dass Sie einen Fehler finden und nicht Ihre Kunden. Bei Software und Einstellungen sollte sie dem Produktivserver gleichen, bei den Ressourcen darf sie halb so groß sein und nur wenige Tage existieren. Hier lesen Sie, wie Sie eine Testumgebung günstig halten, wie Sie mehrere Versionen auf einem Server betreiben und wie Sie verhindern, dass eine Kopie der Website in den Suchergebnissen landet oder E-Mails an echte Kunden verschickt.
In der Entwicklung gibt es meist drei Umgebungen. Auf dem lokalen Rechner schreibt der Entwickler den Code. In der Testumgebung (Staging) wird die gebaute Version unter Bedingungen geprüft, die dem Betrieb nahekommen: Der Auftraggeber sieht sich eine neue Funktion an, die Testerin geht die Szenarien durch, Datenbankmigrationen werden erprobt. Der Produktivserver (Production) bedient die echten Nutzer. Manchmal kommen temporäre Umgebungen für jeden Branch hinzu: Auf ihnen wird eine einzelne Aufgabe vorgeführt, nach dem Merge werden sie gelöscht.
Was in der Testumgebung dem Produktivserver entsprechen muss
- Softwareversionen. Dasselbe Betriebssystem, dieselben Versionen von PHP, Node.js, Python, Datenbank und Webserver. Fehler, die nur unter einer anderen Version auftreten, sind die häufigsten Überraschungen beim Ausrollen.
- Einstellungen. Konfiguration des Webservers, Caching, Upload-Limits, Zeitzone und Umgebungsvariablen, mit Ausnahme von Passwörtern und Schlüsseln.
- Art des Ausrollens. Die Testumgebung wird mit demselben Skript oder derselben Pipeline aktualisiert wie der Produktivserver. So prüfen Sie auch das Ausrollen selbst und nicht nur den Code. Wie Sie eine solche Pipeline aufbauen, beschreibt der Artikel CI/CD auf dem eigenen VPS.
Was abweichen darf: die Ressourcen. Einer Testumgebung mit ein oder zwei Nutzern genügen 1–2 Kerne und 2–4 GB Arbeitsspeicher, auch wenn der Produktivserver 8 Kerne braucht. Die Datenmenge: eine anonymisierte Auswahl statt der vollständigen Datenbank. Die Geschwindigkeit unter Last auf einer verkleinerten Umgebung zu messen ist sinnlos, dafür brauchen Sie einen Server mit derselben Konfiguration wie der Produktivserver. Wie man einen solchen Test durchführt, beschreibt der Artikel Lasttest einer Website vor dem Start.
Kurzlebige Testumgebungen: stündliche Abrechnung und Snapshots
Eine Umgebung, um eine Aufgabe vorzuführen oder ein Update zu prüfen, brauchen Sie für ein paar Tage. Dafür müssen Sie nicht einen ganzen Monat bezahlen: Bei stündlicher Abrechnung wird Geld abgebucht, solange der Server existiert, nach dem Löschen enden die Abbuchungen. Laut Katalog von accsly.io mit Stand November 2026 bieten 173 von 2.248 Hostern mit VPS-Tarifen stündliche Abrechnung. Ein Tarif mit 1 Kern und 2 GB Arbeitsspeicher kostet bei ihnen im Marktmedian etwa 9,80 € im Monat, also rund 0,013 € pro Stunde, und eine Woche Testumgebung kostet etwa 2,30 €. Eine Umgebung mit 2 Kernen und 4 GB kostet etwa 21,40 € im Monat, rund 0,03 € pro Stunde, drei Tage also etwa 2,10 € (aus Rubel umgerechnet und gerundet). Die Rechnung, ab wann sich das lohnt, und die Fallstricke erklärt der Artikel Stündliche Abrechnung: wann sie sich lohnt, Tarife finden Sie in der Auswahl VPS mit stündlicher Abrechnung.
Ein Snapshot der Festplatte beschleunigt das Anlegen einer Testumgebung. Richten Sie den Server einmal ein, erstellen Sie einen Snapshot und legen Sie neue Umgebungen daraus in wenigen Minuten an. Bevor Sie eine Umgebung löschen, die Sie noch brauchen werden, erstellen Sie einen Snapshot und löschen dann den Server: Die Speicherung eines Snapshots ist meist günstiger als ein laufender Server, kostet aber ebenfalls Geld. Ein Snapshot beim selben Hoster ersetzt kein Backup, den Unterschied erklärt der Artikel VPS-Backups: Strategien und Werkzeuge.
Ist der Hoster neu für Sie, ist eine Testumgebung eine bequeme Möglichkeit, ihn vor dem Umzug der produktiven Website zu prüfen. Laut Katalog von accsly.io mit Stand November 2026 bieten 247 Hoster eine kostenlose Testphase; Bedingungen und Einschränkungen solcher Phasen erklärt der Artikel Testphase und Geld-zurück-Garantie.
Mehrere Testumgebungen auf einem Server mit Docker Compose
Brauchen Sie ständig Testumgebungen, ist es günstiger, einen größeren Server zu betreiben und darauf mehrere Versionen in Containern zu starten. Docker Compose liest standardmäßig compose.yaml und compose.override.yaml und führt mit der Option -f mehrere Dateien der Reihe nach zusammen (Docker-Dokumentation). Den gemeinsamen Teil beschreiben Sie einmal, und in compose.staging.yaml stehen die Abweichungen der Testumgebung: andere Ports, niedrigere Speicherlimits, Testvariablen.
Jede Umgebung startet unter einem eigenen Projektnamen: docker compose -p feature-123 -f compose.yaml -f compose.staging.yaml up -d. Projekte mit unterschiedlichen Namen haben eigene Container, Netze und Volumes, die Umgebungen stören sich also nicht gegenseitig. Nach außen verteilt sie ein einziger Webserver oder Reverse Proxy auf Subdomains: feature-123.stage.example.com. Wie Sie den Server für Docker vorbereiten und die Festplatte nicht mit Images füllen, erklärt der Artikel Docker auf einem VPS: der Einstieg.
Wie viele Ressourcen Sie brauchen: Rechnen Sie pro Umgebung mit Datenbank 1–2 GB Arbeitsspeicher und 5–10 GB Festplatte. Ein Server mit 2 Kernen und 4 GB trägt zwei bis drei kleine Umgebungen. Laut Katalog von accsly.io mit Stand November 2026 kostet ein solcher Tarif im Marktmedian etwa 18,50 € im Monat, ein Viertel der Tarife liegt unter 11 €. Ein Tarif mit 1 Kern und 2 GB für eine einzelne Umgebung kostet etwa 9,90 €, ein Viertel liegt unter 6,20 €. Auswahlen: VPS für eine Testumgebung und VPS für Docker.
Wie Sie die Testumgebung vor Suchmaschinen verbergen
Eine Kopie der Website in den Suchergebnissen bedeutet doppelte Seiten, die mit der produktiven Website konkurrieren, und die Veröffentlichung von Inhalten, die noch nicht freigegeben sind. Die Möglichkeiten nach Zuverlässigkeit:
- robots.txt schützt nicht. Google schreibt ausdrücklich, dass ein Verbot in robots.txt kein Mittel ist, eine Seite aus der Suche herauszuhalten: Eine Adresse, auf die verlinkt wird, kann in den Ergebnissen erscheinen, auch wenn der Crawler sie nie besucht hat.
- noindex. Das Meta-Tag
<meta name="robots" content="noindex">oder der HeaderX-Robots-Tag: noindexuntersagt die Indexierung; den Header können Sie in der Webserver-Konfiguration einfacher für die gesamte Umgebung setzen. Google und Bing unterstützen beides. Der Crawler muss dieses Verbot sehen können, deshalb dürfen Sie die Umgebung nicht gleichzeitig in robots.txt sperren (Google-Dokumentation). - Ein Passwort ist die zuverlässigste Variante. Die Basic-Authentifizierung in nginx aktivieren Sie mit zwei Direktiven,
auth_basicundauth_basic_user_file, die Passwortdatei erzeugen Sie mit dem Werkzeughtpasswd(nginx-Dokumentation). Die Direktivesatisfy anylässt Zugriffe von den Büroadressen ohne Passwort zu und verlangt es von allen anderen. Der Crawler sieht dann keine einzige Seite.
Der Name der Testumgebung ist kein Geheimnis. Let's Encrypt veröffentlicht jedes ausgestellte Zertifikat in den öffentlichen Certificate-Transparency-Logs, und daraus sind alle Subdomains ersichtlich, für die Zertifikate ausgestellt wurden. Ein Zertifikat für *.stage.example.com verbirgt die Namen der einzelnen Umgebungen, ersetzt aber nicht den Passwortschutz. Wie Sie solche Zertifikate ausstellen und Subdomains einrichten, erklären die Artikel SSL-Zertifikate: kostenlos und kostenpflichtig und Domains und DNS für Serverbetreiber.
Daten und Nebenwirkungen
- Kopieren Sie die Produktivdatenbank nicht unverändert. Sie enthält personenbezogene Daten Ihrer Kunden, und die Testumgebung ist schlechter geschützt als der Produktivserver. Anonymisieren Sie Namen, Telefonnummern, E-Mail-Adressen und Zahlungsdaten oder stellen Sie einen eigenen Testdatensatz zusammen. Die DSGVO verlangt Datenminimierung: Echte Kundendaten haben in einer Testumgebung nur etwas zu suchen, wenn es dafür einen Zweck und eine Rechtsgrundlage gibt, mehr dazu im Artikel DSGVO und Hosting.
- Schalten Sie den Versand von E-Mails und SMS ab. Eine Testumgebung mit einer Kopie der Datenbank kann Benachrichtigungen an echte Kunden verschicken. Leiten Sie ausgehende E-Mails in ein Test-Postfach (Mail-Catcher) oder deaktivieren Sie sie.
- Zahlungen nur im Testmodus. Zahlungsanbieter stellen Testschlüssel und Testkarten bereit; produktive Schlüssel haben in der Testumgebung nichts verloren.
- Prüfen Sie geplante Aufgaben. Exporte an Marktplätze, die Synchronisierung mit dem CRM und Aufrufe externer APIs aus cron müssen in der Testumgebung auf Testsysteme zeigen oder abgeschaltet sein.
- Eigene Schlüssel und Passwörter. Zugang zur Testumgebung erhalten externe Dienstleister und Tester; kein Schlüssel aus der Testumgebung darf den Produktivserver öffnen.
Vergessene Testumgebungen
Eine vergessene Testumgebung kostet jeden Monat Geld und wird mit der Zeit zur verwundbarsten Stelle: Updates werden nicht eingespielt, die Passwörter sind alt, und die Kopie der Datenbank steht Dienstleistern offen, die längst nicht mehr für Sie arbeiten. Einige Regeln helfen, das zu vermeiden:
- jede Testumgebung hat einen Verantwortlichen und ein Löschdatum, festgehalten im Namen oder in einem Label im Panel des Hosters;
- temporäre Umgebungen für Branches werden nach dem Merge von derselben Pipeline gelöscht, die sie angelegt hat;
- eine dauerhafte Testumgebung wird zusammen mit dem Produktivserver aktualisiert und genauso abgesichert: Anmeldung nur per Schlüssel, Firewall, Sicherheitsupdates (Die ersten 10 Schritte nach dem VPS-Kauf: Sicherheit);
- gleichen Sie einmal im Monat die Serverliste im Panel des Hosters mit der Liste der benötigten Umgebungen ab und löschen Sie überflüssige.