Fly.io zu Coolify oder eigener Infrastruktur migrieren
Timo Wevelsiep•Aktualisiert: 30.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
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.
Quellen
Lieber betreiben lassen?
Sie möchten PaaS & Cloud Exit nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
PaaS-Migration einordnen
Beschreiben Sie Quelle, Anwendung und gewünschtes Ziel. Wir prüfen den Migrationsweg für Runtime, Daten, Delivery und anschließenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Coolify kann viele Git- und Container-Deployments abbilden. Globale Fly.io-Regionen, Anycast, Machine-Steuerung, lokale Volumes und besondere private Netzwerkpfade benötigen jedoch eine eigene Zielarchitektur oder eine bewusste Konsolidierung.
fly.toml dient als wichtige Inventarquelle für Build, Prozesse, Services, Checks, Mounts und weitere Einstellungen. Die Datei wird nicht unverändert importiert, sondern in Docker-, Coolify- oder Kubernetes-Konfiguration übersetzt.
Fly Volumes sind an eine Region und Machine gebundene lokale Persistenz. Daten werden konsistent exportiert und auf das gewählte Ziel-Storage übertragen. Replikation oder Shared Storage müssen im Ziel gesondert geplant werden.
Die PaaS-Migration beginnt bei 1.990 Euro netto. Machines, Regionen, Daten, Volumes, Netzwerk, notwendige Architekturänderungen und Cutover-Anforderungen bestimmen das konkrete Angebot.
