Von Fly.io kommend

Warum Teams Fly verlassen

Fly macht es einfach, Container nah an den Nutzern laufen zu lassen. Aber nutzungsbasierte Abrechnung ist schwer zu planen, die Plattform entscheidet, welche Regionen und Machine-Größen du bekommst, und “Fly Postgres” ist ein Postgres, das du selbst auf Fly-Machines verwaltest.

Railyard gibt dir denselben Container-first-Workflow auf einem Linux-Server in deinem eigenen Cloud-Account (etwa DigitalOcean, Hetzner, Vultr oder AWS), oder auf jeder Ubuntu-Box, auf die du per SSH kommst. Dein Provider stellt dir direkt in Rechnung, zu seinem Preis, und Railyard verwaltet Postgres, Redis und Backups für dich.

Der schnelle Weg: der Importer (Beta)

Anwendungen → Neue App → Import von Heroku / Render / Fly. Wähle Fly.io, füge ein Token von fly tokens create org ein und gib deine Fly-Organisation an (Standard ist personal). Wähl eine App aus, prüfe, was kopiert wird, dann importieren und deployen. Railyard behält dein Token nur für diesen Import und vergisst es nach 30 Minuten.

Was der Importer aus Flys Machines API mitbringt:

• Genau das Image, das Fly gerade laufen lässt, gepullt mit deinem Token als Registry-Passwort, sodass nichts neu gebaut wird.
• Umgebungsvariablen aus der Machine-Config, und der interne Port.
• Secret-Namen. Fly zeigt Secret-Werte nie an, also listet die Review-Seite sie auf, damit du sie erneut eingibst.

Was er dir nur meldet:

• Andere Process Groups (etwa ein worker) werden nicht kopiert. Füge sie als Worker hinzu.
• Volumes starten leer. Kopiere ihre Dateien selbst (siehe unten).
• Postgres-Daten werden vom Fly-Importer nicht kopiert. Zieh sie mit einem Dump um (siehe unten).
• Domains werden aufgelistet, nicht angebunden. Füge sie hinzu, sobald die neue App live ist.

Beta: Der Importer ist gegen Flys dokumentierte API-Antworten getestet, und auf Prod erreicht er Flys API. Er wurde noch nicht end-to-end gegen einen echten Fly-Account gefahren. Wenn etwas nicht mitkommt, nutz die manuellen Schritte unten und sag uns Bescheid.

Der manuelle Weg

1. Einen Server hinzufügen. Railyard kann einen in deinem Cloud-Account anlegen, oder du verbindest einen, den du schon hast. Siehe Einen Server hinzufügen.
2. Die App erstellen. Wenn dein Repo ein Dockerfile hat, wie die meisten Fly-Apps, zeig Railyard aufs Repo und es baut daraus. Oder deploye das Image, das du schon in eine Registry pushst. Siehe Ein Docker-Image deployen.
3. Den Port setzen. Nutze den internal_port aus dem [http_service]- oder [[services]]-Abschnitt deiner fly.toml.
4. Deine Config mitbringen. Kopiere den [env]-Block aus der fly.toml in die Variables. fly secrets list zeigt die Secret-Namen; füge die Werte aus deiner Quelle ein.
5. Eine Datenbank hinzufügen. Postgres anhängen (und Redis, falls genutzt). Railyard legt die Datenbank an und setzt DATABASE_URL / REDIS_URL.
6. Deployen und die App auf ihrer temporären sslip.io-Adresse prüfen.
7. Die Daten umziehen. Öffne einen Tunnel mit fly proxy 15432:5432 -a <deine-postgres-app>, führe pg_dump -Fc gegen localhost:15432 aus, und lade den Dump dann über Ressourcen → Daten importieren in der Railyard-App hoch. Der Upload zeigt Fortschritt an, und du kannst ihn abbrechen. Für Dateien auf einem Fly-Volume nutz fly ssh sftp get (oder tar über fly ssh console) und stell sie im Volume oder Bucket der App wieder her.
8. DNS umschalten. Füge deine Domain in Railyard hinzu und zeig den Record dann auf deinen Server. Fly bedient weiter, bis der Record wechselt, also geht nichts down. Dann die Fly-App auf null skalieren und löschen.

Wie Fly-Konzepte sich übersetzen

Fly	Railyard
Machines in mehreren Regionen	Ein oder mehrere Server, die dir gehören. Der Web-Prozess einer App kann auf mehreren Servern hinter dem Primary laufen
Process Groups ([processes])	Prozesstypen: web plus Worker, aus einem Procfile oder manuell gesetzt
release_command	Release-Command, einmal ausgeführt, bevor die neue Version Traffic bekommt
Health Checks	Ein Health-Path. Die neue Version muss ihn bestehen, bevor Traffic wechselt
Volumes	Volumes auf dem Server, mit Backups
Fly Postgres / Managed Postgres	Managed Postgres auf deinem Server oder auf einem Datenbankserver, mit verifizierten Backups und Point-in-Time-Restore
fly deploy	git push, railyard deploy, oder ein Push nach GitHub
fly logs / fly ssh console	railyard logs --follow / railyard run und der Console-Tab
Auto-Stop Machines	App Sleep: inaktive Stagings schlafen und wachen beim nächsten Request auf

Was anders ist

Railyard betreibt keinen Anycast-Edge. Deine App wird aus der Region deines Servers bedient, und automatisches Multi-Region-Routing gibt es noch nicht. Dafür ist die Rechnung ein planbarer, flacher Server-Preis, die Machines gehören dir, und wenn du Railyard nicht mehr nutzt, läuft deine App weiter.