Sie möchten Fly.io verlassen und Anwendung sowie Betrieb konsolidieren? WZ-IT übernimmt die PaaS-Migration ab 1.990 Euro netto auf Coolify, Docker, Kubernetes oder eine passende Zielarchitektur.
Eine Migration von Fly.io zu Coolify oder eigener Infrastruktur kann deutlich mehr sein als ein Containerumzug. Fly.io kombiniert Machines, Regionen, Anycast, private Netze, lokale Volumes, Secrets und Prozessgruppen. Vor der Zielwahl muss klar sein, welche Verteilung fachlich notwendig ist und welche nur aus der bisherigen Plattform entstanden ist.
Fly.io als laufende Topologie erfassen
Das Inventar umfasst:
- Apps, Organisationen und genutzte Regionen
- Machines, Images und Prozessgruppen
- Konfiguration aus
fly.tomlund aktuelle Machine-Einstellungen - Services, Ports, Protokolle und Health Checks
- Autostart, Autostop, Skalierung und Ressourcen
- Secrets und nicht geheime Variablen
- Volumes, Mounts und Machine-Zuordnung
- private Verbindungen über das Fly-Netz
- öffentliche IPs, Anycast, Domains und Zertifikate
- Datenbanken, Tunnels und externe Dienste
fly.toml ist ein wichtiger Ausgangspunkt, bildet aber nicht zwingend jeden aktuellen Zustand ab. Deshalb werden deklarierte Konfiguration, laufende Machines und externe Abhängigkeiten miteinander verglichen.
Muss die globale Verteilung erhalten bleiben?
Mehrere Regionen sind kein Wert an sich. Vor einer Konsolidierung werden folgende Fragen beantwortet:
- Wo befinden sich die tatsächlichen Nutzer?
- Welche Latenz ist fachlich relevant?
- Ist die Anwendung zustandslos oder regionsgebunden?
- Wie werden Daten zwischen Regionen konsistent gehalten?
- Dient die Verteilung der Verfügbarkeit oder nur der Nähe?
- Welche Recovery-Ziele gelten nach dem Wechsel?
Eine regionale Einzelumgebung kann günstiger und leichter betreibbar sein, wäre aber kein gleichwertiger Ersatz für eine aktiv verteilte Anwendung. Diese Änderung muss bewusst entschieden und getestet werden.
Machines und Prozessgruppen abbilden
| Fly.io-Ebene | Mögliche Zielabbildung |
|---|---|
| Machine | Container oder Workload mit festem Ressourcenprofil |
| Process Group | getrennte Web-, Worker- oder Job-Services |
| Service/Port | Reverse Proxy, Load Balancer oder interner Endpoint |
| Health Check | Readiness- und Liveness-Prüfung im Ziel |
| Autostop/Autostart | dauerhafter Betrieb oder bewusstes Scale-to-zero-Modell |
| Secret | Secret Management oder geschützte Plattformvariable |
| Region | Standort, Availability Zone oder Clustersegment |
Coolify passt zu überschaubaren Git- oder Image-basierten Anwendungen. Bei mehreren Nodes, dynamischer Orchestrierung oder anspruchsvoller Verteilung kann Kubernetes oder eine getrennte Architektur sinnvoller sein.
Private Netzwerke und öffentliche Endpunkte
Interne Fly.io-Namen und 6PN-Verbindungen sind nicht direkt portabel. Im Ziel werden Service-Namen, Netzsegmente, Firewall-Regeln und ausgehende Verbindungen explizit definiert. Dabei wird geprüft, welche Dienste öffentlich erreichbar sein müssen und welche ausschließlich intern kommunizieren.
WebSockets, Streaming, feste ausgehende IPs, OAuth-Callbacks, Webhooks und Partner-Allow-Lists gehören in den Testplan. Ein funktionierender HTTP-Aufruf allein reicht nicht als Netzwerkabnahme.
Fly Volumes und Datenbanken
Fly Volumes sind lokale Persistenz einer bestimmten Region. Sie sind kein automatisch repliziertes Shared Storage. Vor der Migration wird deshalb geklärt:
- Welche Machine schreibt auf welches Volume?
- Gibt es Replikate oder nur eine maßgebliche Kopie?
- Wie wird ein konsistenter Export erzeugt?
- Benötigt die Zielanwendung lokales, geteiltes oder objektbasiertes Storage?
- Wie werden Backup und Restore im Ziel geprüft?
Datenbanken werden mit nativen Verfahren migriert. Bei kurzen Ausfallfenstern können Replikation oder ein finaler Delta-Sync erforderlich sein.
Testmigration und Trafficwechsel
Die Zielumgebung wird mit realistischen Daten und Lastannahmen getestet. Besondere Aufmerksamkeit gilt regionsabhängigem Verhalten, Hintergrundprozessen, Netzwerkpfaden, Wiederanlauf, Storage und Failover. Der Cutover definiert Schreibgrenze, Datenfinalisierung, DNS oder Trafficwechsel, Smoke Tests und Rückfall.
Wenn unklar ist, ob Konsolidierung, Coolify oder eine verteilte Zielarchitektur passt, liefert der PaaS Exit Review vorab eine Portabilitäts- und Zielanalyse.
