Alternativa apenas UE a Heroku (Salesforce).

Heroku is the original developer-first PaaS, acquired by Salesforce in 2010 and now part of Salesforce.com Inc. Salesforce is a US corporation, Heroku's default region is in the US, and the EU "Common Runtime" lives in AWS Ireland - meaning your Heroku app is on AWS infrastructure with Salesforce as the contractual processor. Both layers are US-jurisdictional. The sovereign alternative is straightforward: a self-hosted PaaS like Coolify or Dokku on EU infrastructure, or a fully-managed equivalent operated by an EU partner.

United States Stack de substituição, apenas UE 11 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Heroku (Salesforce)
Sede: San Francisco, CA (Salesforce)
Jurisdição: United States
Regime jurídico: CLOUD Act, FISA 702

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Heroku (Salesforce)

Heroku exits we have run come from three triggers: a customer audit (B2B SaaS) flagging the AWS-Ireland-via-Heroku data path as Schrems II-exposed, the discontinuation of free dynos in 2022 forcing a cost reassessment, or a strategic decision to remove the double provider chain (Salesforce → AWS) which complicates DPA management. Heroku's value is the developer experience; open source alternatives like Coolify, Dokku and Caprover reproduce most of that experience on EU infrastructure.

Heroku (Salesforce) serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Heroku (Salesforce) com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Heroku (Salesforce) serviço	O que usamos no lugar	Nota de engenharia
Dynos (web/worker)	Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.	O Coolify oferece uma DX quase idêntica à do Heroku (deploys via git push, apps one-click) em infraestrutura na UE. Fatura tipicamente 60-80% menos do que o Heroku para compute equivalente.
Heroku Postgres	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A replicação lógica permite uma transição sem downtime. Os backups do Heroku Postgres podem ser descarregados como pg_dump padrão e restaurados em qualquer lugar.
Heroku Redis	Binadit Managed Cloud Platform. Redis ou Valkey, com Sentinel para failover.	API Redis padrão; migração via SLAVEOF ou transferência de RDB.
Heroku Connect (Salesforce sync)	Binadit DevOps & Support. Integration workers em execução na sua própria infraestrutura, comunicando diretamente com a API do fornecedor.	Para equipas que mantêm o Salesforce CRM, a camada de sincronização é reconstruída; para equipas que substituem o Salesforce, esta preocupação desaparece.
Add-ons marketplace	Binadit DevOps & Support. Os componentes que efetivamente utiliza, implementados e operados como parte da sua stack.	A conveniência dos add-ons do Heroku é a maior perda de DX; a gestão direta de fornecedores é o trade-off pela soberania.
Pipelines (review apps, CI/CD)	Binadit DevOps & Support. Ambientes de revisão por branch no Kubernetes, criados e destruídos pelo GitLab CI.	O Coolify suporta ambientes de preview por branch.
Heroku Buildpacks	Binadit DevOps & Support. Dockerfiles ou Cloud Native Buildpacks, construídos no GitLab CI.	A maioria das apps Heroku faz deploy sem alterações via Cloud Native Buildpacks no Coolify.
Logplex / Logging	Binadit Managed Cloud Platform. Loki para agregação, com Grafana para consultas e políticas de retenção por stream.	Loki é o padrão; agrega logs de todos os containers.
Heroku CI	Binadit DevOps & Support. GitLab CI com runners na sua própria infraestrutura.	GitLab CI num runner self-hosted na UE é o substituto de nível de produção.
Heroku Private Spaces	Binadit Private Infrastructure. Ambiente totalmente isolado, hardware dedicado, arquitetura de rede personalizada.	O conceito de "Private Spaces" é uma VPC com outro nome; a rede padrão europeia trata disso.
SSL / domains	Binadit Managed Cloud Platform. cert-manager com Let's Encrypt, com renovação automática.	A transferência de domínio é uma mudança de registrar; o SSL é automatizado por todas as alternativas PaaS modernas.

Dynos (web/worker)

O que usamos no lugar: Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.
Nota de engenharia: O Coolify oferece uma DX quase idêntica à do Heroku (deploys via git push, apps one-click) em infraestrutura na UE. Fatura tipicamente 60-80% menos do que o Heroku para compute equivalente.

Heroku Postgres

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia: A replicação lógica permite uma transição sem downtime. Os backups do Heroku Postgres podem ser descarregados como pg_dump padrão e restaurados em qualquer lugar.

Heroku Redis

O que usamos no lugar: Binadit Managed Cloud Platform. Redis ou Valkey, com Sentinel para failover.
Nota de engenharia: API Redis padrão; migração via SLAVEOF ou transferência de RDB.

Heroku Connect (Salesforce sync)

O que usamos no lugar: Binadit DevOps & Support. Integration workers em execução na sua própria infraestrutura, comunicando diretamente com a API do fornecedor.
Nota de engenharia: Para equipas que mantêm o Salesforce CRM, a camada de sincronização é reconstruída; para equipas que substituem o Salesforce, esta preocupação desaparece.

Add-ons marketplace

O que usamos no lugar: Binadit DevOps & Support. Os componentes que efetivamente utiliza, implementados e operados como parte da sua stack.
Nota de engenharia: A conveniência dos add-ons do Heroku é a maior perda de DX; a gestão direta de fornecedores é o trade-off pela soberania.

Pipelines (review apps, CI/CD)

O que usamos no lugar: Binadit DevOps & Support. Ambientes de revisão por branch no Kubernetes, criados e destruídos pelo GitLab CI.
Nota de engenharia: O Coolify suporta ambientes de preview por branch.

Heroku Buildpacks

O que usamos no lugar: Binadit DevOps & Support. Dockerfiles ou Cloud Native Buildpacks, construídos no GitLab CI.
Nota de engenharia: A maioria das apps Heroku faz deploy sem alterações via Cloud Native Buildpacks no Coolify.

Logplex / Logging

O que usamos no lugar: Binadit Managed Cloud Platform. Loki para agregação, com Grafana para consultas e políticas de retenção por stream.
Nota de engenharia: Loki é o padrão; agrega logs de todos os containers.

Heroku CI

O que usamos no lugar: Binadit DevOps & Support. GitLab CI com runners na sua própria infraestrutura.
Nota de engenharia: GitLab CI num runner self-hosted na UE é o substituto de nível de produção.

Heroku Private Spaces

O que usamos no lugar: Binadit Private Infrastructure. Ambiente totalmente isolado, hardware dedicado, arquitetura de rede personalizada.
Nota de engenharia: O conceito de "Private Spaces" é uma VPC com outro nome; a rede padrão europeia trata disso.

SSL / domains

O que usamos no lugar: Binadit Managed Cloud Platform. cert-manager com Let's Encrypt, com renovação automática.
Nota de engenharia: A transferência de domínio é uma mudança de registrar; o SSL é automatizado por todas as alternativas PaaS modernas.

Como migramos de Heroku (Salesforce)

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Days 1-3

PaaS choice + dependency map

Decide on the EU PaaS (Coolify is our default for Heroku-style DX; Dokku for minimalists; managed offering from Binadit for hands-off teams). Inventory Heroku apps, dynos and add-ons.
Days 4-10

Database + add-on swap

Heroku Postgres replicated to EU managed PostgreSQL with logical replication. Each add-on replaced with EU equivalent (one-by-one to control risk). Logging migrated to Loki.
Weeks 2-4

Application cutover

Apps redeployed on Coolify with the same buildpacks. DNS cutover with low TTL window. Heroku app archived after a verification period.

5-year TCO on Heroku exits: 60-85% cheaper. Heroku's pricing model (per-dyno, per-add-on, per-database tier) compounds quickly; a self-hosted PaaS on EU infrastructure replaces a typical $500-2000/month Heroku bill for a fraction of that in raw infrastructure, plus our managed fee if you do not want to operate it yourself.

Perguntas frequentes

Ver todas as perguntas frequentes

Is Heroku's EU region sufficient for GDPR?

Residency only. Heroku's "Common Runtime" EU region runs in AWS Ireland - that is two layers of US-controlled processors (Salesforce as the immediate contracting party, AWS as the underlying infrastructure). The CLOUD Act analysis applies to both. For Schrems II-strict workloads, Heroku EU is not sufficient.

Will we lose the Heroku DX?

Coolify reproduces git-push deploys, one-click app templates, preview environments per PR, automated SSL, environment variables, and per-branch deploys. The DX is genuinely close. The main loss is the add-on marketplace; you swap that for direct vendor relationships, which is more manageable than Heroku marketing suggests.

What about Heroku Connect for Salesforce sync?

If you're keeping Salesforce CRM, Heroku Connect needs to be rebuilt (REST/Bulk API + queue). If you're also moving off Salesforce - which is increasingly common in Schrems II-driven exits - this concern disappears.

Can we use Coolify ourselves or do we need help?

Many teams self-host Coolify successfully on a single VM. For multi-tenant production scenarios - multi-environment, blue-green, secrets management - a managed-partner setup makes sense. We deploy and operate Coolify clusters for clients.

How long does a Heroku exit take?

For a small workload (1-3 apps, 1 Postgres, a few add-ons): 1-2 weeks. For a multi-app enterprise Heroku setup with Private Spaces and Heroku Connect: 6-10 weeks. Heroku's app surface is intentionally simple, which makes the migration mostly a choreography exercise.

What about the newer Heroku-style platforms?

They reproduce the developer experience well, and if that is all you need they are a reasonable landing. Check two things before you commit: which jurisdiction the platform and its database sit under, and what the exit looks like in two years. A platform that builds from your Dockerfile onto infrastructure you could run yourself is a much shorter conversation later than one with a proprietary build and runtime.

Planeie a sua saída de Heroku (Salesforce).

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor