Alternativa apenas UE a DigitalOcean.

A DigitalOcean é a cloud americana pensada para desenvolvedores - preços competitivos, UX limpa, e uma região em Amsterdã que leva muitas equipas europeias a pensar que a questão da residência de dados está resolvida. Não está: a DigitalOcean LLC é uma empresa do Delaware, o seu datacenter em Amsterdã é operado sob controlo corporativo dos EUA, e o CLOUD Act aplica-se. A boa notícia é que a migração da DigitalOcean para infraestrutura sob jurisdição da UE que realizamos por si é uma das mais limpas deste guia - a superfície de API da DigitalOcean é pequena, e a maioria dos workloads migrados reportam faturas mais baixas e desempenho igual ou melhor.

Estados Unidos Stack de substituição, apenas UE 12 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: DigitalOcean
Sede: New York, NY
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 DigitalOcean

As saídas da DigitalOcean que executámos surgem quase sempre de um único gatilho: uma auditoria de cliente (B2B SaaS) ou uma revisão de compliance em que se verificou que "DigitalOcean Amsterdam" era insuficiente sob o Schrems II, e o cliente teve de adicionar medidas suplementares dispendiosas (encriptação BYOK que anula o valor do managed service) ou migrar. Migrar costuma ser a opção mais económica. O trabalho técnico é reduzido porque o conjunto de produtos da DigitalOcean é intencionalmente minimalista, o que torna o mapeamento para a UE simples.

DigitalOcean 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 DigitalOcean com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

DigitalOcean serviço	O que usamos no lugar	Nota de engenharia
Droplets	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	Dimensionamos as instâncias de acordo com o seu perfil de carga real, em vez de um tier de catálogo, pelo que a maioria das migrações resulta em menos máquinas, e melhor utilizadas.
Spaces (object storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	Compatível com S3 em todas as opções; a migração resume-se a uma alteração de endpoint na configuração do SDK.
Managed Databases (PostgreSQL, MySQL, Redis)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A replicação em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.
App Platform (PaaS)	Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.	O App Platform não tem um equivalente soberano direto ao nível de PaaS. O Coolify (open-source, self-hosted) oferece uma UX semelhante ao Heroku em infraestrutura europeia.
Kubernetes (DOKS)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	Os seus manifests e Helm charts são migrados tal como estão. O que muda é a ingress class e a storage class, e nós tratamos de ambas.
Load Balancers	Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.	Para a maioria dos casos de uso, o LB gerido em fornecedores da UE é suficiente; para regras avançadas, HAProxy numa VM pequena é o padrão standard.
Volumes (block storage)	Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.	Block storage baseado em NVMe padrão em todas as opções europeias; o desempenho é comparável ou superior.
DNS (DigitalOcean DNS)	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	A migração é uma exportação e reimportação de zona; alguns minutos de trabalho.
Floating IPs	Binadit Managed Cloud Platform. Alocação de IP estático com keepalived para failover entre nós.	Todos os provedores oferecem o padrão equivalente de failover-IP.
CDN (DigitalOcean CDN)	Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.	A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.
Monitoring (DO Monitoring)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.	O OpenTelemetry torna a instrumentação portátil, e não existe preço por métrica ou por trace a contornar, pelo que as equipas deixam de amostrar e perder os dados de que precisam.
Container Registry	Binadit DevOps & Support. Harbor ou o container registry do GitLab, com vulnerability scanning a cada push.	O Harbor é o registry open-source de nível de produção; operamo-lo para clientes.

Droplets

O que usamos no lugar: Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia: Dimensionamos as instâncias de acordo com o seu perfil de carga real, em vez de um tier de catálogo, pelo que a maioria das migrações resulta em menos máquinas, e melhor utilizadas.

Spaces (object storage)

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: Compatível com S3 em todas as opções; a migração resume-se a uma alteração de endpoint na configuração do SDK.

Managed Databases (PostgreSQL, MySQL, Redis)

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 em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.

App Platform (PaaS)

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 App Platform não tem um equivalente soberano direto ao nível de PaaS. O Coolify (open-source, self-hosted) oferece uma UX semelhante ao Heroku em infraestrutura europeia.

Kubernetes (DOKS)

O que usamos no lugar: Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
Nota de engenharia: Os seus manifests e Helm charts são migrados tal como estão. O que muda é a ingress class e a storage class, e nós tratamos de ambas.

Load Balancers

O que usamos no lugar: Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
Nota de engenharia: Para a maioria dos casos de uso, o LB gerido em fornecedores da UE é suficiente; para regras avançadas, HAProxy numa VM pequena é o padrão standard.

Volumes (block storage)

O que usamos no lugar: Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.
Nota de engenharia: Block storage baseado em NVMe padrão em todas as opções europeias; o desempenho é comparável ou superior.

DNS (DigitalOcean DNS)

O que usamos no lugar: Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia: A migração é uma exportação e reimportação de zona; alguns minutos de trabalho.

Floating IPs

O que usamos no lugar: Binadit Managed Cloud Platform. Alocação de IP estático com keepalived para failover entre nós.
Nota de engenharia: Todos os provedores oferecem o padrão equivalente de failover-IP.

CDN (DigitalOcean CDN)

O que usamos no lugar: Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
Nota de engenharia: A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.

Monitoring (DO Monitoring)

O que usamos no lugar: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.
Nota de engenharia: O OpenTelemetry torna a instrumentação portátil, e não existe preço por métrica ou por trace a contornar, pelo que as equipas deixam de amostrar e perder os dados de que precisam.

Container Registry

O que usamos no lugar: Binadit DevOps & Support. Harbor ou o container registry do GitLab, com vulnerability scanning a cada push.
Nota de engenharia: O Harbor é o registry open-source de nível de produção; operamo-lo para clientes.

Como migramos de DigitalOcean

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

Inventário e dependências

Liste todos os Droplets, Databases, Spaces e implementações em App Platform. Identifique quaisquer APIs específicas da DigitalOcean ou automações doctl que precisem de ser reescritas. Resultado: plano de migração claro e sem surpresas.
Dias 4-10

Dependências soft primeiro

DNS, Spaces e CDN movidos primeiro. Réplicas de base de dados pré-configuradas em managed service na UE. Container registry movido para Harbor. Monitoring em Prometheus na UE.
Semanas 2-5

Cutover de Compute & DB

Droplets reaprovisionados em compute Binadit com as mesmas imagens. Migração de base de dados com replicação lógica. Workloads da App Platform migrados para Kubernetes na Binadit. Migração do Load Balancer com mudança de DNS.

TCO a 5 anos numa saída do DigitalOcean: normalmente 40-60% mais barato, com as maiores poupanças em compute, onde specs equivalentes custam tipicamente cerca de metade do preço, e em bases de dados managed. Onde o DigitalOcean tem vantagem é na UX da App Platform, que a stack soberana da UE substitui com Coolify ou PaaS self-managed.

Perguntas frequentes

Ver todas as perguntas frequentes

A DigitalOcean tem datacenters em Amsterdam e Frankfurt - isso satisfaz o GDPR?

Residência sim, soberania não. O datacenter de Amsterdã é propriedade e operado pela DigitalOcean LLC, uma entidade controlada pelos EUA. O CLOUD Act permite que as autoridades dos EUA exijam a divulgação de dados em qualquer parte do mundo. Para workloads sensíveis ao Schrems II, essa exposição não é resolvida pela localização do datacenter.

A fiabilidade será afetada se deixarmos a DigitalOcean?

Não é essa a nossa experiência, mas a resposta honesta é que a fiabilidade vem mais da arquitetura do que de um logótipo. Uma única instância sem failover é frágil em qualquer lugar. O que construímos, em vez disso, é redundância nas camadas que importam: bases de dados replicadas com failover testado, load balancing entre nós, e monitorização que nos avisa antes de avisar os seus clientes. É essa parte da mudança que altera o seu uptime, não a escolha do datacenter.

E quanto à substituição específica da App Platform?

A App Platform é genuinamente útil para pequenas equipas que não querem operar infraestrutura. O Coolify, self-hosted e open source, oferece uma experiência comparável à App Platform em compute na UE. Para equipas que a querem gerenciada, nós operamos a container platform por si.

Podemos migrar gradualmente ou tem de ser tudo de uma vez?

O gradual é a norma. Correr ambos os fornecedores em paralelo através de divisão de tráfego ao nível de DNS, migrar workload a workload, desativar o DigitalOcean assim que o último serviço for movido. Tempo decorrido típico: 4-8 semanas para workloads de mid-market, 2-4 semanas para os pequenos.

Quanto tempo demora uma saída do DigitalOcean?

Para uma carga de trabalho típica (5-20 Droplets, 1-2 bases de dados geridas, Spaces, DNS): 3-6 semanas de tempo decorrido. Com um parceiro de infraestrutura gerida a conduzir o processo: 2-4 semanas. O trabalho técnico é leve; o cronograma é determinado pelos gates de validação e pela disponibilidade da equipa.

A migração criará downtime?

Não, quando feita corretamente. A migração de base de dados usa replicação lógica, pelo que o cutover é uma única alteração de DNS ou de connection string. A migração de compute usa blue-green ao nível do load balancer ou do DNS. O object storage usa dual-write durante a janela de migração. Zero downtime é a expectativa padrão.

Planeie a sua saída de DigitalOcean.

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