Alternativa apenas UE a Heroku (Salesforce).

O Heroku é a PaaS original centrada no programador, adquirida pela Salesforce em 2010 e atualmente parte da Salesforce.com Inc. A Salesforce é uma empresa dos EUA, a região por defeito do Heroku é nos EUA, e o "Common Runtime" da UE reside na AWS Irlanda - o que significa que a sua aplicação Heroku está em infraestrutura AWS, com a Salesforce como processador contratual. Ambas as camadas estão sob jurisdição dos EUA. A alternativa soberana é direta: uma PaaS self-hosted como Coolify ou Dokku em infraestrutura da UE, ou um equivalente totalmente gerido operado por um parceiro da UE.

Estados Unidos 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: Estados Unidos
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)

As saídas do Heroku que já executámos surgem de três fatores: uma auditoria de cliente (SaaS B2B) a assinalar o caminho de dados AWS-Irlanda-via-Heroku como exposto ao Schrems II, a descontinuação dos dynos gratuitos em 2022 a forçar uma reavaliação de custos, ou uma decisão estratégica de remover a dupla cadeia de fornecedores (Salesforce → AWS) que complica a gestão de DPAs. O valor do Heroku é a experiência de programador; alternativas open source como Coolify, Dokku e Caprover reproduzem a maior parte dessa experiência em infraestrutura da UE.

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.

Dias 1-3

Escolha de PaaS + mapa de dependências

Decidir sobre o PaaS na UE (Coolify é a nossa opção padrão para DX ao estilo Heroku; Dokku para minimalistas; oferta managed da Binadit para equipas que preferem não gerir nada). Inventariar apps Heroku, dynos e add-ons.
Dias 4-10

Troca de base de dados + add-on

O Heroku Postgres é replicado para PostgreSQL gerido da UE com replicação lógica. Cada add-on é substituído por um equivalente da UE (um a um, para controlar o risco). O logging é migrado para Loki.
Semanas 2-4

Cutover da aplicação

Apps redeployed no Coolify com os mesmos buildpacks. Cutover de DNS com janela de TTL baixo. App do Heroku arquivada após um período de verificação.

TCO a 5 anos em saídas da Heroku: 60-85% mais barato. O modelo de pricing da Heroku (por dyno, por add-on, por tier de base de dados) acumula-se rapidamente; um PaaS self-hosted em infraestrutura da UE substitui uma fatura típica de $500-2000/mês na Heroku por uma fração desse valor em infraestrutura pura, mais a nossa taxa managed caso não queira operá-lo você mesmo.

Perguntas frequentes

Ver todas as perguntas frequentes

A região UE do Heroku é suficiente para o RGPD?

Apenas residência. A região EU do "Common Runtime" da Heroku roda na AWS Irlanda - ou seja, duas camadas de processadores controlados pelos EUA (a Salesforce como parte contratante direta, a AWS como infraestrutura subjacente). A análise do CLOUD Act aplica-se a ambas. Para workloads que exigem conformidade estrita com o Schrems II, o Heroku EU não é suficiente.

Vamos perder a DX da Heroku?

O Coolify reproduz deploys via git-push, templates de aplicações one-click, ambientes de preview por PR, SSL automatizado, variáveis de ambiente e deploys por branch. A DX é genuinamente próxima. A principal perda é o marketplace de add-ons; troca-se isso por relações diretas com fornecedores, o que é mais gerível do que o marketing da Heroku sugere.

E quanto ao Heroku Connect para sincronização com o Salesforce?

Se mantiver o Salesforce CRM, o Heroku Connect precisa de ser reconstruído (REST/Bulk API + fila). Se também estiver a sair do Salesforce - o que é cada vez mais comum em saídas motivadas pelo Schrems II - esta preocupação desaparece.

Podemos usar o Coolify nós próprios ou precisamos de ajuda?

Muitas equipas fazem self-host do Coolify com sucesso numa única VM. Para cenários de produção multi-tenant - multi-ambiente, blue-green, gestão de secrets - uma configuração com parceiro gerido faz sentido. Nós implementamos e operamos clusters Coolify para clientes.

Quanto tempo demora uma saída do Heroku?

Para uma carga de trabalho pequena (1-3 apps, 1 Postgres, alguns add-ons): 1-2 semanas. Para uma configuração Heroku empresarial multi-app com Private Spaces e Heroku Connect: 6-10 semanas. A superfície de aplicações do Heroku é propositadamente simples, o que torna a migração sobretudo um exercício de coreografia.

E quanto às plataformas mais recentes no estilo Heroku?

Reproduzem bem a experiência de developer, e se é tudo o que precisa, são um ponto de partida razoável. Verifique duas coisas antes de se comprometer: sob que jurisdição está a plataforma e a sua base de dados, e como será a saída daqui a dois anos. Uma plataforma que faz build a partir do seu Dockerfile para infraestrutura que você próprio poderia operar é uma conversa muito mais curta mais tarde do que uma com build e runtime proprietários.

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