Richte in Sekundenschnelle eine Full-Stack-Vorschauumgebung ein – ganz ohne Konfiguration

Ein Pull-Request wird eingereicht. Der reviewer möchte sehen, wie es läuft, und nicht nur den Diff lesen, also fragt jemand im Team nach: Kann ich dafür eine Umgebung bekommen? Je nachdem, wer gerade Zeit hat, kann das eine Stunde dauern. Es kann auch bis morgen dauern. Bis die Umgebung steht, hat sich der reviewer schon etwas anderem zugewandt, und seine Aufmerksamkeit wieder zu gewinnen, ist eine Aufgabe für sich. Was wäre, wenn die Vorschau-URL schon im PR enthalten wäre, bevor jemand danach fragen muss?

Was „Zero Config“ eigentlich bedeutet

Das Wichtigste auf einen Blick: Die Konfigurationsarbeit findet nur einmal statt, nämlich bei der Projekteinrichtung, und nicht jedes Mal, wenn jemand einen Branch eröffnet.

Upsun-Projekte basieren auf einer YAML-Konfigurationsdatei, die die App, ihre Dienste und Routen definiert, und diese Datei befindet sich in deinem Git-Repo. Was hier mit „Zero Config“ gemeint ist, ist das, was passiert, nachdem diese Datei eingerichtet ist und deine Umgebungsvariablen festgelegt sind. Sobald ein Projekt eingerichtet ist, erhält jeder neue Branch oder Pull Request automatisch seine eigene Umgebung, ohne dass für diesen spezifischen Branch eine zusätzliche Konfiguration erforderlich ist. Der Onboarding-Agent von Upsun kann diese anfängliche Konfigurationsdatei sogar anhand deines Repositorys vorab generieren, sodass selbst der einmalige Einrichtungsschritt größtenteils automatisiert ist. Die längere Version dieser Aussage lautet „keine inkrementelle Konfiguration pro Branch für neue Umgebungsbereitstellungen“, aber wir haben uns für die kürzere Version entschieden, um die Erklärung zu vereinfachen.

Was passiert, wenn du einen Branch eröffnest

Das Wichtigste auf einen Blick: Die Umgebung wird automatisch erstellt, neu aufgebaut und wieder abgebaut, während der Branch seinen Lebenszyklus durchläuft.

Mit der Git-Integration von Upsun löst das Öffnen eines Branches oder eines Pull-Requests automatisch die Einrichtung einer Umgebung aus. Schickst du neue Commits, wird sie neu aufgebaut. Wirst du den Branch zusammenführen oder schließen, wird sie automatisch entfernt. Deine Entwickler müssen niemals ein Ticket ausfüllen oder manuelle Schritte durchführen, um ihre Entwicklungs-Vorschauumgebungen zu erhalten.

Was dort tatsächlich läuft

Das Wichtigste auf einen Blick: Die Reviewer erhalten die gesamte Anwendung, nicht nur die Codeänderung.

Die Umgebung, die erstellt wird, ist keine abgespeckte Vorschau auf einen einzelnen Dienst oder Container. Sie umfasst den Anwendungscode, eine Kopie der Datenbank, den Suchindex und die Dateien, auf die die App angewiesen ist, sowie eine automatisch generierte URL, die mit jedem geteilt werden kann, der sie sich ansehen muss: ein reviewer, die Qualitätssicherung oder ein Produktmanager, der eine Änderung an der Benutzeroberfläche überprüft. Viele Fehler und Regressionen treten erst zutage, wenn der gesamte Stack tatsächlich zusammenläuft.

Warum das die Überprüfung beschleunigt

Das Wichtigste auf einen Blick: Manche Fehler treten erst auf, wenn der gesamte Stack tatsächlich läuft, und kein noch so gründliches Lesen eines Diffs kann sie aufdecken.

Wenn ein reviewer direkt beim Eröffnen eines PR eine live funktionierende Version einer Änderung vor sich hat, verkürzt das die Zeitspanne zwischen der Änderung und ihrer Bestätigung. Außerdem werden dadurch Probleme einer anderen Art erkannt. Eine CSS-Änderung, die im Diff korrekt aussieht, kann bei einer bestimmten Bildschirmbreite trotzdem zu Fehlern führen. Eine Datenbankmigration kann isoliert einwandfrei laufen und trotzdem mit bestehenden, realistischen Daten in Konflikt geraten, sobald diese berührt werden. Niemand wartet auf eine gemeinsam genutzte Staging-Umgebung, und niemand überprüft das Programm anhand einer Beschreibung dessen, was es tut, anstatt zu beobachten, wie es tatsächlich läuft.

Was passiert mit all diesen Umgebungen im Laufe der Zeit?

Wichtigste Erkenntnis: Nicht genutzte Umgebungen räumen sich selbst auf, sodass daraus kein Haufen vergessener Infrastruktur entsteht.

Das Einrichten einer vollständigen Umgebung pro Branch wirft eine naheliegende Frage auf: Wird das nicht teuer oder unübersichtlich, wenn Dutzende davon herumliegen? Das ist eine berechtigte Sorge in der gesamten Branche: Der „State of the Cloud Report 2026“ von Flexera ergab, dass 29 % der cloud-Ausgaben verschwendet werden, und ungenutzte Rechenkapazitäten, die einfach herumliegen – dieselbe Kategorie, in die auch eine vergessene Preview-Umgebung fällt –, sind der größte Einzelfaktor dafür. 

Upsun pausiert automatisch Preview-Umgebungen, die seit 14 Tagen nicht neu bereitgestellt wurden, sodass ungenutzte Umgebungen keine Ressourcen mehr verbrauchen, ohne dass jemand sie manuell aufspüren muss. Das Hochladen von neuem Code oder das Fortsetzen einer pausierten Umgebung aktiviert sie wieder. Wenn du den Branch zusammenführst oder schließt, wird die Umgebung endgültig entfernt. Hier hängt nichts davon ab, dass sich jemand daran erinnert, hinter sich aufzuräumen.

Warum das für die Akzeptanz bei neuen Entwicklern wichtig ist

Das Wichtigste auf einen Blick: Ein Entwickler kann den Nutzen schon beim ersten Öffnen eines Pull-Requests selbst erkennen – ganz ohne Demo oder Verkaufsgespräch.

Das ist auch der Grund, warum konfigurationsfreie Vorschauen oft gut als Selbstbedienungs-Auslöser funktionieren. Ein neuer Entwickler, der Upsun Cloud zum ersten Mal nutzt, muss nicht erst durch den Mehrwert geführt werden: Er eröffnet einen Branch, und die Umgebung wird ohne zusätzliche Schritte aufgebaut.

Bist du bereit zu sehen, wie aus einem Branch ganz von selbst eine funktionierende Umgebung wird? Starte eine 15-tägige kostenlose Testphase und öffne deinen ersten Pull-Request.

Häufig gestellte Fragen (FAQ)

Funktioniert das mit jedem Git-Anbieter? 
Upsun verfügt über native Quellintegrationen für GitHub, GitLab und Bitbucket, und jede davon erstellt automatisch Vorschau-Umgebungen für Pull-Requests oder Merge-Requests. Selbst gehostete Instanzen funktionieren ebenfalls: GitHub Enterprise, selbstverwaltetes GitLab und Bitbucket Server. Bei jedem anderen Git-Host kannst du weiterhin von deiner CI-Pipeline aus auf Upsun pushen. Du müsstest lediglich die automatische Umgebung für jeden Pull-Request selbst per Skript einrichten.

Muss ich für jede neue Vorschauumgebung eine Konfiguration erstellen? 
Nein. Die Konfiguration erfolgt auf Projektebene und wird einmalig eingerichtet. Neue Branches übernehmen sie automatisch.

Was ist in einer Vorschauumgebung außer dem Code noch enthalten? 
Eine Kopie der Datenbank, des Suchindexes und der Dateien, die die App benötigt, sowie eine automatisch generierte URL, die mit der tatsächlich in der Produktivumgebung laufenden Umgebung übereinstimmt.

Kosten inaktive Vorschau-Umgebungen auf unbestimmte Zeit weiter Geld? 
Nein. Umgebungen, die seit 14 Tagen nicht neu bereitgestellt wurden, werden automatisch pausiert und können außerdem jederzeit manuell pausiert oder wieder aufgenommen werden.