Alternativa apenas UE a DigitalOcean.

DigitalOcean is the developer-first US cloud - competitive pricing, clean UX, and an Amsterdam region that lulls many EU teams into thinking the residency question is solved. It is not: DigitalOcean LLC is a Delaware company, its Amsterdam datacenter is operated under US corporate control, and the CLOUD Act applies. The good news is that the migration from DigitalOcean to EU-jurisdictional infrastructure we run for you is one of the cleanest in this guide - DigitalOcean's API surface is small, and most workloads moved off it report lower bills and equal or better performance.

United States 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: 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 DigitalOcean

DigitalOcean exits we have run almost always come from one trigger: a customer audit (B2B SaaS) or compliance review where "DigitalOcean Amsterdam" was found to be insufficient under Schrems II, and the client either had to add expensive supplementary measures (BYOK encryption that defeats the managed-service value) or migrate. Migrating is usually the cheaper option. The technical work is light because DigitalOcean's product set is intentionally minimal, which makes the EU mapping uncomplicated.

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.

Days 1-3

Inventory & dependencies

List every Droplet, Database, Space and App Platform deployment. Identify any DigitalOcean-specific APIs or doctl automations that need rewriting. Output: clean migration plan with no surprises.
Days 4-10

Soft dependencies first

DNS, Spaces and CDN moved first. Database replicas pre-staged on EU managed service. Container registry moved to Harbor. Monitoring on EU Prometheus.
Weeks 2-5

Compute & DB cutover

Droplets reprovisioned on Binadit compute with the same images. Database cutover with logical replication. App Platform workloads moved to Kubernetes on Binadit. Load Balancer cutover with DNS shift.

5-year TCO on a DigitalOcean exit: typically 40-60% cheaper, with the largest savings on compute, where equivalent specs are typically around half the price, and on managed databases. Where DigitalOcean has the edge is App Platform UX, which the EU sovereign stack replaces with Coolify or self-managed PaaS.

Perguntas frequentes

Ver todas as perguntas frequentes

DigitalOcean has datacenters in Amsterdam and Frankfurt - does that satisfy GDPR?

Residency yes, sovereignty no. The Amsterdam DC is owned and operated by DigitalOcean LLC, a US-controlled entity. The CLOUD Act allows US authorities to compel disclosure of data anywhere globally. For Schrems II-conscious workloads, that exposure is not addressed by the datacenter location.

Will reliability suffer if we leave DigitalOcean?

Not in our experience, but the honest answer is that reliability comes from architecture more than from a logo. A single instance with no failover is fragile anywhere. What we build instead is redundancy at the layers that matter: replicated databases with tested failover, load balancing across nodes, and monitoring that tells us before it tells your customers. That is the part of the move that changes your uptime, not the choice of datacentre.

What about App Platform replacement specifically?

App Platform is genuinely useful for small teams that don't want to operate infrastructure. Coolify, self-hosted and open source, gives a comparable App Platform experience on EU compute. For teams that want it managed, we run the container platform for you.

Can we migrate gradually or does it have to be all-at-once?

Gradual is the norm. Run both providers in parallel via DNS-level traffic split, migrate workload-by-workload, decommission DigitalOcean once the last service is moved. Typical elapsed time: 4-8 weeks for mid-market workloads, 2-4 weeks for small ones.

How long does a DigitalOcean exit take?

For a typical workload (5-20 Droplets, 1-2 managed databases, Spaces, DNS): 3-6 weeks elapsed time. With a managed-infrastructure partner driving it: 2-4 weeks. The technical work is light; the schedule is determined by validation gates and team availability.

Will the migration create downtime?

No, when done properly. Database migration uses logical replication so the cutover is a single DNS or connection-string change. Compute migration uses blue-green at the load balancer or DNS level. Object storage uses dual-write during the migration window. Zero-downtime is the standard expectation.

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