Was beim Umzug von Render tatsächlich kaputtgeht

Render hat nichts falsch gemacht. Das macht diese Migration anders als eine Heroku-Migration: Niemand geht, weil das Produkt schlecht ist. Sie gehen, weil es Renders Infrastruktur, Renders Regionen und Renders Rechnung sind, und alle drei werden unbequemer, je mehr eine App tatsächlich wächst.

Was unverändert mitkommt

Railyards Importer liest einen Render-Account direkt über einen API-Token aus: Repository und Branch, Umgebungsvariablen, der Start-Befehl und eigene Domains kommen alle so mit, wie sie sind. Background-Worker auf Render werden zu gewöhnlichen Worker-Prozessen auf Railyard, derselbe Job, nur ein anderer Host.

Wenn du von Hand umziehst statt den Importer zu nutzen, lassen sich dieselben Dinge direkt übertragen:

Dein Dockerfile, falls du eins hast, dasselbe, aus dem Render bereits baut.
Die Intention einer render.yaml: Web- und Worker-Service-Definitionen werden zu Railyard-Prozesstypen, und ein preDeployCommand wird zu einem Release-Task, der läuft, bevor die neue Version Traffic bekommt.
Umgebungsvariablen und Environment Groups, unverändert eingefügt.
Render Postgres und Render Key Value werden zu verwalteten Postgres- und Redis-Addons, wobei die Connection-URLs genauso injiziert werden, wie Render es heute macht.

Was nicht automatisch mitkommt

Zwei Dinge brauchen einen bewussten Schritt, keinen Schalter:

Secret-File-Werte. Der Importer übernimmt die Namen alles, was Render als Secret File gespeichert hat, nicht den Inhalt, trage diese einmal von Hand neu ein.
Die eigentlichen Daten. Eine Datenbank migriert, indem ein pg_dump von Renders DATABASE_URL direkt in die neue verwaltete Postgres-Instanz gestreamt wird. Halte die alte Datenbank laufend, bis die neue korrekt antwortet, und ändere erst dann die DNS, nicht vorher.

Der Umzug, der Reihe nach

Richte Railyard auf einen Server in deinem eigenen DigitalOcean-, Hetzner- oder AWS-Account, oder hänge einen Server an, den du schon betreibst.
Füge das Repository hinzu und bestätige die Build-Methode, die Render bereits nutzt (meist das Dockerfile).
Baue die Konfiguration nach: Umgebungsvariablen einfügen, Postgres/Redis anhängen, sodass die Connection-Strings automatisch verdrahtet werden.
Deploye auf die temporäre URL und übe die App wirklich aus, Background-Jobs eingeschlossen, bevor du die DNS anfasst.
Streame die Daten über, prüfe sie, dann stelle die DNS um. Render bedient die ganze Zeit weiter, es gibt kein Zeitfenster, in dem die App offline ist.

Was danach tatsächlich anders ist

Die Maschine gehört dir. Keine Überraschung bei der Egress-Abrechnung pro GB am Ende eines guten Monats, kein Warten auf eine Region, die Render noch nicht hinzugefügt hat, und wenn du dich jemals entscheidest, auch Railyard zu verlassen, laufen die Container auf einer Box weiter, die du schon besitzt, nichts am Ausstieg hängt von uns ab.

Vollständiges technisches Mapping: Migration von Render, der Render-Vergleich, und Import von Heroku, Render, Fly oder Railway.