Import aus Railway, Render oder Vercel

Läuft deine App schon auf Railway, Render oder Vercel, musst du sie Cloady nicht von Grund auf beschreiben. Verbinde Cloady einmal mit dem Anbieter, dann liest Cloady den Service aus – Repository, Branch, Umgebungsvariablen, Disk-Größe, Port, eigene Domains – und füllt die Karte New application mit dem Gefundenen vor.

Der Import legt nie selbst etwas an. Er füllt das Formular aus; du prüfst es und deployst.

Ein Service, eine Anwendung

Cloady importiert jeweils einen Service des Anbieters, und jeder wird zu einer Cloady-Anwendung.

Ein Projekt mit einem Webservice, einem Worker und einer Datenbank bedeutet also drei Importe und drei Anwendungen. Das ist Absicht: Es entspricht der Art, wie Cloady deployt, und so lässt sich jedes Teil unabhängig skalieren und neu starten.

Eine Folge solltest du einplanen: Haben sich deine Services über Variablen, die der Anbieter erzeugt hat, gegenseitig referenziert, kommen diese Verweise als der Wert herüber, den sie zum Zeitpunkt des Imports hatten, zusammen mit einer Warnung. Öffne nach dem letzten Import bei jeder App Settings → Environment und richte die Verweise auf die Cloady-Adresse des jeweils anderen Services aus.

Bevor du anfängst

Du brauchst ein Access-Token für den Anbieter. Es wird nur für diesen einen Import verwendet, nie in deinem Konto gespeichert und taucht nie in Logs auf.

Nimm das Token mit dem kleinsten Zugriffsbereich, das der Anbieter bietet, und widerrufe es danach. Cloady liest immer nur.

Den Import ausführen

1. Öffne deinen Workspace, klicke auf New application und wähle Import from another cloud. Unter Settings → Import des Workspaces öffnet sich dasselbe Formular.
2. Wähle Railway, Render oder Vercel.
3. Füge das Token ein. Optional grenzt du die Liste mit einem Scope ein – einem Railway-Workspace, einer Render-Owner-ID (usr- oder tea-) oder einem Vercel-Team.
4. Cloady listet auf, was es importieren kann, gruppiert nach Projekt. Was es nicht übernehmen kann, steht ebenfalls in der Liste, mit Begründung.
5. Wähle einen Service. Die Karte New application öffnet sich bereits ausgefüllt.
6. Prüfe sie – vor allem die Variablen – und deploye.

Deploye innerhalb von drei Stunden. Ein ausgewählter Service wird vorübergehend zwischengespeichert und nach drei Stunden aufgeräumt, wenn du ihn nicht deployst; passiert das, wähle ihn einfach noch einmal aus.

Was übernommen wird

Railway

Image oder GitHub-Repository, Variablen, Volume-Größe und Mount-Pfad, Port, Replikas und verifizierte eigene Domains. Bei Services aus einem Repository kommen auch der Build- und der Start-Befehl und das Root-Verzeichnis mit.

Nicht importiert. Sealed Variables – Railway gibt sie nie heraus, deshalb werden sie zur erneuten Eingabe aufgelistet. Cron-Zeitpläne, App Sleeping, Health Checks, TCP-Proxy-Adressen und Verweise auf andere Services im Projekt.

Render

Web-, Private- und Worker-Services mit ihren Umgebungsvariablen und verknüpften Env Groups, Disks, Plänen und verifizierten eigenen Domains. Postgres- und Key-Value-Stores kommen mit ihren Zugangsdaten herüber.

Nicht importiert. Secret Files – jede wird aufgelistet, damit du sie als Config oder als geheime Variable neu anlegen kannst. Cron-Jobs, statische Websites, Health Checks, Pre-Deploy-Befehle, Autoscaling und gespeicherte Daten.

Vercel

Das verknüpfte GitHub-Repository, der Production-Branch, das Root-Verzeichnis, Build- und Install-Befehl, verifizierte eigene Domains sowie einfache und verschlüsselte Variablen für die Zielumgebung, die du wählst.

Nicht importiert. Sensitive Variables – Vercel gibt sie nie heraus, deshalb werden sie zur erneuten Eingabe aufgelistet. Serverless- und Edge-Funktionen, Middleware, Cron-Jobs und festgelegte Node-Versionen.

Vercel-Projekte lassen sich nur importieren, wenn sie mit GitHub verknüpft sind. Projekte mit GitLab oder Bitbucket, Projekte ohne Quelle und reine CLI-Projekte erscheinen in der Liste mit dem Grund, warum sie nicht übernommen werden können.

Der letzte Punkt verändert, wie deine App läuft. Auf Cloady wird ein Vercel-Projekt zu einem dauerhaft laufenden Server, den railpack baut, nicht zu einer Sammlung von Funktionen. buildCommand wird zum Build-Befehl und installCommand zu RAILPACK_INSTALL_CMD. Besteht das Projekt aus API-Routen hinter einem Framework, das ohnehin auch einen Server bereitstellt, ändert sich dadurch meist nichts. Stützt es sich auf Edge-Middleware oder eine Funktionskonfiguration pro Route, plane ein, das in die App selbst zu verlagern.

Daten werden nie migriert

Der Import kopiert die Konfiguration, nicht die Inhalte. Volumes, Datenbanken und hochgeladene Dateien bleiben, wo sie sind.

Für einen Postgres- oder Key-Value-Store von Render legt Cloady die entsprechende App mit denselben Zugangsdaten an, aber sie startet leer – erstelle einen Dump aus dem alten Store und spiele ihn in den neuen ein, bevor du den Traffic umstellst.

Nach dem Import

Drei Dinge bleiben bewusst dir überlassen.

Secrets, die der Anbieter nicht herausgibt. Sealed Variables von Railway und Sensitive Variables von Vercel kann niemand zurücklesen, auch du nicht. Sie erscheinen unter Environment als leere Zeilen mit dem Hinweis Not readable from the provider — enter it again. Fülle sie vor dem Deploy aus.

Secret Files von Render. Jede wird als Warnung aufgeführt. Lege sie entweder als Config-Datei in der Compose-Datei der App oder als geheime Variable neu an – je nachdem, wie dein Code sie liest.

Eigene Domains. Verifizierte Domains werden angezeigt, damit du weißt, was umziehen muss, aber Cloady übernimmt sie nicht – das würde deine Live-Website mitten in der Migration lahmlegen. Sobald die importierte App läuft und du sie unter ihrer cloady.io-URL getestet hast, füge jede Domain unter Settings → Domains hinzu und stelle die DNS-Einträge um.

Was mit deinem Token und deinen Werten passiert

Das solltest du genau wissen, denn du fügst Zugangsdaten in ein Formular ein.

Das Token wird im Request-Body übertragen, nie in einer URL, nur für diesen einen Aufruf verwendet und nie gespeichert. Gibt der Anbieter einen Fehler zurück, der zufällig dein Token zitiert, wird der Text bereinigt, bevor er deinen Browser erreicht.

Die Werte deiner Variablen werden beim Import nicht gespeichert. Der Import gibt sie an deinen Browser zurück, und die erzeugte Compose-Datei verweist auf sie nur als ${NAME}. Gespeichert werden sie – verschlüsselt – erst, wenn du deployst, und nicht vorher.

Jede importierte Variable gilt standardmäßig als Secret. Cloady markiert eine Variable nur dann als nicht geheim, wenn der Anbieter das ausdrücklich angibt, und selbst dann bleibt sie geheim, wenn ihr Name nach Zugangsdaten aussieht oder ihr Wert eine URL mit eingebetteten Zugangsdaten enthält. Ist etwas verborgen, das du lieber lesen würdest, kannst du es danach unter Settings → Environment umstellen.

Wenn etwas schiefgeht

Ein Service, der ein Image aus einer privaten Registry nutzt, wird mit einer Warnung importiert statt abgelehnt. Cloady kann deine Registry-Zugangsdaten nicht mitnehmen, deshalb schlägt der Pull beim Deploy fehl, bis das Image öffentlich oder für den Cluster verfügbar ist.