In vielen Projekten startet man mit Cloudflare Workers: schnell, simpel, kein eigenes Hosting. Irgendwann stößt man an Grenzen – sei es bei State, Laufzeiten, Speicher oder DSGVO-Anforderungen.

An diesem Punkt wird Fly.io spannend: Container statt nackter Functions, VMs statt Isolates – aber trotzdem Edge-nahe, global und schnell.

Dieser Artikel zeigt:

1. Welche Edge-Funktionen Fly.io bietet
2. Wie Skalierung & Multi-Region funktionieren
3. Wann und wie du von Cloudflare Workers wechseln solltest

Edge-Funktionen von Fly.io im Überblick

Fly.io bringt mehrere Bausteine mit, die zusammen eine Edge-Plattform ergeben.

Anycast Networking

• Du bekommst globale Anycast-IPs.
• Egal, wo der User sitzt: der Traffic wird automatisch zur nächstgelegenen Region deiner App geroutet.
• Kein komplexes Traffic-Routing, kein Geo-DNS – alles im Routing-Layer gelöst.

Fly Machines: Micro-VMs aus Docker-Containern

• Du baust ein Docker-Image deiner App.
• Fly startet daraus Machines:
  • Bootzeit ~300 ms (kann zu Zero skalieren)
  • CPU/RAM frei wählbar
  • GPUs optional (z. B. für AI-Workloads)
  • geeignet für HTTP-Server, Worker, Cronjobs, WebSockets

Für dich als Entwickler heißt das: Du schreibst einen normalen HTTP-Server (z. B. Express, Hono, FastAPI) und lässt ihn auf Fly laufen – Edge-Verteilung übernimmt die Plattform.

Private Networking (WireGuard)

• Services kommunizieren über ein privates Overlay-Netzwerk
• Basierend auf WireGuard
• Ideal für interne APIs, DB-Zugriffe, Microservices ohne öffentliche Exposition

Gerade mit einem EU-Fokus (z. B. Home-Assistant-Integrationen, IoT-Hubs, interne Tools) kannst du gezielt EU-Regionen nutzen und Datenflüsse besser kontrollieren.

Multi-Region-Deployment & Skalierung mit flyctl

Fly.io ist stark CLI-getrieben. Die wichtigsten Konzepte:

Horizontale Skalierung: Mehr Instanzen

# Anzahl Machines erhöhen
fly scale count 4

# Regionsspezifisch skalieren
fly scale count 2 --region fra

• fly scale count startet zusätzliche Machines deiner App.
• Kombiniert mit Regions-Management:
  • fly regions add fra
  • fly regions add cdg
• Ergebnis: deine App läuft in mehreren Rechenzentren, Anycast verteilt den Traffic.

Autoscaling aktivierst du so:

fly autoscale balanced min=1 max=10

Damit kann Fly je nach Traffic zwischen 1 und 10 Instanzen hoch- und runterskalieren.

Vertikale Skalierung: Mehr Power pro Instanz

# leistungsfähigere VM-Klasse
fly scale vm shared-cpu-2x

# Arbeitsspeicher erhöhen
fly scale memory 1024

• Du änderst CPU-/RAM-Profil, ohne alles manuell neu zu orchestrieren.
• Fly deployed neue Machines mit den gewünschten Ressourcen.

Storage & State

• Über Volumes kannst du persistenten Speicher anhängen.
• Für Datenbanken:
  • Managed Postgres
  • eigene DBs in Containern
  • SQLite mit Replikationslösungen wie LiteFS

Damit bist du deutlich flexibler als in klassischen FaaS-Umgebungen, wo „State” oft nur über externe Services oder Spezialkonstrukte möglich ist.

Wann ein Wechsel von Cloudflare Workers sinnvoll ist

Nicht jeder Worker muss migriert werden. Cloudflare Workers sind perfekt für:

• Leichte, stateless Request-Transformationen
• Auth-Middleware und Token-Validierung
• Einfache API-Proxies und Redirects
• Edge-Caching-Logik

Ein Wechsel zu Fly.io lohnt sich, wenn:

1. Laufzeit-Limits zum Problem werden

Workers haben harte Grenzen: 30 Sekunden (Paid) bzw. 10ms CPU-Zeit (Free). Für Aufgaben wie:

• Komplexe Datenverarbeitung
• PDF-Generierung
• Video-/Bild-Manipulation
• Lange API-Chains

reicht das oft nicht. Fly Machines haben keine solchen Limits.

2. Du echten State brauchst

Durable Objects und KV sind clever, aber limitiert. Wenn du brauchst:

• Relationale Datenbanken (Postgres, MySQL)
• Redis mit voller Feature-Palette
• Persistente Dateisysteme
• WebSocket-Connections mit Server-State

ist Fly.io die natürlichere Wahl.

3. DSGVO-Kontrolle wichtig ist

Bei Workers fließt jeder Request durch Cloudflares globales Netz. Bei Fly.io bestimmst du exakt:

• In welchen Regionen deine App läuft
• Wo Daten gespeichert werden
• Welche Logs wohin gehen

4. Du Docker-basierte Toolchains hast

Bestehende Container-Images, CI/CD-Pipelines mit Docker, oder Teams die mit Containern vertraut sind – all das passt besser zu Fly.io als zum Workers-Modell.

Von Cloudflare Workers zu Fly.io: Die Umstellung

Cloudflare Workers folgen einem simplen Modell:

export default {
  async fetch(request) {
    return new Response("Hello from Edge!");
  }
}

Kein Server, kein Port, kein Prozess – nur eine Funktion, die Requests beantwortet.

Fly.io dagegen erwartet einen Server-Prozess, der auf einem Port lauscht.

Schritt 1: Worker-Logik extrahieren

Nimm deinen Worker-Code und identifiziere:

• Routing: welche URLs tun was?
• Business-Logik: z. B. API, Auth, Transformations
• externe Zugriffe: APIs, Datenbanken, KV-Stores, Durable Objects

Diese Logik überführst du in einen Web-Server, z. B. mit Express oder Hono.

Beispiel: Worker → Express-Server

Worker:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === "/health") {
      return new Response("ok");
    }

    return new Response("Hello from Edge!");
  }
}

Fly/Express-Version:

// index.js
import express from "express";

const app = express();

app.get("/health", (req, res) => {
  res.send("ok");
});

app.get("/", (req, res) => {
  res.send("Hello from Fly Edge!");
});

app.listen(8080, () => {
  console.log("Server listening on port 8080");
});

Port 8080 ist der Standard bei Fly.io.

Schritt 2: Dockerfile erstellen

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 8080

CMD ["node", "index.js"]

• Image baut deine App
• Startet den Server auf Port 8080
• Keine Worker-Laufzeit mehr, sondern ein ganz normaler Node-Prozess

Schritt 3: Fly-App anlegen & konfigurieren

fly launch --no-deploy

Fly erstellt eine fly.toml. Dort definierst du u. a.:

app = "my-edge-app"
primary_region = "fra"

[build]
  dockerfile = "Dockerfile"

[[services]]
  internal_port = 8080
  protocol = "tcp"

  [[services.ports]]
    port = 80
    handlers = ["http"]

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

Dann:

fly deploy

Damit startet Fly Machines deiner App in der gewählten Region (z. B. Frankfurt).

State & Datenbanken

Was vorher vielleicht in Durable Objects, D1 oder externen Services hing, braucht unter Fly eine neue Heimat:

• Postgres auf Fly für relationale Daten
• Redis für Caches/Queues
• Volumes + SQLite/LiteFS für leichtgewichtige verteilte Daten

Vorteil: Du kannst Daten bewusst in EU-Regionen halten und replizieren – wichtig für Datenschutz-Strategien.

Postgres auf Fly einrichten

# Postgres-Cluster erstellen
fly postgres create --name my-db --region fra

# Mit App verbinden
fly postgres attach my-db

Fly setzt automatisch die DATABASE_URL Environment Variable.

Redis auf Fly

fly redis create --name my-cache --region fra

DSGVO-Aspekte

Im Vergleich zu Workers:

• Bei Cloudflare Workers laufen alle Requests durch Cloudflare (Proxy) – inklusive IPs, Cookies, Inhalte.
• Bei Fly.io bestimmst du granular:
  • welche Daten deine App speichert
  • wo diese Daten liegen (Regionen)
  • welche Logs du aufbewahrst

Rechtlich bleiben es US-Anbieter, aber das technische Profil ist anders:

• Workers = Proxy + Compute-Layer
• Fly = Hoster deiner Workloads

Das hilft bei einer Transfer-Risikoabwägung, weil du die Architektur sehr konkret beschreiben kannst.

Monitoring & Betrieb

• Logs: fly logs oder UI
• Metriken: im Fly-Dashboard
• Rolling Deployments: mit fly deploy
• Scaling & Regions-Änderungen: komplett über flyctl

Damit bist du näher an klassischem „Ops”, aber mit Edge-Komfort.

Health Checks

[[services.http_checks]]
  interval = 10000
  grace_period = "5s"
  method = "get"
  path = "/health"
  protocol = "http"
  timeout = 2000

Fly prüft regelmäßig, ob deine App antwortet und routet Traffic nur zu gesunden Instanzen.

Typische Stolpersteine

1. Zu viel Worker-Magie erwartet

Auf Fly musst du selbst:

• einen Server starten
• Routing definieren
• ggf. eigenes Caching bauen (oder CDN davor schalten)

2. Timeouts & Ressourcen falsch dimensioniert

Nicht einfach alles minimal lassen:

• plane genügend RAM für DB-Clients, Runtime & Caching ein
• überprüfe Timeouts bei externen APIs

3. Datenflüsse unterschätzen

Wenn DSGVO wichtig ist:

• Regionen bewusst wählen (z. B. fra, cdg)
• Replikation in Nicht-EU-Regionen abschalten, wenn nicht nötig
• Logs und Metriken in der Datenschutzdokumentation berücksichtigen

Exkurs: Ähnliche Setups bei Hetzner und IONOS

Fly.io ist nicht die einzige Option für Container-Hosting in Europa. Deutsche Anbieter wie Hetzner und IONOS bieten ebenfalls interessante Alternativen.

Hetzner Cloud

Hetzner ist bekannt für extrem günstiges, leistungsstarkes Hosting mit Rechenzentren in Deutschland und Finnland.

Was geht:

• Cloud Server (VPS): Ab ~4€/Monat für 2 vCPU, 4 GB RAM
• Docker/Kubernetes: Manuell oder via k3s/Docker Swarm
• Hetzner Cloud API: Automatisierung und Skalierung möglich
• Load Balancer: Für Hochverfügbarkeit

Was fehlt:

• Kein Anycast-Routing – du brauchst eigenes Geo-DNS oder einen CDN davor
• Kein automatisches Multi-Region – manuelles Setup erforderlich
• Keine „Scale to Zero”-Funktionalität
• Mehr Ops-Aufwand: Updates, Security, Monitoring selbst managen

Typischer Einsatz: Kostenbewusste Projekte mit EU-Fokus, bei denen ein oder zwei Standorte reichen und das Team Ops-Erfahrung hat.

IONOS (Cloud Cubes / Managed Kubernetes)

IONOS bietet sowohl einfache Container-Lösungen als auch Managed Kubernetes.

Was geht:

• Cloud Cubes: Einfache Container-Instanzen, schnell deployed
• Managed Kubernetes: Vollständiges K8s ohne Cluster-Management
• Deutsche Rechenzentren: Berlin, Frankfurt, Karlsruhe
• DSGVO-Konformität: Deutsches Unternehmen, EU-Daten bleiben in der EU

Was fehlt:

• Kein globales Edge-Netzwerk – primär Deutschland/EU
• Weniger Developer Experience als Fly.io (mehr Enterprise-fokussiert)
• Kubernetes-Komplexität bei Managed K8s

Typischer Einsatz: Unternehmen mit strikten Compliance-Anforderungen, die einen deutschen Anbieter bevorzugen.

Vergleich: Fly.io vs. Hetzner vs. IONOS

Aspekt	Fly.io	Hetzner	IONOS
Edge/Global	30+ Regionen, Anycast	2 Regionen, kein Anycast	EU-fokussiert
Scale to Zero	Ja	Nein	Nein
Managed DB	Postgres, Redis	Nein (DIY)	Managed DBaaS
Preis (Einstieg)	~5$/Monat	~4€/Monat	~5€/Monat
Ops-Aufwand	Niedrig	Hoch	Mittel
DSGVO	US-Firma, EU-Regionen	DE-Firma	DE-Firma
Best für	Globale Apps, DX	Budget, EU-only	Enterprise, Compliance

Wann welcher Anbieter?

• Fly.io: Wenn du globale Verteilung, niedrigen Ops-Aufwand und moderne DX willst
• Hetzner: Wenn Budget wichtig ist, EU reicht und du Ops-Kompetenz hast
• IONOS: Wenn du einen deutschen Anbieter mit Enterprise-Support brauchst

Alle drei können Docker-Container hosten. Der Unterschied liegt im Drumherum: Networking, Skalierung, Developer Experience und Compliance-Story.

Zusammenfassung

Cloudflare Workers sind super für leichte, stateless Edge-Tasks. Sobald du aber:

• mehr State brauchst
• längere Laufzeiten
• komplexere Workloads mit DB, WebSockets & Co.
• oder gezielte EU-Regionen-Kontrolle

wird Fly.io zur logischen nächsten Stufe.

Für rein europäische Projekte mit weniger globalen Anforderungen können Hetzner oder IONOS eine kosteneffiziente Alternative sein – mit dem Trade-off von mehr Eigenverantwortung beim Betrieb.

Weiterführende Ressourcen

• Fly.io Documentation
• Fly.io Machines
• Fly.io Postgres
• flyctl Reference
• Hetzner Cloud
• IONOS Cloud
• Hono Framework – leichtgewichtiger als Express, ideal für Edge