Fly.io EU Alternative 2026: CLOUD Act 16/25 — What Edge Containers Mean for GDPR

Post #2 in the sota.io EU Serverless & PaaS Series

Fly.io built something genuinely impressive: a global container platform where your app runs in Firecracker micro-VMs close to your users, with anycast routing and instant scale-to-zero. For developer experience, it's among the best platforms available in 2026. For GDPR compliance, it's a US-jurisdiction platform — and that gap matters in ways that Fly.io's documentation doesn't make obvious.

This post gives EU startups, scale-ups, and compliance teams the complete picture: CLOUD Act exposure analysis, GDPR Article 28 implications, technical architecture review, and a clear comparison of EU-native alternatives.

Fly.io Corporate Structure

Fly.io Inc. is incorporated in Delaware, United States. Founded in 2017 by Kurt Mackey and Jerome Gravel-Niquet, the company is headquartered in San Francisco and operates as a private venture-backed company. As of 2026, Fly.io has raised significant funding but remains privately held with no European parent entity or EU subsidiary.

This matters because the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. §2713) applies to all US-incorporated entities regardless of where their servers are located. A Delaware corporation operating servers in Frankfurt is still a Delaware corporation subject to US compulsion orders.

CLOUD Act Score: 16/25

We rate Fly.io at 16 out of 25 on our CLOUD Act risk scale, where 0 = pure EU jurisdiction (no US exposure) and 25 = maximum US jurisdiction (PRISM-tier government contractor).

Total: 16/25 — Meaningfully lower than hyperscalers (AWS 21/25, Azure 21/25, GKE 20/25) and lower than Netlify (18/25) because Fly.io runs its own compute infrastructure rather than routing through PRISM-participating cloud providers. However, the US jurisdiction floor is still present and non-negotiable.

Why 16/25 and Not Lower

Fly.io is often described by developers as a "cool indie" platform, which creates a perception of lower compliance risk. The CLOUD Act doesn't grade on perceived size or attitude. Section 2713 applies to any electronic communications service or remote computing service provider incorporated or headquartered in the United States — Fly.io qualifies on both counts.

The 2 points below DigitalOcean (17/25) and 5 points below AWS (21/25) reflect:

• No known intelligence community partnerships or government contractor status
• No PRISM-equivalent program participation discovered in public records
• Own compute infrastructure rather than AWS/GCP (which have additional IC exposure through their own government cloud divisions)

The 16/25 score does not reflect lower CLOUD Act applicability — it reflects lower additional exposure beyond the baseline Delaware corporation floor.

GDPR Implications

Article 28 — Data Processing Agreement

Using Fly.io as a processor for EU personal data requires a GDPR-compliant Data Processing Agreement. Fly.io provides a DPA, but the DPA cannot override the legal reality that a US court order under the CLOUD Act supersedes contractual protections.

The conflict: GDPR Article 28(3) requires processors to "process the personal data only on documented instructions from the controller." The CLOUD Act allows US authorities to compel data disclosure without the controller's knowledge or consent. A Fly.io DPA cannot simultaneously guarantee both.

Article 46 — Transfers to Third Countries

If your Fly.io region is within the EU (ams, fra, cdg), your data at rest may be in the EU. But Fly.io Inc. as the US entity can be compelled to produce that data under US law. This means you're running into the Schrems II problem: EU Standard Contractual Clauses (SCCs) alone don't protect against CLOUD Act compulsion.

EDPB Guidance (2021): Transfer Impact Assessments (TIAs) must evaluate whether the legal framework of the importer country protects data equivalently to EU law. For US-based processors, TIAs consistently reveal the CLOUD Act gap — and EU Data Protection Authorities have found SCCs insufficient without supplementary measures that are often technically impossible to implement (full end-to-end encryption where the processor has no access to keys).

Article 44 — General Principle for Transfers

Even if you choose an EU region on Fly.io, the controller-to-processor relationship itself constitutes a data transfer to a US entity under GDPR Article 44 analysis. The European Data Protection Board confirmed this interpretation in Guidelines 05/2021.

Fly.io Technical Architecture

Understanding Fly.io's architecture helps assess the actual data flow:

Compute: Fly.io Machines run as Firecracker micro-VMs on Fly.io's own bare-metal servers. This is genuinely differentiated from AWS/GCP/Azure — Fly.io does not run your containers on hyperscaler infrastructure. The physical servers in Fly.io's EU regions (ams = Amsterdam, fra = Frankfurt, cdg = Paris, arn = Stockholm, lhr = London, lax, ord, iad, etc.) are leased data center space running Fly.io's own hypervisor stack.

Networking: Fly.io uses WireGuard for its private networking mesh (6PN — Fly's private networking). Anycast routing means a request from Paris to your Fly.io app may get routed to the Frankfurt region. Control plane metadata (Fly.io API, machine lifecycle, configuration) is managed from Fly.io's US-operated systems.

Storage — Tigris: Fly.io launched Tigris as their S3-compatible object storage. Tigris Object Storage, Inc. is a US-incorporated company (Delaware). Tigris is built on top of multiple backend providers including Cloudflare R2. EU data stored in Tigris is subject to Tigris's own US jurisdiction and CLOUD Act exposure.

Secrets and environment variables are managed through Fly.io's US-operated API. When you run fly secrets set DATABASE_URL=..., that secret goes through Fly.io's control plane infrastructure in the US before being injected into your VM.

Build pipeline: Fly.io builds Docker images via flyctl deploy. Build processes may run in Fly.io's US infrastructure depending on configuration.

What "EU Region" Actually Means on Fly.io

Choosing --region fra (Frankfurt) on Fly.io means:

• ✅ Your VM runs on bare-metal in Frankfurt
• ✅ Your data at rest is in the EU geographically
• ❌ Your control plane metadata is US-managed
• ❌ Tigris storage (if used) is a US entity
• ❌ Fly.io Inc. as your processor is a US Delaware corporation
• ❌ CLOUD Act §2713 allows US DOJ to compel data access

The EU region doesn't create EU jurisdiction — it creates EU geography with US jurisdiction overlay.

EU-Native Alternatives to Fly.io

For teams that require genuine EU jurisdiction (CLOUD Act score 0-4/25), the following platforms provide comparable developer experience without US corporate exposure:

Scalingo — CLOUD Act 0/25

Scalingo SAS (3DS OUTSCALE / Iliad group): French SAS corporation, wholly owned by French entities. No US parent, no US subsidiary, no CLOUD Act exposure.

• Architecture: Heroku-compatible buildpack deployment + Docker support
• Regions: Paris (France), Osc-fr1 (outscale DC)
• Comparable to Fly.io: Buildpacks, container deployments, PostgreSQL managed add-on
• GDPR: Article 28 DPA covers genuine EU processor with no CLOUD Act override risk
• Pricing: €0.02/container-hour (comparable to Fly.io)
• DX difference: No equivalent to Fly.io Machines (ephemeral VMs), no global edge; but full French jurisdiction

Koyeb — CLOUD Act 1/25

Koyeb SAS (Paris): French SAS, primarily EU-operated, minimal US exposure (1/25 for some Cloudflare CDN usage in control plane).

• Architecture: Serverless container deployment, global regions including Paris, Frankfurt
• Comparable to Fly.io: Fast deployments, container-native, built-in global routing
• Standout: Koyeb has the closest developer experience to Fly.io of any EU-native platform — fast cold starts, anycast-style routing, container-first
• GDPR: Koyeb DPA covers EU processor jurisdiction
• Pricing: Free tier available, competitive with Fly.io for small workloads

Northflank — CLOUD Act 3/25

Northflank Ltd (UK): UK company (Brexit creates some nuance for post-adequacy-decision era). UK GDPR applies. Northflank operates Kubernetes-based container deployments.

• Architecture: Multi-cloud (bring your own cloud) or Northflank-managed, full Kubernetes orchestration
• Comparable to Fly.io: Container deployments, preview environments, CI/CD integration
• Standout: More enterprise-grade than Fly.io — multi-region, team permissions, environment management
• GDPR: UK data adequacy decision in place; UK GDPR aligned with EU GDPR through 2026 (review pending)
• Pricing: Starts higher than Fly.io; enterprise tier available

sota.io — CLOUD Act 0/25

sota.io (EU-native managed PaaS): EU-incorporated, hosted on Hetzner Germany (German Aktiengesellschaft, no US parent, no CLOUD Act exposure). Built specifically for EU developers who need genuine GDPR compliance without sacrificing deployment ergonomics.

• Architecture: Git-push or Docker deployment, EU-only infrastructure
• Comparable to Fly.io: Simple deployment workflow, managed PostgreSQL, automatic SSL
• Standout: Explicit EU compliance documentation, 0/25 CLOUD Act score, Hetzner infrastructure
• GDPR: Pure EU processor chain — sota.io + Hetzner, both EU entities

CLOUD Act Score Comparison

Migrating from Fly.io to an EU-Native Platform

Step 1: Assess Your Compliance Requirements

Before migrating, determine your actual risk profile:

• What personal data do you process? Health, financial, children's data = highest GDPR risk
• Which DPAs are active? French CNIL, German BfDI, and Dutch AP are the strictest on third-country transfers
• Do you have EU enterprise clients? B2B contracts often require EU data residency clauses

Step 2: Inventory Fly.io Services in Use

Common Fly.io features and their migration path:

Step 3: Update Your DPA Chain

When you switch to Koyeb or Scalingo:

1. Request the new processor's DPA
2. Update your own privacy policy to reflect the new processor chain
3. Update your ROPA (Records of Processing Activities) under GDPR Article 30
4. Notify your DPO if applicable

Step 4: Migrate and Validate

Most Fly.io applications use standard Docker containers. The migration path to Koyeb or Scalingo is typically:

1. Push existing Dockerfile to new platform
2. Set equivalent environment variables
3. Migrate database (pg_dump → pg_restore for PostgreSQL)
4. Update DNS
5. Validate end-to-end with monitoring

Who Should Stay on Fly.io

Fly.io is an excellent platform for:

• Non-EU-personal-data applications (open data, public APIs, tools without user accounts)
• Development and staging environments where GDPR compliance requirements are relaxed
• Global performance-first applications where Fly.io's edge network provides genuine latency advantages
• Teams in US/CA/AU who don't process EU personal data and don't need EU compliance
• EU teams with DORA/NIS2 exposure where US jurisdiction risk is accepted after proper TIA documentation

The developer experience on Fly.io — flyctl deploy, instant rollbacks, Firecracker speed, the Machines API — is genuinely excellent. The compliance trade-off is real but manageable if your threat model allows US-jurisdiction processors with EU geographic servers.

Decision Framework

Choose Fly.io if:

• Your data isn't EU personal data under GDPR
• You've completed a GDPR Transfer Impact Assessment and accepted the CLOUD Act residual risk
• You need global edge performance that EU-native platforms can't match
• Development/staging workloads only

Choose Koyeb if:

• You want the closest Fly.io DX with EU jurisdiction
• You need fast container deployments with EU compliance
• You process EU personal data and can't accept CLOUD Act residual risk

Choose Scalingo if:

• You need full French/EU jurisdiction (strictest GDPR interpretation)
• Your French or German clients require EU data processor documentation
• Heroku-compatible buildpack deployment fits your stack

Choose sota.io if:

• You want a managed EU PaaS with zero CLOUD Act exposure and simple deployment
• You're building EU-first products and want the hosting to match

Summary

Fly.io scores 16/25 on the CLOUD Act scale — meaningfully better than AWS, Azure, and Google Cloud, but still a US-jurisdiction platform under CLOUD Act §2713. EU teams processing sensitive personal data (health, financial, biometric) under strict DPA interpretation should evaluate the gap between Fly.io's EU regions and genuine EU processor jurisdiction.

For developers who need Fly.io's edge deployment model with EU compliance, Koyeb offers the closest equivalent at 1/25. For strictest GDPR compliance, Scalingo (0/25) and sota.io (0/25) provide pure EU processor chains.

See Also

• Netlify EU Alternative 2026 — JAMstack PaaS with similar US-jurisdiction exposure (18/25), same series
• Heroku EU Alternative 2026 — Salesforce-owned PaaS with highest CLOUD Act risk (22/25) in the series
• Railway EU Alternative 2026 — Another US-incorporated developer PaaS with comparable GDPR implications
• EU Serverless PaaS Comparison 2026 — Full risk matrix comparing all four platforms side by side

The CLOUD Act doesn't punish small platforms differently from large ones. A Delaware incorporation is a Delaware incorporation — and that's the starting point for any compliant EU data processing decision.