Self-hosted Heroku alternative for EU data residency

Why EU data residency changes the Heroku decision

If your organization is based in the EU and must keep personal data inside the EU, the Heroku question is less about app features and more about where every copy of your data lives. Heroku's Common Runtime offers one Europe region (the eu region), and Private Spaces are available in Dublin, Frankfurt and London. However, all snapshots captured with pg:backups are stored in the U.S., regardless of where the database is located. That means a Heroku deployment that is fully in the EU for live traffic can still hold backup copies outside it. Running Dokku or Coolify on servers in an EU data center you choose keeps the application, the database and its backups under your control in one jurisdiction.

The choice matters because residency is about where operator-controlled copies sit, not a claim that a platform is compliant. Moving to self-hosted software does not make an organization compliant with the GDPR, and it does not remove the need for a transfer assessment for any third party that still touches the data, such as a backup target, a DNS provider, an email service or a monitoring tool. Start by listing every place personal data is written in the current Heroku setup: the Postgres primary, the pg:backups snapshots, log drains, add-ons, and any Heroku-hosted build artifacts. Then confirm with your legal and privacy team which of those copies must stay in the EU.

Before you commit to a target, confirm three things in writing with the vendor or your provider: the region of each server or data center you plan to use, whether any backup or object storage endpoint is in the EU, and where the support staff who might access those systems are located, since remote access from a third country can itself count as a transfer. Ask your counsel to review the EDPB guidance on transfers and the data processing terms of each service. DeployOpen can plan and document the EU-only layout, but the residency determination remains with your organization and its advisers.

What the EU residency constraint requires you to control

EU residency is less about where a server sits and more about who can reach the data and where copies travel. The cards below describe obligations and the controls that follow from them, and a legal review of your own processing decides how they apply.

Every transfer outside the EU

Article 44 of the GDPR requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. For a Heroku app, the question is which copies leave the EU: the primary database, the pg:backups snapshots, logs, error reports and build caches. Map each store to a region and a legal entity before choosing a Dokku or Coolify host.

Remote access counts as a transfer

The EDPB's *Guidelines 05/2021* state that remote access from a third country is a transfer, even if the data is only displayed on a screen for support or administration. Vendor engineers, offshore contractors and follow-the-sun support teams with console access can therefore create transfers. Ask who can open a shell, a database console or the Coolify dashboard, and from which countries.

Storage outside the EEA

The same guidelines treat storage in a cloud outside the EEA as a transfer. Heroku's PGBackups documentation says all pg:backups snapshots are stored in the U.S., whatever the database region. A self-hosted setup keeps backups on storage you choose, such as S3-compatible storage in an EU data center, and the dokku-postgres plugin and Coolify both support that target. Confirm the bucket region and any replication settings in writing.

U.S. CLOUD Act reach

18 U.S.C. 2713 requires U.S. electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever that data is located. A U.S.-headquartered provider holding your data in an EU region can therefore still be compelled. Evaluate this exposure before engaging any provider, and treat it as a question for your counsel rather than a settled answer.

Foreign court orders under Article 48

Article 48 of the GDPR allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only where it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. Ask counsel whether your processing relies on such an agreement and how your provider would respond to a request. Self-hosting on an EU host you control narrows the number of parties who could receive one.

Transfer tools and their limits

Transfer tools such as the Data Privacy Framework and standard contractual clauses have been challenged in court, and an appeal in Case C-703/25 P is pending. EDPB Recommendations 01/2020 also state that where a provider must access data in the clear and third-country powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Document which transfer mechanism you rely on and review it on a schedule.

Where Heroku meets the constraint and where it does not

The Common Runtime is Heroku's shared multi-tenant platform, and it is the default place most teams deploy apps. According to Heroku's Dev Center, the Common Runtime has two regions, eu and us, and apps are created in the us region unless you specify another. For a residency decision, the important detail is the default: a team that runs heroku create without a region flag will place the app in the United States.

Two regions only: the Common Runtime offers eu and us, so Europe is a single region choice.
Default placement: apps are created in the us region unless another region is specified at creation.
Existing apps: confirm with Heroku whether an app's region can be changed after creation, and what that involves.
Add-ons and related services: check the region of each add-on and whether it can be placed in the same region as the app.
Current options: confirm the current list of Common Runtime regions with Heroku in writing before relying on it.

Before you decide, ask Heroku to confirm in writing which regions are available for each app and add-on you run, and where each one stores data.

Heroku Postgres is often the component that decides residency, because the database may sit in an EU region while the backup copies do not. According to Heroku's PGBackups documentation, all snapshots captured with pg:backups are stored in the U.S., regardless of where the database is located. That statement applies to Heroku's own backup feature, so it matters even when the database itself runs in Europe.

Backup location: pg:backups snapshots are stored in the U.S. whatever the database region.
Database region: an EU database does not change where those snapshots are kept.
Exports you create: a dump you take yourself and store in an EU bucket is controlled by your own process, not by Heroku's backup setting.
Retention and access: confirm with Heroku the retention period, access controls and who can read backup copies.
Written confirmation: ask Heroku to confirm backup storage locations in writing for your plan and account.

If your data must stay in the EU, treat Heroku's managed backups as a data flow to assess, and ask for the backup location statement in writing before you move any production data.

Which self-hosted options keep data in EU servers

This table compares Dokku, Coolify and open-core Dokploy on how each controls where application data and backups are stored, what backup options they include, and how far they scale past one host. Because you choose the EU data center for the servers, you also choose where backup targets sit, so check both before you sign a hosting contract.

Option	How data location is controlled	Backup and storage trade-offs	Multi-server limits
Dokku (MIT)	You pick the server and its data center, and app containers run on that host	The dokku-postgres plugin runs one-off or scheduled backups to S3-compatible storage, so the bucket region is your choice	Runs on a single server by default; the k3s scheduler builds a multi-server cluster but needs a Docker registry
Coolify (Apache-2.0)	You connect your own servers over SSH, so the EU location is the server you add	PostgreSQL scheduled backups can go to S3-compatible storage with retention by count, days or size; Redis, Dragonfly and KeyDB are not covered by scheduled backups	Deploys to multiple servers you manage; confirm current multi-server limits in the multi-server docs before you size the cluster
Dokploy (open core)	Self-hosted on servers you choose, with the Apache 2.0 code outside proprietary directories	Check which backup and storage features sit in the source-available proprietary code before relying on them	Built on Docker Swarm for clustering; features such as SSO, audit logs and custom roles sit in the proprietary code
Heroku Common Runtime (reference)	Choose the eu region at app creation; apps default to the us region	pg:backups snapshots are stored in the U.S. regardless of database region	Managed by Heroku; multi-region placement depends on Private Spaces
Backup target location	Set by the bucket or storage endpoint you configure, not by the PaaS	Confirm the bucket region, provider jurisdiction and encryption keys in writing	Each server or cluster node may need its own backup path; list them in the quote

How to deploy Dokku or Coolify on EU servers

This sequence moves a Heroku workload onto Dokku or Coolify on servers in an EU data center you choose, with backups and logs kept inside the EU and checked before cutover.

Choose and confirm the EU data center
Your infrastructure team selects a provider and a facility in the EU, then asks the provider to confirm the physical location of compute, block storage, snapshots and object storage in writing. Ask whether any control plane, support tooling or monitoring service used by the provider stores copies outside the EU. The step is done when the written confirmation lists each location and the sub-services that hold data, and your data protection lead has signed off on it.
Size hosts against the platform minimums
Your platform engineers size the servers for the chosen tool. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk and runs on specific Linux distributions on amd64 or arm64. Dokku needs at least 1 GB RAM for its default Docker scheduler and supports Ubuntu 22.04, 24.04 and 26.04 or Debian 11 or later. Add headroom for your application containers, database volumes and build jobs, which the minimums do not cover. The step closes when each host passes the installer's preflight checks and has a documented disk and memory baseline.
Set the S3-compatible backup target inside the EU
Your team provisions an S3-compatible bucket in the same EU region or in another EU location you have confirmed, and configures it as the backup target. For Dokku, the dokku-postgres plugin can run scheduled backups to S3-compatible storage. For Coolify, PostgreSQL backups on cron schedules can upload to S3-compatible storage. Set retention limits and confirm that the bucket's replication and access logs also stay in the EU. The step is done when a test backup lands in the EU bucket and a restore from it succeeds on a scratch database.
Configure the reverse proxy and TLS
Your team picks the proxy that routes domains and terminates HTTPS on each host. Coolify runs Traefik by default and can use Caddy, and both obtain certificates automatically. Dokku ships nginx by default and also supports Caddy, HAProxy, OpenResty and Traefik. If you choose Coolify's Custom (None) option, your team owns routing and certificate issuance. Confirm that certificate authorities and DNS providers you use do not change where application data is stored. The step closes when each application domain resolves to the EU host and returns a valid certificate.
Export from Heroku and restore into the EU database
Your database engineer runs a pg:backups capture on the Heroku database, then downloads the dump promptly, since Heroku stores those snapshots in the U.S. regardless of database location. Restore the dump into the Dokku Postgres service or the Coolify-managed PostgreSQL instance on the EU host, then re-create config vars as environment variables. Delete the Heroku-side snapshot once the restored copy is verified, and record the deletion in your change log. The step is done when row counts and key queries match between the source and the EU target. The detailed cutover steps are in the Dokku and Coolify migration pages.
Verify that no copy leaves the EU
Your security and compliance team checks every place data can be written: application logs, database logs, build caches, container registries, monitoring agents, error trackers, backup buckets and DNS query logs. For each location, confirm the storage region in writing or from the console, and note any sub-processor that can access it remotely. Remote support sessions that display data from outside the EU also count as transfers under EDPB Guidelines 05/2021, so restrict them. The step closes with a signed register of locations and a list of exceptions to resolve before go-live.
Cut over and confirm the EU deployment
Your release team lowers DNS TTLs in advance, points the production domains at the EU hosts, and keeps the Heroku app running until the new deployment passes health checks and a data reconciliation. Confirm that scheduled jobs run once only on the new platform. Retain the Heroku snapshot and config records for your agreed period, then remove Heroku resources. The step is done when production traffic is served from the EU hosts, the Heroku app is scaled down, and the verification register is updated.

Evidence that shows where your data lives

A residency decision is only as strong as the records behind it. The cards below list the documents and logs that show where Heroku processes, stores and copies your data today, and where a Dokku or Coolify setup would keep it. An auditor or regulator decides whether the transfer position is adequate; DeployOpen prepares the evidence and does not issue attestations.

Data location register and transfer map

List every place personal data sits: app regions, Postgres, backup snapshots, logs, error reporting, email and support tooling. For each entry, record the country, the operator and whether any party outside the EEA can view or store it. Under GDPR Article 44, remote viewing from a third country counts as a transfer, so the map must include support access paths, not only storage. Confirm the map with your data protection officer before cutover.

Provider data processing terms and sub-processor list

Collect the signed data processing terms, the standard contractual clauses in force for each provider, and the current sub-processor list with locations. For Heroku, check which region each resource uses and whether Heroku's storage terms cover the backup location. For a Dokku or Coolify setup, the contract is with your own hosting provider and any third-party registry or backup target you add, so those agreements become part of your evidence set.

Backup target configuration and bucket region records

Export the configuration that decides where backups land: the S3-compatible endpoint, bucket name, bucket region and retention settings. For self-hosted Postgres, the dokku-postgres plugin and Coolify's scheduled backups both write to S3-compatible storage you choose, so the bucket region becomes a residency control you must document. Keep a dated screenshot or API export of each setting, and test a restore from an EU bucket to prove the copy is usable.

Access logs for remote support from third countries

Keep logs that show who opened production systems, from which country and for what purpose. This covers SSH sessions to Dokku or Coolify hosts, Coolify dashboard logins, API token use and any vendor support sessions. Each entry that reveals personal data to someone outside the EEA is a transfer that needs its own legal basis and record. Set retention for these logs in advance so the evidence exists when an assessor asks.

Heroku's written confirmation of backup storage

Heroku's PGBackups documentation states that snapshots captured with pg:backups are stored in the U.S. regardless of database location. Ask Heroku in writing to confirm that position for your account, your plan and your contract date, and file the reply with your register. Treat the documentation as the provider's statement, not a substitute for the written answer your assessor will expect.

Questions buyers ask before choosing a self-hosted EU option

What drives the cost of self-hosting Dokku or Coolify instead of Heroku?

The cost is mostly the servers you rent, the staff time to run them, and the database backup storage you pay for. Heroku bills per dyno, database plan and Private Space, which are recurring line items. Self-hosting moves that spend to servers in an EU data center you choose, the time spent on patching, upgrades, backups and on-call, and any paid support or retainer. Coolify's self-hosted edition is free with all features under Apache-2.0, and Dokku is MIT licensed, so software licenses are not the main line. Ask any quote to split one-time setup from recurring server, storage, support and on-call costs, and to state which items are optional.

Does the Coolify Cloud option keep our data in the EU?

Confirm this in writing with Coolify before you rely on it. Coolify's pricing page says customers bring their own servers while the Coolify instance runs on Coolify's managed infrastructure, so the control plane sits outside your servers. Ask Coolify which region hosts that instance, what data it stores (such as server addresses, deployment metadata and logs), where backups of that data go, and who can access it from outside the EEA. If those answers do not meet your requirements, a self-hosted Coolify instance on your own EU servers keeps the control plane inside your environment.

Does self-hosting remove the need for a transfer assessment?

It removes the vendor's transfer, but it does not remove the legal review. When you run Dokku or Coolify on servers in an EU data center, you avoid sending personal data to a U.S.-operated Heroku snapshot store, which is the specific problem in the Heroku pg:backups design. You still need to check your other processors, such as the data center operator, DNS, email, monitoring and any SaaS tool that receives personal data, and record their transfer positions. Remote access from a third country, even only viewing data for support, can also count as a transfer under EDPB Guidelines 05/2021, so the support model matters. Ask counsel or your data protection officer to review the design.

Can our team run a Dokku or Coolify setup without outside help?

A small team with Linux and Docker experience can run a single-server setup, but the work does not end at installation. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and Dokku needs 1 GB of RAM for the default Docker scheduler, so the hardware bar is low. The harder parts are backups you test by restoring, OS and proxy patching, certificate and DNS handling, and a runbook for failure. Ask yourself who will be on call for that work and whether the same people can also support the application. A written scope with an outside partner can cover the parts you do not want to staff.

What does a fixed-scope implementation need from our side?

A fixed-scope engagement needs your decisions and access before work starts, and those inputs set the scope. Expect to provide the EU data center or cloud account, the list of apps and their build methods, the database inventory and retention needs, the domains and DNS authority, the identity model for operators, and the names of the people who approve the data protection and security decisions. You also need to confirm the recovery targets you expect and who owns the evidence for your compliance assessment. DeployOpen sets scope, deliverables and timelines in writing before work starts, and does not publish a price list, so the quote follows from that written scope.

How long does an EU migration from Heroku take?

No researched timeline is available for this migration, so ask for a written timeline in the scope document rather than relying on a general estimate. The duration depends on the number of apps, how many databases must be exported and restored, how many custom buildpacks or Dockerfiles need rework, the number of config vars and external integrations, and how many compliance reviews run in parallel. Ask for milestones covering the server build, a test restore of each database, a staged DNS cutover and the legal review. Treat any date in a proposal as a planning target until the scope is agreed.

Where does the data go if we keep Heroku Postgres backups?

Heroku's PGBackups documentation states that all snapshots captured with pg:backups are stored in the U.S., regardless of where the database is located. That means a database in the EU region can still have backup copies in the U.S., which matters if the backups contain personal data. The alternative is to run your own PostgreSQL on an EU server and send backups to S3-compatible storage in a location you choose. Dokku's dokku-postgres plugin and Coolify's scheduled PostgreSQL backups both support that pattern, but you must test restores and confirm the storage location yourself.

Should we wait for Heroku Fir before deciding on EU hosting?

Fir is not a basis for a compliance decision yet, because Heroku's Generations article states that Fir is not considered certified for any compliance program until Heroku receives the auditor reports. Fir also requires a Private Space for every dyno, and Heroku's blog says telemetry and builds stay in the same region as the Fir Space. Ask Heroku in writing which regions, reports and dates apply to your workload. Meanwhile, self-hosted EU options give you control over where the data sits, but they do not give you a vendor's audit report, so your own controls must be evidenced.

What you take on for backups, upgrades and recovery

Leaving a managed platform moves capacity, backups and recovery to your team, and that is the first thing to plan for once data residency has pushed you off Heroku's managed services. Coolify's guide for teams coming from managed platforms makes the boundary concrete: a rollback can redeploy a retained application image, but it does not restore databases or persistent files. On a Coolify or Dokku server in an EU data center you choose, the restore path for PostgreSQL is the one you build, test and document yourself, separate from any deployment rollback.

Backup coverage also differs by datastore. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any Redis-backed queue or session store needs its own persistence plan and restore test. On the Dokku side, the dokku-postgres plugin supports scheduled backups to S3-compatible storage, and that storage should sit in the same EU jurisdiction as the database. Dokku's version is still 0.x, so confirm which release you pin and how upgrades are staged before you depend on it for production.

Patching the host, the container runtime, the reverse proxy and the database engine is your responsibility under this model, and it recurs. Ask whether your team or a retainer partner will own security updates, Dokku or Coolify upgrades, and periodic restore tests into a scratch environment, because an untested backup is not evidence of recovery. Record the owner, the cadence and the recovery time you can actually meet for each component, so that a regulator or auditor asking how a lost EU database would be restored receives a documented answer.

How DeployOpen deploys Heroku alternatives under EU residency

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For EU residency, that means the server location, database backups and support access are decided and evidenced by your team before any application moves.

How we scope

Map every Heroku app, add-on and region setting to the EU location you choose for each workload.
Confirm where database backups, logs, metrics and build artifacts will be stored and who can access them.
Record scope, deliverables and timelines in writing before work starts, as engagements are fixed-scope.

How we build

Install Dokku or Coolify on servers in the EU data center you select, with the proxy and TLS setup documented.
Move databases to PostgreSQL you run, with backups written to EU-hosted S3-compatible storage you control.
Test restores of backup files in a separate environment, not only the backup jobs, before cutover.

How we hand over

Deliver a residency register listing each system, data category, storage location and access path.
Document runbooks for deploys, rollbacks, database restores and proxy renewal in your own repositories.
Provide evidence packs for your auditors, which prepare controls and records but do not replace an independent assessment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover.
Review platform versions, such as Dokku and Coolify release notes, and plan upgrades with your change process.
Retest after configuration changes, new add-ons or new regions so residency controls stay accurate over time.