Alle Produkte 
Testumgebung auf dem VPS: kurzlebige Server ohne unnötige Kosten
Eine Testumgebung lebt nicht lange: ein Release vor dem Ausrollen prüfen, einem Kunden die neue Version der Website zeigen, einen Bug auf einem sauberen System nachstellen, einen Lasttest fahren oder unbekannte Software ausprobieren, ohne den Produktivserver anzufassen. Dafür eine dauerhafte Maschine vorzuhalten, lohnt sich nicht, und eine lokale VM auf dem Laptop bietet keine echte öffentliche IP, keine Domain und kein echtes Netzwerk. Testumgebungen setzen Sie daher am bequemsten auf einem VPS mit stundenweiser Abrechnung auf – die Tabelle oben zeigt solche Tarife ab 2 GB Arbeitsspeicher.
Was ein Anbieter für Testumgebungen können sollte
- Stundenweise Abrechnung – ein Server, der nach drei Stunden gelöscht wird, kostet drei Stunden. Wie diese Abrechnung funktioniert und worin sich Anhalten und Löschen unterscheiden, erklärt die Seite VPS mit stundenweiser Abrechnung.
- Schnelle Bereitstellung – ein bis zwei Minuten vom Klick bis zum SSH-Zugang. Anbieter mit sofortiger Bereitstellung halten die Bestellung nicht für eine manuelle Prüfung zurück.
- Snapshots und Images – eine eingerichtete Testumgebung speichern und Kopien davon ausrollen, statt alles neu zu installieren.
- API und cloud-init – Server per Skript oder Pipeline anlegen und löschen und die Grundkonfiguration beim Anlegen mitgeben.
- Auswahl an Betriebssystemen – aktuelle und ältere Versionen von Ubuntu, Debian, AlmaLinux, manchmal Windows Server, um zu prüfen, wie sich die Anwendung in der Umgebung verhält, in der sie bei Kunden läuft.
Snapshots: das wichtigste Werkzeug der Testumgebung
Ein Snapshot hält den Zustand der gesamten Festplatte fest. Ein typisches Vorgehen: die Testumgebung auf einen „Referenzstand“ bringen (Betriebssystem, Abhängigkeiten, Datenbank mit Testdaten), einen Snapshot erstellen und vor jedem Durchlauf darauf zurücksetzen. So beginnt jeder Test im selben Zustand, und das Ergebnis hängt nicht von Überbleibseln früherer Läufe ab. Aus demselben Snapshot lassen sich mehrere identische Server erstellen, um zwei Branches oder zwei Konfigurationen parallel zu prüfen.
Denken Sie daran, dass die Speicherung von Snapshots und Images bei vielen Anbietern separat berechnet wird, auch wenn der Server selbst gelöscht ist. Alte Snapshots sollten Sie genauso regelmäßig aufräumen wie die Testumgebungen selbst.
Testumgebungen aus der CI
Der nächste Schritt ist, Testumgebungen automatisch anzulegen. Die Pipeline startet für jeden Merge Request per API oder Terraform einen VPS, rollt den Branch dorthin aus, führt End-to-End-Tests durch oder liefert einen Link zur Review-Umgebung und löscht den Server, sobald der Request geschlossen ist. Für solche Szenarien brauchen Sie einen Anbieter mit API und stundenweisen Tarifen; die Builds selbst laufen bequemer auf einem dauerhaften Runner – zu dessen Auswahl siehe die Seite VPS für CI/CD.
Damit eine Testumgebung nicht ewig weiterläuft, bauen Sie eine Absicherung ein: ein Label mit dem Erstellungsdatum und einen zeitgesteuerten Job, der alles löscht, was älter als einen Tag oder eine Woche ist. Vergessene Server sind der größte Kostentreiber bei Testumgebungen.
Welche Konfiguration Sie wählen sollten
Für die Testumgebung einer Website, eines Bots oder einer API reichen 2 Kerne und 2–4 GB Arbeitsspeicher. Laufen mehrere Container mit Datenbank, orientieren Sie sich an 4–8 GB. Ein Lasttest ist die Ausnahme: Die Testumgebung muss der Produktion bei Prozessor, Festplatte und Arbeitsspeicher entsprechen, sonst sagen die Zahlen nichts aus. Den Lastgenerator lagern Sie besser auf einen separaten VPS aus, damit er sich die Ressourcen nicht mit dem getesteten Dienst teilt. Wenn Sie Latenzen für verschiedene Regionen prüfen, legen Sie an den gewünschten Standorten je einen kurzlebigen Server an – so sehen Sie den realen Ping leichter als anhand fremder Messungen.
Typische Fehler und Sicherheit
- Die Testumgebung ähnelt der Produktion nicht – eine andere Version von Betriebssystem, PHP oder Datenbank, und der Test besteht dort, wo auf dem Produktivserver ein Fehler auftritt. Legen Sie die Versionen im Image oder im Deployment-Skript fest.
- Manuelle Einrichtung – wird die Testumgebung von Hand aufgebaut, gelingt keine zweite identische. Ansible, Docker Compose oder cloud-init machen sie reproduzierbar.
- Anhalten statt Löschen – ein ausgeschalteter Server kostet oft weiterhin Geld für Festplatte und IP.
- Eine gemeinsame Testumgebung für alle – zwei Entwickler rollen gleichzeitig ihre Branches aus und stören sich gegenseitig; günstiger ist es, jedem einen eigenen kurzlebigen Server zu geben.
Testumgebungen werden oft „für fünf Minuten“ mit root-Passwort und offenen Ports gestartet, und eine Woche später sind sie Teil eines Botnetzes. Melden Sie sich auch bei einem temporären Server per SSH-Schlüssel an, schirmen Sie Datenbanken und Panels vom Internet ab und kopieren Sie keine echten personenbezogenen Kundendaten auf die Testumgebung – verwenden Sie anonymisierte oder generierte Daten. Review-Umgebungen schützen Sie mit Basic Auth, damit Suchmaschinen sie nicht indexieren.
Wollen Sie nur einen Anbieter ausprobieren, statt eine Testumgebung zu betreiben, sehen Sie sich Tarife mit kostenlosem Testzeitraum an: Ein paar Tage reichen, um Festplattengeschwindigkeit, Netzwerk und Bedienbarkeit des Panels zu prüfen.