Is Fly.io's European region enough for EU data residency?
For many regulated teams, no. A European region is a necessary step for EU data residency on Fly.io, but it does not settle the question on its own. Residency depends on three separate questions. The first is placement: where app data, volumes and database replicas are stored and processed. The second is processor location: where the provider's operators and support staff can reach that data. The third is third-country access: whether a non-EU legal authority can compel disclosure of data the provider holds. Under EDPB Guidelines 05/2021, storage outside the EEA and remote access from a third country both count as transfers, so placement and access interact. Self-hosted Coolify or Dokku lets the operator choose the EU servers, control who holds SSH and admin access, and keep the control plane on infrastructure the operator runs.
Third-country access needs its own review, because a region choice does not address it. The EDPB's Recommendations 01/2020 state that where a provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. The US CLOUD Act provision at 18 U.S.C. 2713 requires covered providers to preserve or disclose data in their possession, custody or control, wherever it is located. The EDPB's Example 12 adds that using an EU processor subject to third-country law is not a transfer in itself, but complying with a third-country request would be, so controllers should assess that exposure before engaging the processor. If your transfer analysis relies on the Data Privacy Framework, note that its adequacy decision is under appeal in Case C-703/25 P.
What EU data residency actually requires
EU data residency is not only a question of which region an app runs in. Transfer rules, remote access, third-country legal reach and switching rights all shape where personal and non-personal data can sit and who can reach it. Check each card against your own data map before choosing a hosting location.
Transfer conditions under Article 44
Every transfer of personal data to a third country must meet Chapter V conditions, including onward transfers made by your processors and their subprocessors. Article 83(5)(c) sets fines for infringements of Articles 44 to 49 of up to EUR 20 million or 4% of worldwide annual turnover. For hosting, map every location where personal data is stored, processed or backed up, not only the primary region your app runs in.
Remote access and storage count
EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when a support engineer only views data on a screen. Storage in a cloud outside the EEA is also a transfer. Ask your vendor and any support contractor where administrators sign in from, and whether backups, logs or snapshots are copied outside the EEA, because each of these can bring data into scope.
Third-country legal reach
An EU-based processor can still be exposed to third-country law with extraterritorial effect. Under Article 48, a foreign court order is recognized in the EU only if it rests on an international agreement, and EDPB Recommendations 01/2020 state that where a provider must access data in the clear and foreign powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Confirm which legal jurisdictions your provider and its parent companies answer to, and document that assessment before signing.
Data Act switching and access rules
The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Article 32 requires providers to prevent third-country governmental access to non-personal data held in the Union where that conflicts with EU or national law. Write these switching terms into your contract so that moving off a managed platform stays a planned exit, not a renegotiation.
Where Fly.io's European regions meet the constraint and where they do not
Placing a Machine or volume in one of Fly.io's five European regions fixes where those resources are stored, but storage is only one place personal data can sit. Under EDPB Guidelines 05/2021, remote access from a third country is a transfer even when someone only views data on a screen for support, and so is storage in a cloud outside the EEA. An EU volume can therefore still generate a transfer if support staff in another country open a session, if logs or metrics are exported to a non-EU service, if backups are replicated outside the EU, or if the control plane processes account data elsewhere. Map each of these flows before you rely on the region choice.
The supplied material does not establish Fly.io's sub-processor list, support access practices, log retention, backup locations or control plane location, so the reader must obtain them directly. Ask for the data processing agreement, the current sub-processor list with processing locations, the written support access procedure (including whether engineers outside the EEA can reach customer data), and the locations of logs and backups. Ask whether the vendor can provide a transfer impact assessment and which transfer mechanism covers each non-EU flow. Base the decision on these written answers, not on the region list alone.
Jurisdiction is the second question. The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether it sits inside or outside the United States. If a processor in the chain is US-headquartered, an EU region does not remove that reach. EDPB Recommendations 01/2020 state that where a provider needs data in the clear and the destination's authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Running Coolify or Dokku on EU infrastructure you select keeps the application and data under your own control, though you still need to assess your infrastructure provider's own access and jurisdiction terms.
Which self-hosted options keep apps and data in EU infrastructure
Coolify is the option most teams reach for when they want a control panel over several servers. It is licensed under Apache-2.0, and you install it on a Linux host in an EU data center or cloud region you select. It connects to each server over SSH, prepares that server to run Docker workloads, and deploys apps from a Git repository, Dockerfile, Docker Compose file or prebuilt image. Because the servers are yours, the EU location of application containers, volumes and databases is a decision you make and document.
- Server model: Coolify manages servers you bring over SSH, so each server's region is the one you pick. Coolify Cloud, which runs the Coolify instance on Coolify's own infrastructure, is a separate choice that you should review against your residency requirement before using it.
- Proxy and TLS: Each server runs one coolify-proxy container. Traefik is the default and Caddy is the alternative, and both handle HTTPS automatically. The Custom (None) option leaves routing and certificates to your team.
- Database backups: PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse support scheduled backups to S3-compatible storage. Confirm that the bucket is in the EU, because backup copies also count as personal data.
- Gaps: Redis, Dragonfly and KeyDB are deployable but are not covered by scheduled backups, so plan their recovery separately.
- Multi-server limits: Multi-server support is a Coolify model, not a cluster. Check the multi-server documentation for how placement and failover behave before you rely on it for EU-only failover.
Confirm the server region, the proxy choice and the backup bucket location in writing before the first production deploy.
Dokku is an MIT-licensed, Heroku-style PaaS that runs on a single server. Its default docker-local scheduler runs containers directly on that host, so the whole application stack stays in one EU machine that you control. Deploys happen with git push to a dokku remote, which creates the app on the fly. This model fits teams that want a small, auditable footprint and a single location for code, runtime and data.
- Build options: Dokku builds with the herokuish builder, Cloud Native Buildpacks through the pack CLI, a Dockerfile, or Nixpacks and Railpack when a nixpacks.toml or railpack.json file is present. Cloud Native Buildpacks needs the pack CLI installed separately.
- Process model: The Procfile is read under strict rules, the web process scales to 1 on the first deploy, and a release process type works like the Heroku Release Phase.
- Datastores: Dokku provides no datastores by default. The official dokku-postgres plugin installs PostgreSQL and runs one-off or scheduled backups to S3-compatible storage, which you should place in the EU.
- Single-server limit: The git push target is the initial Dokku server only, and the default scheduler does not span hosts. A single-server failure takes the apps down until you restore them elsewhere.
- Version status: Dokku is still versioned 0.x, so plan upgrades and test them in a staging host first.
Confirm the server region, the backup bucket location and your own recovery steps before you treat the single host as the residency boundary.
Dokku's k3s scheduler, introduced in Dokku 0.33.0, builds a multi-server K3s cluster so that workloads can run on more than one host. It is the option for teams that need several EU nodes but want to keep the Dokku deployment workflow. The trade-offs are operational: it adds a cluster to run and it changes how images move between hosts.
- Registry requirement: The k3s scheduler requires a Docker registry. Host the registry in the same EU boundary, because container images can contain personal data or secrets.
- Git target: Only the initial Dokku server is configured as the git push target, so other nodes are not deploy entry points.
- Cluster skills: Your team needs Kubernetes operations knowledge for node health, upgrades and networking. Confirm who owns that work after go-live.
- Placement: Confirm in the documentation how the scheduler places workloads and whether it can pin apps to EU nodes only.
- Scope: The k3s model is the closest Dokku gets to multi-region-style placement, but it is not a managed multi-region service.
Before choosing this path, ask for a tested failover plan, a documented registry location and a list of the nodes that will hold personal data.
How to deploy Coolify or Dokku in an EU region you choose
This sequence takes you from a written processor chain to a tested, EU-hosted Coolify or Dokku environment with documented access, proxy and backup paths. Each step ends with a check you can show an auditor or data protection lead.
Confirm the processor and sub-processor chain
Before any server is ordered, the controller's legal or privacy lead asks the hosting provider, and each sub-processor, to state in writing where data is stored, where it is processed and who can access it remotely. Include backup storage, DNS, email and any support tooling. Under EDPB Guidelines 05/2021, remote access from a third country, even only viewing data on screen, counts as a transfer, so support access paths belong in this review. The step is done when the written list names every location and every access route, and the controller has signed off on it.
Choose the EU provider and data centers
Select a provider whose contracted data center locations are inside the EEA for every component that holds personal data: application hosts, databases, object storage and backups. Ask whether the provider is subject to non-EU laws with extraterritorial reach, such as the US CLOUD Act at 18 U.S.C. 2713, and record the assessment the EDPB describes in Example 12 of its guidelines. Coolify Cloud is a separate option only if its managed control plane location meets your residency requirement, which you should confirm with Coolify directly. The step is done when the region, provider and legal exposure are recorded in your data processing register.
Provision Linux hosts for the chosen runtime
Your infrastructure team creates the servers in the chosen EU region. For Coolify, each host needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, running a supported Linux distribution on amd64 or arm64. For Dokku, the documented minimum is 1 GB RAM for the default Docker scheduler, on Ubuntu 22.04, 24.04 or 26.04, or Debian 11 or later. Size above these minimums for your real workload and database, which the vendor minimums do not account for. The step is done when each host passes an OS and resource check and the install script completes.
Restrict SSH and firewall access
Coolify connects to each server over SSH, so the platform's access path must be locked down before applications go live. Your security engineer limits SSH to named administrator networks or a bastion, disables password logins, uses key-based access for the Coolify or Dokku user, and opens only the ports the platform needs for web traffic and management. Record who holds keys and how they are revoked. The step is done when an external port scan shows only the intended ports and a key-holder list is on file.
Configure the reverse proxy, TLS and wildcard DNS
Choose the reverse proxy deliberately: Coolify runs Traefik by default, with Caddy as an alternative, and both handle HTTPS automatically, while the Custom (None) option leaves routing and certificates to your team. Dokku ships nginx by default, with Caddy, HAProxy, OpenResty and Traefik as alternatives. If you use Coolify preview deployments, create the wildcard DNS record that its default {{pr_id}}.{{domain}} URL needs, and confirm that preview hostnames resolve only inside the EU hosts. The step is done when a test application serves over HTTPS with a valid certificate from the EU host.
Point S3-compatible backups at an EU bucket
Create an object storage bucket in an EU region, or on an EU-operated S3-compatible service, and configure Coolify's scheduled PostgreSQL, MySQL, MariaDB, MongoDB or ClickHouse backups to upload there, or set up the dokku-postgres plugin's S3-compatible backups for Dokku. Set retention by count, days or size according to your policy. Note that Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB, so those datastores need a separate plan. Confirm the bucket's location and access policy in writing. The step is done when a scheduled backup file appears in the EU bucket.
Test restores before go-live
Coolify's guide for teams leaving managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so recovery is your responsibility. Restore a backup into a separate test database using Coolify's Import Backup or the dokku-postgres import command, then run the application against it and time how long the restore takes. Repeat this after each platform upgrade. The step is done when a documented restore has completed successfully and the result is recorded with the date and the person who ran it.
Document the remote support access path
Write down every route by which a person or vendor can reach the environment for support, including the account, the network path, the location of the person at the time, and the approval step. If the vendor is outside the EEA, any screen view or remote session is a transfer under the EDPB guidance, so either restrict it to in-EEA staff or cover it in the transfer assessment and contract. Keep this record with the processor chain from the first step. The step is done when the document is approved by the controller and linked from the platform's runbook.
What multi-region placement you give up
Moving to Coolify or Dokku means you give up Fly.io's automatic regional placement. A Fly.io app can run Machines in several of its regions and route users to nearby capacity without you managing servers in each one. With self-hosting, each server you add is a machine you chose, placed and patched yourself. Coolify connects to each server over SSH and deploys to it through its multi-server deployment feature, so you decide which servers belong to which region and which applications run on which servers. Dokku, by its own documentation, runs on a single server, and its k3s scheduler builds a multi-server K3s cluster but requires a Docker registry, with only the initial Dokku server configured as the git push target. Confirm with the vendor whether that single push target is acceptable for your deployment workflow before you design around it.
Failover, latency and capacity are now your responsibility. Traffic steering between regions, health-based removal of a failed server, and load balancing across servers are not features you can assume from either tool, so confirm each one in the current documentation or plan to build it with DNS, an external load balancer or your cloud provider's services. Capacity planning also moves to your team, since no platform adds Machines in a region when demand rises. Check the Coolify minimums (2 CPU cores, 2 GB RAM and 10 GB of free disk per server) and the Dokku minimum of 1 GB RAM for the default Docker scheduler when sizing each node.
Recovery design is the hardest part to hand over. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. Your team must therefore define backup schedules, off-region copies and restore tests for every database and volume, including the S3-compatible backups that Coolify and the dokku-postgres plugin support. Treat any recovery target you have not restored from as unproven, and document the recovery time and data loss your business accepts before the migration starts.
Evidence auditors and regulators ask for under this constraint
What records should show where personal data is processed and stored?
A processing location register lists every server, datastore, backup target, log store and support tool that holds or can reach personal data, with the city, country and operator for each. Under the GDPR, the record of processing activities should name the locations and any third countries involved, so the register and that record must agree. Keep it current: each new Coolify server, Dokku host, plugin or S3-compatible backup bucket is a new entry. Confirm with your data protection officer which fields your record template requires, and have the register reviewed whenever infrastructure changes.
How do you document transfer assessments for third-country exposure?
A transfer assessment records whether any access, storage or support path crosses outside the EU, and if it does, which transfer tool and supplementary measures apply. The EDPB Guidelines 05/2021 treat remote access from a third country, even only viewing data on a screen, and storage in a cloud outside the EEA as transfers, so include support vendors and monitoring services in the review. For each provider subject to third-country law, document the exposure to government access requests and the controller's assessment before engaging it, as the same guidelines suggest. Ask your legal team to confirm the assessment method and the standard contractual clauses in use.
What should a sub-processor list contain for a self-hosted stack?
A sub-processor list names each external party that processes personal data for you, its role, its processing location and its contract basis. In a self-hosted stack the list is often shorter than with a managed platform, but it is not empty: the server or colocation provider, the object storage vendor for backups, the DNS and certificate authority, the email provider for alerts, and any managed Coolify Cloud control plane if you use it. Each entry should link to the signed terms that cover it. Confirm the list with each vendor, because contracts change over time.
How do you document remote access paths to production servers?
Auditors expect a written map of every way a person or system can reach production data, including SSH, the Coolify or Dokku administration interface, database consoles, and support tunnels. Record the source location of each access path, the authentication method, the role allowed to use it and the logging that captures it. Remote access from a third country counts as a transfer under EDPB guidance, so note whether any operator, contractor or vendor reaches systems from outside the EU. Review the map after each change to bastions, VPN settings or firewall rules.
What backup location and restore test records do auditors ask for?
Auditors look for three things: where each backup is stored, how long it is kept and proof that restores work. Record the bucket or volume location, its region, its encryption and its retention settings. Coolify scheduled PostgreSQL backups can go to S3-compatible storage with retention by count, days or size, and Dokku's postgres plugin can run backups to S3-compatible storage, so confirm which datastores are covered, since Coolify excludes Redis, Dragonfly and KeyDB from scheduled backups. Keep dated restore test logs that show the restored database and the restore duration, and check that backup copies stay inside the EU.
What does an SSH key inventory and access control record include?
An SSH key inventory lists every public key authorized on each server, the person or service it belongs to, when it was added, and who approved it. Coolify connects to each server over SSH, so its key and the operator keys on the host are in scope, as are the Dokku host keys and any CI deploy keys. Keep access reviews dated, remove keys when people leave, and record which accounts hold administrator rights in the platform. Confirm how your identity provider or key management tool exports this data, because manual lists drift quickly.
What must a data switching plan under the EU Data Act contain?
The EU Data Act gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure, and it sets a maximum two-month notice period and a 30-day transition under Articles 25, 29 and 50, with switching charges banned from 12 January 2027. A switching plan records the export formats for data and configuration, the contact and notice steps, the target environment, and the test that proves the data arrived intact. For an apps stack, include the Dockerfiles or buildpack settings, environment variables stored outside the platform, and database dumps. Ask your legal team to confirm how the Act applies to each provider in your chain.
Does DeployOpen issue audit reports or attestations for this evidence?
No. DeployOpen prepares the systems, controls and evidence for a compliance assessment, including the registers, access maps, backup records and switching plans described above. Independent auditors and certification bodies issue audit reports, attestations and certifications, so the review is performed by them, not by DeployOpen. Engagements are fixed-scope, with the evidence set, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope. Ask your auditor which artifacts they need in advance so the scope reflects their request.
How DeployOpen deploys Coolify or Dokku under EU residency rules
DeployOpen plans, implements, hardens and documents self-hosted Coolify or Dokku inside your own cloud accounts, data centers or networks, so you choose where each application and database runs. Each engagement starts from a written scope that sets out which regions, data flows and transfer questions it covers.
How we scope
- Map which apps, databases, backups and support sessions touch personal data and where each one lives today.
- Record every location a Fly.io workload would move to, including backups, logs and any remote administration access.
- Agree in writing which EU regions, providers and multi-region limits the deployment will accept before work starts.
How we build
- Install Coolify or Dokku on servers in the EU infrastructure you select, with the proxy, TLS and access settings you approve.
- Configure databases, S3-compatible backups and restore tests, and confirm the Git build path for each application.
- Test deployments, rollbacks and failover assumptions, and document any workload that cannot be placed in a single region.
How we hand over
- Deliver a written record of hosting locations, data flows, access paths and the controls that support your transfer assessment.
- Provide runbooks for deploys, backup restores and server patching so your team can operate the platform.
- Give your legal and compliance staff evidence to review. DeployOpen prepares that evidence but does not issue audit reports or attestations.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Ask for a written quote based on your scope. DeployOpen does not publish a price list.
