Fly.io: Docker-Apps weltweit deployen ohne Kubernetes-Komplexität

Kubernetes ist mächtig – aber für viele Teams und Projekte deutlich überdimensioniert. Fly.io füllt die Lücke zwischen einfachen Plattform-as-a-Service-Anbietern wie Heroku und der Komplexität eines eigenen Kubernetes-Clusters. Mit einem einzigen Befehl werden Docker-Container auf der eigenen globalen Infrastruktur von Fly.io gestartet – in der Region, die dem Nutzer am nächsten liegt.

Was ist Fly.io?

Fly.io ist eine Application-Hosting-Plattform, die 2017 gegründet wurde und sich auf das Deployment von Docker-Containern spezialisiert hat. Im Hintergrund läuft jeder Container als leichtgewichtige Firecracker-MicroVM – ein von AWS entwickelter Hypervisor, der die Isolierung einer virtuellen Maschine mit der Startgeschwindigkeit eines Containers kombiniert. Für Entwickler ist dieser Unterschied weitgehend transparent: Man baut ein Docker-Image und Fly.io übernimmt den Rest.

Fly.io betreibt eigene Rechenzentren in über 35 Regionen weltweit. Das Routing-System Anycast leitet eingehende Verbindungen automatisch zum nächsten verfügbaren Server weiter, was Latenzzeiten erheblich reduziert. Besonders für Full-Stack-Anwendungen, die Server-Rechenleistung benötigen und nicht auf Edge-Functions reduziert werden können, ist Fly.io eine attraktive Alternative.

flyctl CLI

flyctl ist das offizielle Kommandozeilen-Werkzeug von Fly.io. Nach der Installation und Anmeldung mit fly auth login lässt sich eine Anwendung mit fly launch starten. Der Befehl erkennt automatisch den Anwendungstyp (Node.js, Python, Go, Ruby etc.) und erstellt eine passende fly.toml-Konfigurationsdatei sowie – falls noch nicht vorhanden – ein einfaches Dockerfile.

Wichtige flyctl-Befehle im Überblick:

• fly launch – Erstellt eine neue App mit automatischer Konfiguration
• fly deploy – Baut das Docker-Image und deployed es auf Fly.io
• fly status – Zeigt den Status aller laufenden Machines der App
• fly logs – Streamt die Logs aller Instanzen in Echtzeit
• fly ssh console – Öffnet eine SSH-Session in eine laufende Machine
• fly scale count 3 – Skaliert die App auf drei Instanzen
• fly secrets set KEY=value – Setzt Umgebungsvariablen verschlüsselt

fly.toml Konfiguration

Die fly.toml-Datei im Projektverzeichnis beschreibt, wie die Anwendung auf Fly.io ausgeführt wird. Ein typisches Beispiel für eine Node.js-Webanwendung:

app = "meine-app"
primary_region = "fra"

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

[vm]
  memory = "256mb"
  cpu_kind = "shared"
  cpus = 1

Die Option auto_stop_machines = true sorgt dafür, dass Machines bei fehlenden Anfragen heruntergefahren werden. auto_start_machines = true startet sie bei eingehenden Anfragen neu. Für Produktionsanwendungen sollte min_machines_running auf mindestens 1 gesetzt werden, um Cold Starts zu vermeiden.

Multi-Region-Deployment

Fly.io macht Multi-Region-Deployments ungewöhnlich einfach. Nach dem ersten Deployment in der Primärregion genügt fly scale count 1 --region sin, um eine zusätzliche Instanz in Singapur zu starten. Das Anycast-Routing von Fly.io übernimmt die Verteilung der Anfragen automatisch. Für zustandslose Anwendungen ist das der direkteste Weg zu globaler Niedriglatenz.

Bei zustandsbehafteten Anwendungen mit Datenbankzugriffen muss man aufpassen: Schreibzugriffe auf eine zentrale Datenbank erzeugen Latenz, wenn die Machine in Singapur auf eine Datenbank in Frankfurt schreiben muss. Fly Postgres bietet hier eine Lösung durch Read Replicas in mehreren Regionen.

Machines API

Die Machines API ist die Low-Level-Schnittstelle zu Fly.io, die über einen einfachen HTTPS-Aufruf einzelne VMs starten, stoppen und konfigurieren kann. Sie ist besonders nützlich für dynamische Workloads wie CI/CD-Runner, temporäre Verarbeitungsaufgaben oder Sandbox-Umgebungen, die on-demand erstellt und nach der Aufgabe wieder vernichtet werden. Plattformen wie Machines API-Dokumentation beschreiben alle verfügbaren Endpunkte.

Volumes für persistente Daten

Fly Volumes sind persistente Block-Storage-Volumes, die an Machines angehängt werden können. Ein Volume wird mit fly volumes create data --size 10 --region fra erstellt und in der fly.toml als Mount-Point eingebunden. Volumes eignen sich für SQLite-Datenbanken, Datei-Uploads oder andere Daten, die über Neustarts hinaus erhalten bleiben sollen.

Fly Postgres

Fly Postgres ist eine PostgreSQL-Datenbank, die direkt auf Fly.io als Gruppe von Machines läuft. Sie wird mit fly postgres create erstellt und automatisch als interne Datenbank an eine App angekoppelt. Im Hintergrund nutzt Fly Postgres Patroni für automatisches Failover: Fällt der Primary-Node aus, wird ein Replica innerhalb von Sekunden zum neuen Primary befördert. Read Replicas in anderen Regionen lassen sich ebenfalls hinzufügen.

Wichtig: Fly Postgres ist kein vollständig verwalteter Service wie Amazon RDS. Datenbankupdates, Backups und Monitoring liegen in der Verantwortung des Nutzers. flyctl bietet zwar Hilfsbefehle wie fly postgres backup, aber für produktionskritische Datenbanken sollte ein dedizierter Backup-Plan implementiert werden.

Kostenloses Kontingent

Fly.io bietet ein monatliches Freikontingent: 3 Shared-CPU-1x-Machines mit 256 MB RAM (insgesamt 160 GPU-Stunden), 3 GB persistenter Volume-Speicher und 160 GB ausgehender Datenverkehr. Das reicht für kleine Anwendungen und Prototypen. Über das Freikontingent hinaus wird nach Nutzung abgerechnet – eine Shared-CPU-1x-Machine mit 256 MB kostet ca. 1,94 USD/Monat bei Dauerbetrieb.

Vergleich: Fly.io vs. Railway vs. Render vs. Heroku

Railway ist besonders einsteigerfreundlich mit einem klaren Dashboard und einfacher Datenbankintegration, hat aber weniger Regionen. Render bietet ein kostenloses Tier für Web Services, die nach Inaktivität einschlafen – für Demos gut, für Produktionsanwendungen unpraktisch. Heroku hat sein kostenloses Tier 2022 eingestellt und ist nun nur noch für Teams mit Budget interessant, die Wert auf die etablierte Plattform und das umfangreiche Add-on-Ökosystem legen.

Typischer Deploy-Workflow

Ein vollständiger Deployment-Ablauf auf Fly.io sieht typischerweise so aus:

1. fly auth login – Authentifizierung
2. fly launch – App erstellen, Region wählen, fly.toml generieren
3. fly secrets set DATABASE_URL=postgresql://... – Secrets setzen
4. fly postgres attach my-db-app – Datenbank verknüpfen
5. fly deploy – Ersten Deployment anstoßen
6. fly status – Deployment-Status prüfen
7. fly logs – Logs beobachten

Fazit

Fly.io trifft einen guten Mittelweg zwischen der Einfachheit von Heroku und der Flexibilität von Kubernetes. Docker-Container werden ohne Konfigurationsaufwand global deployed, Fly Postgres bietet eine solide Datenbankgrundlage, und das Freikontingent erlaubt risikofreies Ausprobieren. Besonders für Teams, die maximale Kontrolle über ihr Deployment-Modell wollen, ohne einen eigenen Cluster verwalten zu müssen, ist Fly.io eine ernsthafte Wahl.

Häufige Fragen

Unterstützt Fly.io auch non-HTTP-Dienste wie WebSockets oder TCP?

Ja. Fly.io unterstützt neben HTTP/HTTPS auch rohe TCP-Verbindungen. WebSockets werden transparent weitergeleitet. Für UDP-Dienste gibt es ebenfalls Unterstützung über spezielle Handler-Konfigurationen in der fly.toml. Das macht Fly.io auch für Game-Server, IRC-Bots oder andere TCP-basierte Dienste geeignet.

Wie funktioniert das Autostopp-Feature bei Fly.io?

Wenn auto_stop_machines = true gesetzt ist, fährt Fly.io eine Machine herunter, wenn sie über einen konfigurierbaren Zeitraum keine Anfragen erhalten hat. Bei einer neuen Anfrage startet die Machine automatisch neu. Der Neustart einer Firecracker-MicroVM dauert in der Regel unter 500 ms – deutlich schneller als ein Container-Kaltstart auf anderen Plattformen.

Kann ich bestehende Heroku-Apps einfach zu Fly.io migrieren?

Weitgehend ja. Fly.io unterstützt Procfile-basierte Deployments ähnlich wie Heroku. Mit fly launch erkennt flyctl viele Buildpack-basierte Projekte automatisch. Heroku-Postgres-Datenbanken lassen sich mit einem pg_dump/pg_restore-Workflow zu Fly Postgres migrieren. Heroku-Add-ons ohne Fly-Äquivalent müssen durch externe Dienste ersetzt werden.

Wie sicher sind Fly.io-Deployments in Bezug auf Datenschutz?

Fly.io speichert Container-Images und Secrets verschlüsselt. Die Verbindung zwischen Fly-Machines und dem Fly-Netzwerk ist durch WireGuard-VPN-Tunnel gesichert. Für DSGVO-Anforderungen sollte die Primärregion auf europäische Standorte (fra, ams, lhr) gesetzt werden. Fly.io bietet ein Data Processing Agreement auf Anfrage an.