Eine Preview-Umgebung pro Pull Request, auf Servern, die dir gehören
Preview-Umgebungen pro PR sind eines der Features, die den Workflow von Vercel und Netlify im Rückblick unvermeidlich wirken lassen — ein Reviewer klickt auf einen Link, statt einen Diff zu lesen und sich auszumalen, was er tut. Was leicht übersehen wird, wenn dieser Workflow nur auf einer fremden Managed-Plattform existiert: Jede dieser Preview-Umgebungen ist ein laufender Server, und laufende Server kosten Geld, egal ob sich jemand den PR tatsächlich ansieht oder nicht.
Was das Einschalten wirklich macht
Mit verbundenem GitHub schaltest du Previews für eine App ein, und jeder Pull Request danach bekommt seine eigene vollständige Kopie — gleicher Build, gleiche Prozesstypen, eigene URL, automatisch entfernt in dem Moment, in dem der PR geschlossen wird. Kein manuelles Provisionieren pro PR, kein manuelles Aufräumen danach; der Lebenszyklus entspricht exakt dem des PRs selbst.
Der Teil, der wirklich anders ist: Previews schlafen
Das ist das Detail, das mehr zählt als der Preview-Mechanismus selbst: Neue Staging- und Preview-Apps schlafen standardmäßig nach 30 Minuten ohne Traffic ein, und die nächste Anfrage weckt sie wieder auf. Ein PR, der zwei Wochen offen bleibt, während jemand im Urlaub ist, ist kein Server, der zwei Wochen lang zum vollen Preis im Leerlauf läuft — es ist ein Server, der fast die ganze Zeit schläft und aufwacht, sobald jemand den Preview-Link wirklich wieder öffnet.
Konfigurierbar pro App unter Settings → General: nie, 10 Minuten, 30 Minuten, 1 Stunde, 6 Stunden oder ein voller Tag ohne Traffic vor dem Einschlafen — oder stattdessen Wachzeiten festlegen, bestimmte Tage und ein Zeitfenster (in der eigenen Zeitzone der App), in dem sie oben bleiben soll, und außerhalb dieses Fensters schläft sie unabhängig vom Traffic und wacht bei der nächsten Anfrage trotzdem auf.
railyard sleep my-preview-app 30Vollständige Umgebungen, nicht nur Previews
Previews sind der PR-begrenzte Fall einer größeren Idee: Environments sind vollständige Kopien eines Projekts — Produktion, Staging, was ein Team eben braucht — erstellt von der Canvas aus. Services innerhalb einer Environment referenzieren sich gegenseitig auf die normale Weise (${{api.RAILYARD_PRIVATE_URL}}), automatisch innerhalb derselben Environment aufgelöst, sodass die Services einer Staging-Environment mit der eigenen Datenbank von Staging sprechen, nicht mit der von Produktion, ohne dass irgendetwas hartkodiert den Unterschied kennen muss.
Warum das Preismodell der eigentliche Punkt ist
Ein Preview-pro-PR-System, das wie ein Produktionsserver für jeden offenen PR abrechnet, wird entweder sparsam genutzt (was den Zweck zunichtemacht, es überhaupt zu haben) oder irgendwann zu einem Posten, den jemand infrage stellt. Eines, das standardmäßig schläft, macht das Nützliche (eine laufende Environment, die man tatsächlich durchklicken kann) ohne den üblichen Tradeoff, für den Großteil der Lebensdauer eines PRs den vollen Preis für untätige Infrastruktur zu zahlen.
Vollständige Referenz: Environments and previews.