Self-hosted Railway alternative for EU data residency

Self-hosted Railway alternative for EU data residency: the short answer

If your Railway service and its volume sit in the EU region and legal or your DPO is asking where that data physically and administratively lives, running Coolify or Dokku on servers you choose in an EU location puts placement under your control. You pick the country, the data center and the provider account, and you decide whether a volume can be moved without a cross-region migration window. Railway's single EU region is EU West in Amsterdam, so if your requirement is a different EU location, a self-hosted platform gives you that choice, while a managed platform only offers the regions it publishes. Residency is not the whole GDPR analysis, though. Under Article 44, a transfer includes more than storage: the EDPB's Guidelines 05/2021 treat remote access from a third country, even only viewing data on a screen for support, as a transfer. Your administrators, your hosting provider's staff and any vendor support engineers therefore belong in the assessment, along with backups stored outside the EEA and any telemetry or error reporting you enable. Confirm which of these reach personal data before you sign off on a location. The second exposure is third-country legal reach. The US CLOUD Act provision at 18 U.S.C. 2713 applies to providers in their possession, custody or control regardless of where the data sits, so a US-headquartered host or a US-owned platform vendor can be compelled even on EU servers. The EDPB's Recommendations 01/2020 say that where access in the clear goes beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask your legal team to map the operator and each provider in the chain before deciding.

What EU data residency actually requires of a hosting platform

Keeping data in an EU region is only part of the question. The GDPR treats remote access, storage and legal exposure to non-EU authorities as parts of the same transfer analysis, so a hosting choice has to be checked against all of them. The cards below set out what to decide and verify before moving services and databases.

Chapter V applies to every transfer

Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. This applies to the platform vendor, its subprocessors and your own staff working from outside the EEA. Start by mapping where each service, backup and log stream for personal data is processed, then list every transfer that leaves the EEA. Your data protection officer should confirm the legal basis for each one.

Remote access counts as a transfer

The EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when the person only views data on a screen for support or administration. This affects managed platform support teams, contractors and offshore on-call rotations that can open dashboards, logs or database consoles. Ask each provider where support staff sit, which access paths exist and whether they can reach production data.

Storage outside the EEA counts

Storing personal data in a cloud location outside the EEA is also a transfer under the same guidelines, which matters when a platform's control plane, container registry, object storage or log pipeline sits outside the region you chose for the application. An EU application region does not settle the question if backups go to a bucket elsewhere. Confirm the region of every component, including build caches, image registries and metrics, and write those locations into your records of processing.

Third-country disclosure orders

The US CLOUD Act at 18 U.S.C. 2713 requires covered providers to preserve or disclose data in their possession, custody or control, wherever it is stored. Under GDPR Article 48, a third-country court order can be recognized in the EU only if it rests on an international agreement, such as a mutual legal assistance treaty. EDPB Recommendations 01/2020 state that where access goes beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Assess this exposure before choosing a provider that is subject to such laws.

Transfer tools change over time

The Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, applies only to US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Earlier, the CJEU in Case C-311/18 invalidated the Privacy Shield decision in 2020. Any transfer relying on a framework should have a documented fallback, and your legal team should track the appeal before relying on it.

Self-hosting moves the control point

Running Coolify or Dokku on servers in an EU location you choose means the operator, not a managed vendor, decides where containers, volumes and backups live. The residency promise then depends on your own access controls, database backup destinations and the hosting provider's own location and staff access. Confirm the server region, the S3-compatible backup target and who holds SSH and dashboard credentials before treating the deployment as EU-resident.

Where Railway's single EU region fits and where it leaves gaps

Railway's EU option is a single region, EU West in Amsterdam, so a team that needs its services and data in the European Union can pick that region without running anything itself. That helps with where data is stored and processed. It does not, on its own, answer the questions a data protection officer will ask next: who can administer the platform from outside the EEA, whether support staff can view data on screen from a third country, and how the provider responds to a demand from a foreign authority. The EDPB treats remote access from a third country, even only displaying data for support, as a transfer, so location alone does not settle the analysis.

Moving a service with a volume from one region to another is not a configuration change. It means a migration with downtime, so a team that picks the wrong region on day one, or that later needs a second EU location for resilience, should plan a cutover window rather than assume it can switch quietly. Running a self-hosted Coolify or Dokku instance in an EU location you choose removes that constraint for the workloads you move, because the placement decision sits with your infrastructure team.

Before deciding that Railway fits, ask Railway in writing for its data processing terms, its current sub-processor list, and a description of its support access model, including which staff can reach customer environments, from where, and under what approval. None of these were covered in the material used to prepare this section, so treat any answer you receive as the baseline for your assessment. Your legal and privacy team should also check the transfer mechanisms and government access commitments in those documents against the GDPR analysis your organization already maintains.

Which open-source platform fits an EU-only deployment

Coolify is licensed under Apache-2.0 and its self-hosted edition carries no feature limits. You install its control panel on a server you choose, then connect further servers over SSH. Data placement follows the servers you rent or own, so an EU deployment means every node that runs an application, database or backup job sits in an EU location you can name in your contract. Coolify connects to each server, prepares it for Docker workloads and deploys from Git, Dockerfiles, Compose files or prebuilt images.

Placement by server: Each connected server is a place where application data, database files and container images live. Keep every node, including any build or proxy host, in the EU region you have approved.
Resource floor: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and it runs only on supported Linux distributions on amd64 or arm64. Size the control host and each workload host with headroom for builds.
Proxy choice: Each server runs a coolify-proxy container, with Traefik as the default and Caddy as the alternative. Both handle HTTPS automatically, while the Custom (None) option leaves TLS certificates to your team.
Databases and backups: PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse have scheduled backups, which can go to S3-compatible storage. Redis, Dragonfly and KeyDB do not have scheduled backups, so plan their recovery separately.
Coolify Cloud: The hosted control plane costs a monthly fee per connected server, but the instance runs on Coolify's managed infrastructure. Before you claim EU residency, confirm in writing where that managed control plane and its stored metadata are located.

Confirm the server regions, the backup target location and whether any hosted Coolify component handles your data.

How to deploy Coolify or Dokku in an EU location you choose

This sequence moves a Railway workload onto a server you place in an EU location, with the proxy, databases, backups and administrative access all controlled and documented inside that environment.

Choose the EU provider and confirm data locations
Your team selects a provider or data center in the EU and then confirms, in writing, where the servers, database backups, logs and any S3-compatible object storage will physically sit. Ask the provider where its support staff and management tooling are located, because remote access from outside the EEA can count as a transfer under EDPB Guidelines 05/2021. This step is done when you hold a written list of every location that will store or display the data. Confirm the details with the provider and your legal or privacy team, since the answers depend on your contracts.
Provision Linux hosts on supported distributions
Your infrastructure team creates the server or servers in the chosen location using a distribution listed in the Coolify installation docs (Debian, Ubuntu, the Red Hat family, SUSE, Arch, Alpine or 64-bit Raspberry Pi OS) on amd64 or arm64. For Coolify, the host needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk. For Dokku, check the current distribution list in its installation docs, since Dokku supports a narrower set of Ubuntu and Debian releases. This step is done when SSH access works with key-based login and the host meets the minimum specification.
Install Coolify or Dokku on the host
Install Coolify with its single installation script, or install Dokku on a single server, following the current steps in the vendor documentation. Coolify is Apache-2.0 licensed and its self-hosted edition carries no feature restrictions, so the software cost is zero. Dokku is MIT licensed and runs on one server by default. Your team pays for the server and for the time to install, patch and operate the platform. This step is done when the Coolify dashboard or the Dokku CLI responds and the host is listed as healthy.
Set the reverse proxy and TLS
Choose the proxy that will route domains and terminate HTTPS. Coolify runs one coolify-proxy container per server with Traefik by default or Caddy as the alternative, and both issue certificates automatically. Dokku ships nginx by default with Caddy, HAProxy, OpenResty and Traefik as alternatives. If your policy requires certificates from an internal authority, select the Custom (None) option in Coolify and manage routing and certificates yourself. This step is done when a test domain resolves to the server and returns a valid certificate.
Connect Git and configure build packs
Connect your Git provider and deploy one non-critical service first. In Coolify, choose a build pack (Nixpacks, Railpack in beta, Static, Dockerfile, Docker Compose or a prebuilt Docker image). In Dokku, push to the dokku remote and select a builder such as herokuish, Cloud Native Buildpacks with the pack CLI, or a Dockerfile. Pin the build method your team has tested, because rebuilding a Railway service can produce different output if the build pack changes. This step is done when the test service builds from a commit and answers on its domain.
Deploy databases with EU-hosted backups
Deploy each database inside the EU server, then configure scheduled backups to S3-compatible storage whose location you confirmed in the first step. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so plan a separate backup route for key-value stores. Dokku's dokku-postgres plugin supports scheduled backups to S3-compatible storage. Run a test restore into a separate instance and record the result. This step is done when a restore from an EU-stored backup completes and the data matches the source.
Configure preview deployments only if needed
Enable preview deployments only when your release process needs them. Coolify's default preview URL pattern requires wildcard DNS, and previews can expose data from non-production builds, so limit them to non-personal test data or disable them. Confirm which Git provider integration you use before you grant access. This step is done when the preview policy is written down and either disabled or tested against a wildcard record in your EU DNS zone.
Restrict administrative access and document it
Limit access to the Coolify or Dokku control plane to named administrators, use strong authentication, and restrict SSH and dashboard ports to approved networks. Record which administrators, support contractors and remote tools can reach the control plane from outside the EEA, and document the reason. Keep the API token scope narrow, and review the list on a schedule your organization sets. This step is done when the access list, network rules and the register of non-EEA access are stored with your compliance evidence.
Plan the cutover and rollback from Railway
Moving a service with a Railway volume requires a dump of the database and a copy of any persistent files, followed by a cutover plan that changes DNS and stops writes on the old service. Coolify's guidance for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so the dump and file copy are your rollback source. Agree the freeze window, the verification checks and the owner of each step in writing before you start. This step is done when a rehearsed dump, restore and DNS switch has been completed on a copy of the data.

Questions buyers ask before moving Railway workloads to the EU

How much does it cost to self-host Railway workloads in the EU?

The Coolify software is free to self-host, so your cost is the servers, storage, backups, monitoring and staff time that run it. Coolify Cloud, the managed edition, costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Note that Coolify Cloud still runs its control plane on Coolify's infrastructure, so it is not the same as keeping every component in your own EU location. Recurring costs grow with the number of servers, database size, backup storage and egress. Ask any provider for a written quote that separates server rental, storage, backup retention, monitoring and the labor for setup and upgrades. Compare that with your current Railway bill, which is metered per second for CPU, memory, storage and egress.

How long does a Railway to EU self-hosted move take?

The duration depends on how many services you have, how many use volumes, how large the databases are and how many domains and integrations must be cut over. Services without volumes are usually the simplest to redeploy, since Coolify builds from a Git repository, Dockerfile, Docker Compose file or prebuilt image. Services with volumes and databases need a dump, a restore and a planned cutover, which is where downtime is most likely. Confirm the timeline in a written scope with your partner or internal team, and test a restore in the target EU environment before you schedule the switch.

What must our team do itself, and what can a partner handle?

Your team keeps the decisions about which data may leave Railway, who holds access, and which regulatory obligations apply to you. A partner can plan the target architecture, install and harden the servers, configure the reverse proxy and TLS, set up database backups and restore testing, document the runbooks and prepare evidence for compliance reviews. DeployOpen does this as fixed-scope work in your own infrastructure, with ongoing support and upgrades available as retainers. DeployOpen does not issue audit reports or certifications, so independent auditors still assess your controls. Agree the split of responsibilities in writing before work begins.

Can an in-house platform team run a self-hosted PaaS in the EU?

Yes, a team with Linux administration, Docker, DNS and TLS experience can run Coolify or Dokku, but the work does not end at installation. Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, runs on specific Linux distributions, and installs with a single script. Your team then owns OS patching, proxy configuration, database backups, restore drills, monitoring and incident response, which Railway handles for you today. Dokku runs on a single server and needs 1 GB of RAM for the default Docker scheduler, so it simplifies some tasks but still needs the same operational discipline. Assess honestly whether you have on-call coverage for databases before you commit.

Does hosting in an EU region alone satisfy GDPR?

No. Choosing an EU location is a useful step, but GDPR also governs who can access the data. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so support staff and administrators outside the EEA need assessment. The same guidelines say an EU processor subject to third-country law is not itself a transfer, but compliance with a third-country authority request would be, so you should assess that exposure before engaging the provider. Your legal or privacy team should confirm the transfer analysis, the processor terms and the access model for your specific data.

What happens to Railway volumes during cutover?

Railway volumes do not move automatically to another region, so you copy the data yourself. For databases, Coolify supports scheduled backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, and its Import Backup accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. Redis, Dragonfly and KeyDB are not covered by scheduled backups, so plan a separate export for them. Persistent files need a copy to the new servers, and Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. Freeze writes, take a final dump, verify the restore, then switch domains. Keep the Railway copy until the new environment is confirmed.

Does the EU Data Act affect switching away from Railway?

The EU Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, and it applies since 12 September 2025, according to Regulation (EU) 2023/2854. The regulation sets a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027. These rights are relevant to exit planning, but they do not replace a technical migration plan, and your contract terms with Railway should be reviewed with counsel. Confirm with your legal team how these provisions apply to your agreement and how they interact with your own data processing obligations.

What evidence regulators and auditors will ask you for

A controller moving off Railway's single EU region needs records that show where personal data sits and why any transfer is lawful. Start with a data location inventory that lists every service, database, volume and backup, its host, the cloud account or data center it runs in, and the EU location you chose. Coolify backups can be pushed to S3-compatible storage and Dokku's dokku-postgres plugin can run scheduled backups to S3-compatible storage, so the inventory must also name the bucket, its region and any replica or offsite copy. Regulators ask this first, and the same list tells you which backups a deletion request reaches.

Next, keep the Chapter V file. Under Article 44 of the GDPR, every transfer to a third country, including onward transfers, must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat remote access from outside the EEA, even only viewing data on a screen for support, as a transfer. Keep an access log for administrators that records who connected to each server over SSH, from which country, and for which change. Coolify's API tokens and team roles and Dokku's SSH keys are the controls to review, and a quarterly export of who still holds them is evidence an auditor will request. Confirm with your vendors which support staff can view production data and from where.

Finally, document the third-country legal exposure assessment the EDPB guidelines describe, covering whether your EU processor could be compelled by a non-EU authority to disclose data. Record the reasoning, not just the conclusion. Also plan for exit: under the EU Data Act, providers must allow switching to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. Ask your hosting provider in writing how they will support export. DeployOpen prepares these records and controls, but independent auditors and certification bodies issue any attestation.

Evidence to keep for an EU residency review

An EU residency review asks where personal data sits, who can reach it, and what happens if it has to move. The cards below list the records that answer those questions for a Coolify or Dokku deployment, so the evidence is ready before an assessor, customer or regulator asks for it.

Data location register

A register listing each application, database, backup target, log store and object bucket, with the server, provider, country and data categories it holds. Because Railway's only EU region is Amsterdam, the register should show the EU location you chose for each component and confirm that no copy sits in an unlisted region. Check it against the servers you actually rented, not the plan you intended.

Transfer and third-country exposure assessment

A written assessment of every place personal data could leave the EEA, including remote support sessions from outside the EEA, hosting provider staff access, and any analytics or error-reporting tools wired into the app. Under EDPB Guidelines 05/2021, remote viewing from a third country counts as a transfer, so include it. Record the conclusion for each path and who signed off on it.

Administrator access and remote session log

A record of who holds SSH access to each server, who can log into the Coolify or Dokku control plane, and where each session originated. Keep the list of accounts and keys current and review it on a fixed schedule. Confirm that session logs are retained off the host so an administrator cannot edit them.

Backup location and restore test record

Documentation of where each scheduled database dump and file backup is stored, which region the S3-compatible bucket sits in, and the retention rule applied. Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB, so record how those datastores are protected instead. A restore test record with dates, the restored target and the result shows the backups work, and it proves they stay inside the EU location you chose.

Processor and sub-processor terms

Contracts with the server host, any managed backup or object storage provider, and any support vendor, plus the list of sub-processors each one uses. Check where each sub-processor stores or accesses data and whether the contract allows you to object to new ones. Confirm with each provider whether it is subject to third-country law with extraterritorial reach, since compelled access by a foreign authority is itself a transfer.

Exit or switching plan

A written plan for moving data and services to another provider or on-premises infrastructure, including export steps for each database, the dump format used, and the owner of each step. The EU Data Act gives customers switching rights for data processing services, so a documented plan also supports that right. Test the export once so the plan reflects what your team can really do.

How DeployOpen deploys Coolify or Dokku under an EU residency constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including EU locations you choose. For a Railway replacement under an EU residency constraint, the work starts with which services and data must stay in the EU and who can access them.

How we scope

Map every Railway service, volume and database to the EU location where it must run.
Record which third-country access paths, support tools and backup targets must be excluded or justified.
Agree the fixed-scope deliverables, timelines and responsibilities in writing before any work starts.

How we build

Install Coolify or Dokku on servers in the EU location your organization selects and configure SSH access.
Set up application builds, databases and S3-compatible backups so that data stays in the approved region.
Run security testing on applications, APIs and the hosting platform before cutover to production.

How we hand over

Deliver architecture, data-flow diagrams, runbooks and a record of where each dataset is stored.
Document backup, restore and rollback steps, including how databases and persistent files are recovered.
Provide evidence for your compliance team, while independent auditors and certification bodies issue any formal assessment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Track platform upgrades and proxy, database and backup changes that could affect data location.
Confirm with your legal and privacy teams whether any transfer assessment is still required for your setup.

Self-hosted Railway alternative for EU data residency