Self-hosted Render alternative for EU data residency

Render's only EU region is Frankfurt, and existing services cannot change region. Here is how to move services and Postgres to EU infrastructure you choose with Coolify or Dokku, and what that shifts onto your team.

Book a callTalk to us
On this page

Self-hosted Render alternative for EU data residency: what the constraint requires

A team runs web services, workers and a Postgres database on Render, and some of the data in those services is personal data that must stay in the European Union. Render's only EU region is Frankfurt, and existing services cannot be moved between regions, so the team has to build a new home for them. Coolify or Dokku on EU servers you control can meet the residency goal, but the operator then takes on hosting, backups and recovery. Residency is a question of where data is stored and where it is accessed from, so the region name on a server is only the first check.

The GDPR transfer rules and the vendor's own access policies matter as much as the region. The EDPB's Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, and treat storage in a cloud outside the EEA the same way. Before choosing a host, confirm with each provider which staff can reach the servers, where support sessions originate, and how the provider responds to a foreign government request. The same guidelines note that using an EU processor subject to third-country law is not itself a transfer, but complying with such a request would be, so that exposure belongs in the assessment. Confirm these points in writing with your legal and privacy team, because this page does not give a legal conclusion.

Which residency requirements apply when Render is replaced

Moving a Render workload to infrastructure you choose in the EU does not settle residency by itself. The controller still has to decide whether personal data leaves the EEA, through storage, remote access or a provider's legal exposure, and document that decision. The cards below set out the points the controller must assess, with DeployOpen preparing technical evidence but not making the legal determination.

Chapter V transfer conditions

Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. Before choosing a host, the controller should map which personal data sits in each Render service, Postgres database and log stream, and which of those flows could reach a non-EEA destination. The controller, not DeployOpen, decides whether a transfer mechanism is needed.

Fine ceiling under Article 83

Infringements of Articles 44 to 49 fall in the higher fine tier of Article 83(5)(c), with fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. This exposure is the reason residency decisions belong in the risk register with a named owner. The controller should confirm the exposure with its data protection officer and counsel.

Remote access counts as a transfer

EDPB 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. Vendor support staff, offshore administrators and contractors with console access can therefore create a transfer even when the data never leaves the EU disk. The controller should list every administrative path into the EU hosts and check where each operator sits.

Storage outside the EEA

The same guidelines state that storing data in a cloud outside the EEA is a transfer. Backups, log exports, object storage buckets and off-site copies all need the same check as the primary database, because an EU primary with a non-EEA backup target still moves personal data. Confirm the region of every backup target, including S3-compatible storage used by Coolify or the Dokku Postgres plugin.

Schrems II and the Data Privacy Framework

The CJEU invalidated the Privacy Shield in Case C-311/18 (Schrems II) while holding that standard contractual clauses remained valid. Commission Implementing Decision (EU) 2023/1795 finds adequacy for 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. The controller should record which mechanism it relies on and monitor the appeal.

US CLOUD Act exposure

18 U.S.C. 2713 requires US electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is located. A US-headquartered provider hosting in Frankfurt can therefore receive a request that reaches EU data. EDPB Recommendations 01/2020 say no effective technical supplementary measure can be envisioned where access goes beyond what is necessary and proportionate, so the controller should assess this exposure before choosing a provider.

Which open-source platform fits EU residency: Coolify or Dokku

Coolify fits EU residency best when your footprint spans several servers or your team wants a web dashboard for deployments. You register each server you select in an EU location over SSH, Coolify prepares it to run Docker workloads, and you assign each application to a server. Coolify is licensed under Apache-2.0, and its self-hosted edition is free with all features, so the recurring costs are the servers, storage and staff time. Each host needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported Linux distribution.

  • Server placement: Each application targets a server you registered, so a regulated service can stay on EU hardware while a non-regulated service runs elsewhere. Multi-server deployments are documented, so confirm that every node you plan to use sits in the EU.
  • Proxy and TLS: Each server runs one coolify-proxy container. Traefik is the default, Caddy is the alternative, and both issue HTTPS certificates automatically. The Custom (None) option hands routing and certificate management to your team.
  • Databases and backups: PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse have scheduled backups that can upload to S3-compatible storage. Redis, Dragonfly and KeyDB are not covered by scheduled backups, so plan a separate export for them.
  • Control plane location: Self-hosted Coolify runs its dashboard on a server you choose. Coolify Cloud runs the management instance on Coolify's infrastructure while your servers stay yours, so the location of that instance and the metadata it stores becomes part of your residency assessment.

Before you commit, confirm with Coolify the region that hosts any management instance you would use and confirm that the backup bucket for personal data sits in the EU.

How to deploy EU-only services and Postgres under the constraint

This sequence moves Render services, cron jobs and Postgres onto servers you choose in the EU, with every data store, backup and log sink confirmed to sit inside that boundary before any traffic moves.

  1. Choose EU hosting and confirm every data path

    Select a provider with servers in an EU region you can name, then write down where each piece of data will sit: application servers, the Postgres database, backup storage, and any log or metric sinks. Ask the hosting provider and any monitoring vendor, in writing, where their management plane and support access run, because remote access from a third country counts as a transfer under EDPB Guidelines 05/2021. The step is done when every destination is on a list signed off by your data protection lead.

  2. Provision Linux servers in the chosen region

    Create the servers in the EU region, using a supported Linux distribution on amd64 or arm64. Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and runs only on the Linux families its installation docs list. Dokku supports specific Ubuntu and Debian releases and needs 1 GB of RAM for the default Docker scheduler. Confirm the exact sizing against the current installation pages before ordering, and record the server IDs and region codes. The step is done when SSH access works from your bastion host only and the region is confirmed in the provider console.

  3. Install the platform and connect the servers

    Install Coolify or Dokku on the EU servers, following the vendor installation guide. Coolify connects to each server over SSH and prepares it to run Docker workloads, so restrict SSH keys and firewall rules before connecting. Dokku runs as a single-server platform on the host itself. Set the admin account, enable multi-factor authentication where offered, and confirm the instance loads over HTTPS. The step is done when the platform reports the server healthy and a test application can deploy from Git.

  4. Map each Render service and cron job to an app

    Inventory the services in your Render Blueprint, including web services, background workers, cron jobs and static sites. Recreate each one as a Coolify application or Docker Compose stack, or as a Dokku app with a Procfile process type and an app.json cron definition. Re-enter environment values through the platform's secret handling rather than copying them into repositories. The detailed mechanics for each platform are in the Render to Coolify and Render to Dokku migration guides. The step is done when every Render service has a matching deployed app in the EU environment.

  5. Move Postgres into the EU database

    Create the Postgres database on the EU server, then export the Render database with a logical dump and restore it into the new instance. Render's paid Postgres backups are not a complete export path, so use logical dumps from the database connection you already have. Coolify's Import Backup accepts PostgreSQL SQL dumps and custom archives, and Dokku's dokku-postgres plugin provides export and import commands. Run a row count and a sample of key queries against both databases before cutover. The step is done when the restored data matches the source and the application points at the EU connection string.

  6. Configure S3-compatible backups in an EU bucket

    Create an S3-compatible bucket in an EU location, and set the database backup schedule to upload there with a retention policy you have approved. Coolify's scheduled PostgreSQL backups can upload to S3-compatible storage and apply retention by count, days or size, and Dokku's Postgres plugin supports scheduled backups to S3-compatible storage. Note that Coolify does not schedule backups for Redis, Dragonfly or KeyDB, so plan those separately. Run one restore test into a scratch database and record the result. The step is done when a backup object lands in the EU bucket and the restore test succeeds.

  7. Set DNS, certificates and routing

    Point your domains at the EU servers and confirm that the reverse proxy, either Traefik or Caddy in Coolify or nginx by default in Dokku, issues certificates for each hostname. Check that the platform handles HTTPS automatically before you rely on it, and keep a copy of the DNS change plan. Lower any DNS record time-to-live values with your DNS provider ahead of the change, if your provider supports it. The step is done when each hostname resolves to the EU server and returns a valid certificate.

  8. Cut over and verify the new environment

    Freeze writes on the Render database, take a final logical dump, restore it into the EU database, and switch DNS to the EU servers. Run your smoke tests and check logs and monitoring against the sinks you approved in the first step. Keep the Render services running in read-only mode for a period your team agrees in advance, so you can roll back. Remember that a rollback in Coolify can redeploy a retained application image but does not restore databases or persistent files. The step is done when the EU services serve production traffic and the Render workloads are retired under a written decommission record.

Evidence to collect for a residency review

A residency review asks one question in many forms: can you show where every byte of personal data lives, who can reach it, and how it could leave the EU. The cards below list the records that answer that question for a Render move to Coolify or Dokku. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any opinion.

Data map by region

List every web service, worker, cron job, Postgres database and Key Value instance, with the server, region and provider that hosts it. Include backup targets and log sinks, since copies of personal data count as stored data. Check that each row names an EU location you chose, not the location a provider defaults to. Keep the map under change control so a new service cannot appear without a region.

Server provider contracts and locations

Collect the contracts, data processing terms and facility locations for every server, DNS, object storage and email provider in the stack. Confirm the legal entity that signs, any sub-processors, and where support staff can reach the hardware. A provider headquartered outside the EU is not automatically a transfer, but its contract and access model must be assessed before you rely on it.

Transfer assessments for remote access

Record every case where a non-EU sub-processor or support engineer can view or administer data, including screen sharing during an incident. The EDPB treats remote access from a third country as a transfer even when no copy is made. Document the Chapter V basis, the supplementary measures and your assessment of third-country authority requests for each one.

Backup and restore test records

Keep dated restore tests for each Postgres database, showing the dump file, the storage target, the restore host and the row counts checked. Coolify and the dokku-postgres plugin both write backups to S3-compatible storage, so confirm the bucket region and retention settings. Redis, Dragonfly and KeyDB are not covered by Coolify's scheduled backups, so record how their data is rebuilt or accepted as loss.

Management plane access logs

Export logs of who signed in to the Coolify or Dokku host, who created API tokens, and who deployed or changed environment values. Include SSH sessions, sudo use and changes to the proxy configuration. Store these logs outside the server they describe, in the EU, and set retention in line with your policy. Confirm which of these events your chosen tooling records by default, since the platform may not log everything you need.

Data Act switching terms

For any managed service you keep, such as an EU-hosted DNS, email or object store, collect the switching clauses. The Data Act gives customers a right to move to another provider or to on-premises infrastructure, with notice and transition periods that the contract must respect. Check the switching charge position against the January 2027 ban, and record the exit assistance each provider commits to.

Questions teams ask before moving Render workloads to EU servers

How much effort does moving Render workloads to EU servers take?

The effort depends mainly on how many services, workers, cron jobs and databases you run, how much of your configuration lives in a render.yaml Blueprint, and how much data must move. Each service needs a container or build path on Coolify or Dokku, its environment values must be re-entered, and its domains and certificates must be switched. Databases add the largest share of work because they need a logical backup, a restore and a verified cutover. No duration is quoted here. Ask the implementer to break the estimate into services, data volume, cutover windows and testing so you can compare the parts.

Can our team move Render workloads to EU servers without outside help?

A team with Linux, Docker and Postgres experience can often do it in-house, especially for a small number of services. The harder parts are server hardening, backup design, certificate and DNS changes, and proving that restores work. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported Linux distribution, and Dokku needs 1 GB of RAM for its default Docker scheduler. Those are minimums, not sizing advice. Decide early which parts your staff will own and which you will buy as a fixed-scope engagement.

What recurring work remains after cutover on self-hosted servers?

After cutover, the recurring work moves from Render to your team. The main items are:

  • Operating system and runtime patching on each server
  • Coolify or Dokku upgrades and proxy maintenance
  • Scheduled database backups, off-site copies and retention checks
  • Monitoring, alerting and an on-call rota for outages
  • Renewing the access and secret rotation that Render previously handled for you

Backups deserve special attention: 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. Budget for these tasks as ongoing staff time, and ask any provider whether patching, backup testing and on-call are included in a retainer.

Should we choose Coolify or Dokku for EU hosting?

Choose Coolify if you want a web interface, several servers, one-click database templates, scheduled backups to S3-compatible storage and preview deployments. Choose Dokku if you prefer a single-server, command-line workflow that works like git push to a Heroku-style remote. Coolify is licensed under Apache-2.0 and its self-hosted edition is free forever with all features, according to its pricing page. Dokku is MIT licensed and runs on a single server by default, with the k3s scheduler available for multi-server clusters but requiring a Docker registry. Your team's skills, the number of servers and your backup tooling should drive the choice.

Does Render's Frankfurt region already meet our EU data residency goal?

Frankfurt keeps hosting in the EU, but it may not settle every residency question. Data residency is about where data is stored and processed, while transfer rules also cover remote access from outside the EEA and any support or administration by a provider subject to non-EU law. The EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data, as a transfer. Your legal and privacy teams should review Render's contract terms, subprocessors and access model. Also note that existing Render services cannot change region, so moving to infrastructure you choose is the only way to pick a different EU location.

What does a restore test involve before we cut over?

A restore test proves that a backup can be rebuilt into a working database, not just that a file exists. It usually includes taking a logical backup from Render Postgres, restoring it into a non-production Coolify or Dokku database, starting the application against it, and checking row counts, key queries and application behavior. Record how long the restore takes and what steps an operator must run by hand. Repeat the test on a schedule, because a backup you have never restored is unproven. Ask the implementer to document the procedure, the owner, and the evidence you will keep for auditors.

What should we ask for in a fixed-scope quote for this move?

Ask for a written scope that lists each service, worker, cron job and database to move, the target EU servers and their providers, and the Coolify or Dokku version to be installed. The quote should name deliverables such as migrated services, restored databases, backup configuration, DNS and certificate cutover, runbooks and documented restore tests. Ask what is excluded, how data is handled during transfer, who holds access, and how changes to scope are priced. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask whether ongoing support, upgrades and testing are offered as a separate retainer.

What changes in operations after leaving Render

Leaving Render moves capacity planning, operating system and platform upgrades, backups and restore testing from the vendor to your team. On Render, the platform handles most of this for managed Postgres and web services. On Coolify or Dokku, you choose the server sizes, schedule updates for the host OS and the Docker runtime, and decide how much headroom each EU server keeps. Coolify's installation docs set a floor of 2 CPU cores, 2 GB RAM and 10 GB of free disk, but that is a minimum for the Coolify host, not a sizing for your workloads. Ask your provider which instance types exist in your chosen EU region and confirm how resizing or adding a second server works before you commit to a layout.

Backups deserve the most attention. Coolify's scheduled PostgreSQL backups use the pg_dump custom format, can be uploaded to S3-compatible storage in an EU bucket, and run on cron schedules with retention by count, days or size. Coolify's guide for teams coming from managed platforms is explicit that a rollback can redeploy a retained application image but does not restore databases or persistent files. Plan for restore tests as a recurring task, record the time a restore takes, and keep Redis data, which Coolify does not back up on schedule, under a separate, documented process.

Networking changes too. Coolify's preview deployments build pull or merge requests at a default {{pr_id}}.{{domain}} URL, which needs wildcard DNS pointing at the server, so confirm your EU DNS zone supports that record before enabling previews. Dokku runs on a single server by default, so a host failure takes every app on it offline until you rebuild or restore. If EU availability matters, decide early whether one server with tested restores is enough, or whether you need the k3s scheduler and a registry, which adds operating work of its own.

How DeployOpen deploys Render alternatives under EU residency rules

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or networks. For EU residency, that means placing Render workloads on infrastructure you choose in the EU and writing down where every service, database and backup lives.

How we scope

  • Inventory every Render service, worker, cron job, Key Value instance and Postgres database, with its current region and data categories.
  • Record each EU hosting location, backup target and any support access path that could show personal data outside the EEA.
  • Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.

How we build

  • Install Coolify or Dokku on servers in your chosen EU location, with the reverse proxy, HTTPS and firewall rules documented.
  • Rebuild each workload from its Git source, Dockerfile or buildpack, and restore databases with logical dumps into your own Postgres.
  • Test the cutover, DNS and certificate changes, and rollback steps against a staging copy before any production switch.

How we hand over

  • Deliver a runbook covering deployments, scaling, database backups, restore tests and who holds each credential.
  • Provide a data location register that maps each system, backup copy and administrator access point to its EU location.
  • Document the controls and evidence you would need for an assessment, while your auditors or certification bodies make any formal judgment.

How we support

  • Ongoing support, upgrades, backup verification and continuous security testing are available as retainers after handover.
  • Upgrades of the platform, proxy and database images are planned, tested in staging and recorded in the change log.
  • Confirm your retainer scope, response expectations and access model in writing so residency commitments stay enforceable.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com