Railway, Render, and Fly.io in Frankfurt: Are Your Apps Actually GDPR-Safe?

Your EU customers are asking about GDPR. Your legal counsel wants data processing agreements. You picked Railway, Render, or Fly.io because they offer Frankfurt or Amsterdam regions, and "EU servers" sounds like the answer. It is not.

GDPR compliance is not a geography question. It is a corporate structure question. The CLOUD Act turns "where are your servers?" into an irrelevant detail the moment a US prosecutor hands a US-incorporated company a lawful order. This guide walks through exactly what that means for each provider, what the Data Privacy Framework actually guarantees (and does not), and what a genuinely GDPR-compliant PaaS deployment looks like.

The Core Problem: Data Location vs. Data Control

The common assumption: If data is processed on servers in Frankfurt, German data protection law applies and GDPR is satisfied.

The legal reality: GDPR Article 44 prohibits transfers of personal data to third countries unless adequate safeguards are in place. The critical word is transfer, which includes scenarios where a non-EU company can access data stored in the EU — not just scenarios where data physically moves across borders.

GDPR Recital 101 and Chapter V established this principle precisely because the European Court of Justice understood that legal obligations imposed by a government on a company can compel data disclosure regardless of where the data sits.

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) makes this concrete. Under 18 U.S.C. § 2713, US providers of electronic communication services or remote computing services must preserve, backup, and disclose the contents of any record or information regardless of whether such communication, record, or other information is located within or outside the United States.

If your PaaS provider is a US company, this statute applies to all data they hold — including data on Frankfurt servers.

Railway: US-Incorporated, No EU Legal Entity

Railway Technologies, Inc. is a Delaware corporation headquartered in San Francisco, California.

Railway offers deployment to a Frankfurt region (EU West). Their privacy policy and terms of service are governed by California law and binding arbitration in San Francisco. Railway has not published a separate EU legal entity, EU-based data processor register, or a legal opinion on CLOUD Act applicability.

What this means:

• A US government agency can serve Railway Technologies, Inc. with a CLOUD Act order covering data on Frankfurt servers.
• Railway's DPA (Data Processing Agreement) is available but executed with a US entity. An EU customer signing this DPA receives contractual protections from a company that cannot block lawful US government access orders.
• The EU-US Data Privacy Framework (DPF, replacing Privacy Shield in 2023) covers personal data transferred from the EU to participating US companies. Railway participates in the DPF. However, DPF explicitly does not prevent CLOUD Act orders — it governs commercial data handling, not government surveillance.
• Schrems II risk remains: If a future ECJ challenge to DPF succeeds (similar to the original Schrems II decision in 2020), all DPF-based adequacy determinations are invalidated retroactively. Companies relying solely on DPF have no fallback.

Regulatory exposure: Any DPA you sign with Railway is executed with a US entity subject to FISA Section 702 surveillance and CLOUD Act orders. This is the same legal exposure that led the ECJ to invalidate Safe Harbor (2015) and Privacy Shield (2020).

Render: US-Incorporated, EU Region via AWS

Render Inc. is a Delaware corporation headquartered in San Francisco. Their infrastructure runs on Amazon Web Services, with EU region options including Frankfurt (eu-central-1).

This creates a layered CLOUD Act exposure:

1. Render Inc. is a US company subject to CLOUD Act.
2. Amazon Web Services, Inc. is the underlying infrastructure provider — also a US company subject to CLOUD Act.

Render's DPA designates Render Inc. as the data processor. Sub-processor relationships include AWS. Both are US entities.

What changed with Render in 2025: Render announced significant changes to its free tier in August 2025, including eliminating free persistent storage and bandwidth caps that effectively raised costs for EU-hosted deployments. This made the already-marginal GDPR compliance story less attractive: the pricing incentive that made Render's EU regions interesting to EU startups has partially eroded.

DPF status: Render participates in the EU-US DPF. The same caveats from the Railway section apply: DPF does not protect against CLOUD Act orders.

Article 28 consideration: GDPR Article 28 requires that data processors provide sufficient guarantees that they can implement appropriate technical and organizational measures to ensure processing meets GDPR requirements. A processor that is legally compelled to disclose data to a government without informing the controller cannot fully satisfy Article 28(3)(e), which requires processors to assist controllers in responding to data subject rights requests. If your data is disclosed under a CLOUD Act order with a non-disclosure provision, you cannot fulfill an Article 15 access request or Article 17 erasure request regarding that disclosed data.

Fly.io: US-Incorporated, Distributed Global Infrastructure

Fly.io, Inc. is a Delaware corporation headquartered in Chicago, Illinois. Fly.io operates infrastructure across multiple regions including Frankfurt (fra) and Amsterdam (ams).

Fly.io's architecture is distinctive: applications run on Fly's own physical hardware in colocation facilities worldwide, rather than being built on AWS or GCP. This does not change the CLOUD Act analysis, however — the question is not who owns the hardware but who the US government can compel to produce records.

Fly.io offers:

• EU deployment in Frankfurt and Amsterdam
• Low-latency networking between regions
• Reasonable pricing that has not seen the Render-style cuts

GDPR compliance status: Fly.io provides a DPA executed with Fly.io, Inc. — a US entity. Their privacy policy is governed by US law. They participate in the EU-US DPF.

The personal machine server mode: Fly's hardware independence means they are less likely to face the "we're just running on AWS/GCP and have no real data access" argument that some providers use. Fly.io staff do have administrative access to their hardware. CLOUD Act orders can therefore obtain data directly from Fly.io Inc.

What the Data Privacy Framework Actually Covers

Before examining alternatives, it is worth being precise about what the EU-US Data Privacy Framework does and does not provide.

What DPF covers:

• Voluntary commitments by participating US companies to handle EU personal data with GDPR-equivalent protections
• An adequacy decision from the European Commission (issued July 10, 2023) allowing personal data transfers to certified companies without additional safeguards
• A redress mechanism for EU individuals via the US Data Protection Review Court

What DPF does not cover:

• CLOUD Act orders to US companies
• FISA Section 702 bulk surveillance programs
• National security access by US intelligence agencies

The ECJ has twice found that US surveillance law undermines the protection of personal data transferred to US companies (Schrems I 2015, Schrems II 2020). The DPF was specifically designed to address the gaps found in Privacy Shield after Schrems II. NOYB and Max Schrems have indicated an intention to challenge the DPF in the ECJ. The challenge has not yet produced an ECJ ruling as of May 2026, but the legal risk of another invalidation is not hypothetical.

Practical implication for compliance teams: A DPF-only legal basis for transfers to Railway, Render, or Fly.io is a single point of failure. If DPF is invalidated, you need binding corporate rules, standard contractual clauses, or a transfer impact assessment showing that US surveillance law poses an acceptable risk for your specific data categories. For health data, financial data, or legally privileged content, that assessment is very difficult to pass.

Why "Frankfurt Servers" Does Not Satisfy GDPR's Chapter V

The Article 29 Working Party (now the European Data Protection Board) addressed this question directly in Opinion 01/2016 on the EU-US Privacy Shield Draft Adequacy Decision. While Privacy Shield has been replaced by DPF, the substantive legal analysis of US government access powers remains applicable.

The EDPB's transfer impact assessment guidance (Recommendations 01/2020, updated 2021) establishes a four-step process:

1. Map transfers: Does your use of Railway/Render/Fly.io constitute a transfer of personal data to a third country?
2. Identify transfer tool: What legal basis enables the transfer?
3. Assess third country law: Do US law and practice provide adequate protection?
4. Identify supplementary measures: If not, what technical, contractual, or organizational measures compensate?

For step 3, the EDPB guidance explicitly states that transfers to US cloud providers must account for FISA Section 702 and EO 12333 surveillance programs. It requires controllers to assess whether the US provider is likely to receive national security orders for the specific categories of data they process.

For B2B SaaS companies processing EU customer data, the relevant categories often include contact information, usage logs, financial records, and in some cases health or legal data. US intelligence agencies have demonstrated interest in corporate espionage and economic intelligence in addition to counter-terrorism. A transfer impact assessment for these categories requires concluding that US surveillance of B2B SaaS infrastructure poses a low probability — a conclusion that is difficult to justify given documented NSA programs.

The Technical Safeguards Gap

Railway, Render, and Fly.io do not offer encryption key management where the EU customer, rather than the US provider, controls the keys. This matters because the strongest supplementary measure for transfers to US providers is end-to-end encryption where the recipient (the US company) cannot access plaintext data and therefore cannot comply with a CLOUD Act order even if one is issued.

Comparison:

Without customer-managed encryption keys, a CLOUD Act order against Railway, Render, or Fly.io produces plaintext data — the supplementary measure does not exist.

The DPA Quality Problem

Data Processing Agreements with US providers are governed by US law. Article 28(3) requires that DPAs include specific provisions: processing only on documented instructions; confidentiality obligations; implementation of Article 32 security measures; sub-processor obligations; assistance with data subject rights; deletion or return upon termination; audit rights.

US DPAs typically include all of these provisions contractually. The enforcement problem is that US courts interpret contracts under US law, and US law permits government access that may conflict with the DPA's confidentiality provisions. A DPA term saying "we will not disclose your data without authorization" does not override a CLOUD Act order — it simply means the provider has two conflicting legal obligations and will comply with the government order while potentially breaching the DPA.

EU customers signing DPAs with Railway, Render, or Fly.io have the contractual terms but not the enforcement mechanism that makes those terms meaningful under GDPR.

What Genuine GDPR Compliance Requires

For SaaS applications processing EU personal data, a GDPR-safe PaaS deployment requires:

1. EU legal entity with EU-jurisdiction DPA Your data processor should be a company incorporated in the EU (or EEA), subject to EU law, and without a US parent company that could be compelled under CLOUD Act. The DPA should be governed by the law of an EU member state.

2. No US parent company corporate chain A German subsidiary of a US company can still be served with a CLOUD Act order targeting the parent. Legal entity structure matters only when there is genuine corporate independence — no majority ownership, no effective control by a US entity.

3. Sub-processor transparency and EU-chain auditing If your EU provider uses sub-processors, each sub-processor should also be an EU entity or have equivalent strong safeguards. A Frankfurt server running on AWS eu-central-1 is still AWS (a US company) in the sub-processor chain.

4. Technical measures for high-sensitivity data For special category data under GDPR Article 9 (health, biometric, political opinion, etc.), encryption at rest and in transit with EU-controlled keys provides a genuine supplementary measure. For most B2B SaaS data, EU corporate structure plus EU infrastructure is the practical baseline.

5. Transfer impact assessment documentation Even with a genuinely EU provider, your legal team should document the transfer impact assessment to show supervisory authority compliance. This is required under GDPR Article 46 for any international transfer mechanism, and good practice for Article 5(2) accountability even for EU-to-EU processing.

Practical Migration Considerations

If you are currently on Railway, Render, or Fly.io and need to address GDPR exposure:

Assessment first: Before migrating, determine whether your application actually processes personal data that triggers GDPR. If you only process non-personal technical data (log files without user identifiers, aggregate analytics, build artifacts), the Chapter V transfer restrictions may not apply.

Data mapping: Use the EDPB's four-step framework to map which data flows go through your PaaS and what categories are involved. This determines urgency — health data on Fly.io is higher priority than pseudonymized usage metrics on Railway.

Containerized applications: Most Railway/Render/Fly.io applications use Docker containers. Migration to a EU PaaS is typically a matter of updating deployment configuration. If your application is already containerized, the migration is primarily operational rather than code-level.

Database considerations: Your PaaS choice affects application compute. If you are using a managed database from the same provider (Render PostgreSQL, PlanetScale on Railway), that is a separate transfer to assess. EU-based managed database options (Supabase EU hosting, Neon's EU region, self-hosted PostgreSQL on EU infrastructure) exist for each category.

Choosing a GDPR-Compliant PaaS

The market for EU PaaS providers has grown substantially since 2022. Genuinely EU-incorporated options include:

Clever Cloud — French company (Clever Cloud SAS), infrastructure in Paris and Warsaw. The first major European PaaS by age. Strong GDPR compliance posture.

Scalingo — French company (Scalingo SAS), infrastructure in Paris. Good Docker support, Heroku-like workflow.

sota.io — German company, infrastructure in Germany. Developer-first deployment platform with explicit GDPR-safe positioning. Designed specifically for EU developers who need GDPR compliance without the compliance overhead.

Northflank — UK company (Northflank Ltd.). Post-Brexit UK is not in the EU, but UK GDPR provides equivalent protections and the UK has an adequacy decision from the EU. The corporate structure question still applies: a UK company with no US parent is meaningfully different from a US company with a Frankfurt region.

When evaluating any provider, the key questions are:

• Where is the legal entity incorporated? (Not: where are the servers?)
• Is there a US parent company or majority US ownership?
• Does the DPA designate an EU entity as data processor?
• Are sub-processors also EU entities?

The Compliance Cost Argument

A common objection to EU-only PaaS is that options like Railway and Fly.io have better developer experience, lower prices, or more advanced features. This argument deserves a direct answer.

The actual cost differential: Railway, Render, and Fly.io pricing for typical B2B SaaS workloads (2-4 services, moderate traffic, PostgreSQL) runs €30-80/month. EU providers like Clever Cloud and sota.io are in a comparable range. The price gap that existed in 2022 has narrowed significantly as EU providers have matured.

The developer experience gap: Railway's deployment UX and Fly.io's CLI are genuinely good. However, the gap has narrowed. If your team ships on GitHub Actions, a deployment to sota.io via Docker is mechanically identical to Fly.io — the developer experience difference is days, not weeks.

The actual compliance cost: A GDPR fine for a US-only cloud provider transfer can reach 4% of global annual turnover (GDPR Article 83). For a €5M ARR SaaS company, that is €200,000. For a Series A company, fines in this range are existential. The DPA litigation and regulatory investigation cost — even for cases that end without a fine — typically runs six figures in legal fees alone.

The break-even calculation on developer experience convenience versus compliance risk is not close for any company with EU customers and measurable revenue.

Summary

Railway, Render, and Fly.io are well-engineered platforms with genuine EU deployment options. "Frankfurt servers" is a real feature that improves latency and data residency. But it does not address the fundamental GDPR Chapter V problem: all three are US companies subject to CLOUD Act, and none offers encryption architecture that would make CLOUD Act orders non-executable.

For EU B2B SaaS companies processing personal data:

• DPF provides a current legal basis for transfers to these providers but is subject to ECJ challenge
• CLOUD Act exposure is not covered by DPF and cannot be addressed by DPA terms alone
• A transfer impact assessment for these providers requires concluding that US surveillance risk is acceptable for your specific data categories
• Genuinely EU-incorporated providers without US parents eliminate the Chapter V transfer problem entirely

The question is not whether Railway is a good platform. It is whether "the servers are in Frankfurt" is a sufficient answer when your legal counsel, a supervisory authority, or a data subject asks about GDPR compliance. In most cases, it is not.

sota.io is an EU-incorporated PaaS platform (Germany) designed for developers who need genuine GDPR compliance. Deploy your first application free →