Alternativa solo UE a DigitalOcean.

DigitalOcean è il cloud statunitense pensato per gli sviluppatori - prezzi competitivi, UX pulita e una regione Amsterdam che induce molti team EU a pensare che la questione della residenza dei dati sia risolta. Non è così: DigitalOcean LLC è una società del Delaware, il suo datacenter di Amsterdam è gestito sotto controllo societario statunitense, e il CLOUD Act si applica. La buona notizia è che la migrazione da DigitalOcean a un'infrastruttura di giurisdizione EU che eseguiamo per te è una delle più agevoli di questa guida - la superficie API di DigitalOcean è piccola, e la maggior parte dei workload migrati riporta bollette più basse e prestazioni uguali o migliori.

Stati Uniti Stack sostitutivo, solo UE 12 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: DigitalOcean
Sede: New York, NY
Giurisdizione: Stati Uniti
Regime giuridico: CLOUD Act, FISA 702

"Regione UE" non è sovranità. Quattro domande decidono.

La residenza dei dati dice dove si trovano i bit. La sovranità dice quale sistema giuridico può imporne l'accesso. La risposta deve reggere su tutti e quattro i punti, altrimenti lo stack non è sovrano.

Residenza

Dove sono fisicamente archiviati i dati?

Non "nel cloud": quale datacenter, in quale paese, sotto quale giurisdizione.

Sub-responsabili

Chi altro è nel suo percorso dei dati?

Ogni fornitore che tocca i dati: il CDN, il relay e-mail, il tracker degli errori, la pipeline di analytics.

Giurisdizione

Quali leggi possono imporre la divulgazione?

Un fornitore con sede negli Stati Uniti ricade sotto FISA 702 e CLOUD Act, anche se i bit si trovano a Francoforte.

Custodia delle chiavi

Chi detiene effettivamente le chiavi di cifratura?

Se il provider cloud detiene sia i dati sia le chiavi, può leggerli, indipendentemente da qualsiasi DPA.

Non supera AWS · Azure · GCP · Regione UE

Fallisce su giurisdizione e custodia delle chiavi.

Bit nell'UE, casa madre statunitense, sub-responsabili americani nel percorso predefinito, chiavi gestite dal fornitore.

Supera Stack gestito da Binadit

Passa su tutte e quattro.

Ospitato in UE su infrastruttura con sede europea. Zero sub-responsabili statunitensi nel percorso predefinito. Chiavi del cliente o di KMS europeo. Elencati per nome nel suo DPA Articolo 28.

Perché i team se ne vanno DigitalOcean

Le uscite da DigitalOcean che abbiamo gestito derivano quasi sempre da un unico fattore scatenante: un audit del cliente (B2B SaaS) o una revisione di compliance in cui "DigitalOcean Amsterdam" è risultato insufficiente ai sensi di Schrems II, costringendo il cliente ad aggiungere misure supplementari costose (crittografia BYOK che vanifica il valore del servizio gestito) oppure a migrare. Migrare è di solito l'opzione più economica. Il lavoro tecnico è limitato perché il set di prodotti di DigitalOcean è volutamente minimale, il che rende semplice la mappatura verso l'EU.

DigitalOcean servizi e i loro equivalenti solo UE

Una migrazione non è "scambiare una scatola con un'altra". La mappatura sottostante è ciò che eseguiamo per i clienti che lasciano DigitalOcean in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

DigitalOcean servizio	Cosa usiamo al suo posto	Nota di ingegneria
Droplets	Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.	Dimensioniamo le istanze in base al tuo effettivo profilo di carico e non a un livello di catalogo, così la maggior parte delle migrazioni si conclude con meno macchine, meglio utilizzate.
Spaces (object storage)	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.	Compatibile S3 su tutte le opzioni; la migrazione richiede solo la modifica di un endpoint nella configurazione dell'SDK.
Managed Databases (PostgreSQL, MySQL, Redis)	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.	La replica in streaming ci permette di effettuare il cutover con pochi secondi di downtime invece di una finestra di manutenzione, e i ripristini vengono testati secondo una pianificazione invece di essere dati per scontati.
App Platform (PaaS)	Binadit Managed Cloud Platform. Immagini Docker costruite in GitLab CI e distribuite su Kubernetes, con ambienti di review per ogni branch.	App Platform non ha un equivalente sovrano diretto a livello PaaS. Coolify (open-source self-hosted) offre una UX in stile Heroku su infrastruttura EU.
Kubernetes (DOKS)	Binadit Managed Cloud Platform. Kubernetes su Debian o Talos, con networking Cilium e cert-manager per i certificati.	I tuoi manifest e Helm chart si spostano così come sono. Ciò che cambia è la ingress class e la storage class, e ce ne occupiamo noi.
Load Balancers	Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived per il failover.	Per la maggior parte dei casi d'uso il LB gestito sui provider UE è sufficiente; per regole avanzate, HAProxy su una piccola VM è il pattern standard.
Volumes (block storage)	Binadit Managed Cloud Platform. Ceph RBD, o Longhorn per volumi Kubernetes-native.	Storage a blocchi basato su NVMe standard su tutte le opzioni EU; le prestazioni sono comparabili o superiori.
DNS (DigitalOcean DNS)	Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.	La migrazione consiste in un export e re-import della zona; pochi minuti di lavoro.
Floating IPs	Binadit Managed Cloud Platform. Allocazione di IP statici con keepalived per il failover tra i nodi.	Tutti i provider offrono il pattern equivalente di failover-IP.
CDN (DigitalOcean CDN)	Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.	Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.
Monitoring (DO Monitoring)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.	OpenTelemetry rende l'instrumentazione portabile, e non c'è un pricing per-metrica o per-trace da aggirare in fase di design, quindi i team smettono di campionare via i dati di cui hanno bisogno.
Container Registry	Binadit DevOps & Support. Harbor o il container registry di GitLab, con vulnerability scanning al push.	Harbor è il registry open-source di livello produzione; lo gestiamo per i clienti.

Droplets

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.
Nota di ingegneria: Dimensioniamo le istanze in base al tuo effettivo profilo di carico e non a un livello di catalogo, così la maggior parte delle migrazioni si conclude con meno macchine, meglio utilizzate.

Spaces (object storage)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.
Nota di ingegneria: Compatibile S3 su tutte le opzioni; la migrazione richiede solo la modifica di un endpoint nella configurazione dell'SDK.

Managed Databases (PostgreSQL, MySQL, Redis)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.
Nota di ingegneria: La replica in streaming ci permette di effettuare il cutover con pochi secondi di downtime invece di una finestra di manutenzione, e i ripristini vengono testati secondo una pianificazione invece di essere dati per scontati.

App Platform (PaaS)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Immagini Docker costruite in GitLab CI e distribuite su Kubernetes, con ambienti di review per ogni branch.
Nota di ingegneria: App Platform non ha un equivalente sovrano diretto a livello PaaS. Coolify (open-source self-hosted) offre una UX in stile Heroku su infrastruttura EU.

Kubernetes (DOKS)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Kubernetes su Debian o Talos, con networking Cilium e cert-manager per i certificati.
Nota di ingegneria: I tuoi manifest e Helm chart si spostano così come sono. Ciò che cambia è la ingress class e la storage class, e ce ne occupiamo noi.

Load Balancers

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived per il failover.
Nota di ingegneria: Per la maggior parte dei casi d'uso il LB gestito sui provider UE è sufficiente; per regole avanzate, HAProxy su una piccola VM è il pattern standard.

Volumes (block storage)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Ceph RBD, o Longhorn per volumi Kubernetes-native.
Nota di ingegneria: Storage a blocchi basato su NVMe standard su tutte le opzioni EU; le prestazioni sono comparabili o superiori.

DNS (DigitalOcean DNS)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.
Nota di ingegneria: La migrazione consiste in un export e re-import della zona; pochi minuti di lavoro.

Floating IPs

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Allocazione di IP statici con keepalived per il failover tra i nodi.
Nota di ingegneria: Tutti i provider offrono il pattern equivalente di failover-IP.

CDN (DigitalOcean CDN)

Cosa usiamo al suo posto: Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.
Nota di ingegneria: Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.

Monitoring (DO Monitoring)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.
Nota di ingegneria: OpenTelemetry rende l'instrumentazione portabile, e non c'è un pricing per-metrica o per-trace da aggirare in fase di design, quindi i team smettono di campionare via i dati di cui hanno bisogno.

Container Registry

Cosa usiamo al suo posto: Binadit DevOps & Support. Harbor o il container registry di GitLab, con vulnerability scanning al push.
Nota di ingegneria: Harbor è il registry open-source di livello produzione; lo gestiamo per i clienti.

Come migriamo da DigitalOcean

Una tipica migrazione di mid-market si svolge in tre fasi. I numeri qui sotto assumono un team di ingegneria di 6-10 persone e uno stack applicativo moderatamente complesso.

Giorni 1-3

Inventario e dipendenze

Elenca ogni Droplet, Database, Space e deployment su App Platform. Identifica eventuali API specifiche di DigitalOcean o automazioni doctl da riscrivere. Output: piano di migrazione pulito senza sorprese.
Giorni 4-10

Prima le dipendenze soft

DNS, Spaces e CDN spostati per primi. Repliche del database pre-staged su servizio gestito EU. Container registry spostato su Harbor. Monitoring su Prometheus EU.
Settimane 2-5

Cutover Compute & DB

Droplets riprovisionati su compute Binadit con le stesse immagini. Cutover del database con replica logica. Workload App Platform migrati a Kubernetes su Binadit. Cutover del load balancer con shift DNS.

TCO a 5 anni su un'uscita da DigitalOcean: tipicamente il 40-60% più economico, con i risparmi maggiori su compute, dove specifiche equivalenti costano tipicamente circa la metà, e sui database gestiti. Dove DigitalOcean ha un vantaggio è l'esperienza utente di App Platform, che lo stack sovrano UE sostituisce con Coolify o un PaaS self-managed.

Domande frequenti

Visualizza tutte le domande frequenti

DigitalOcean ha datacenter ad Amsterdam e Francoforte - questo soddisfa il GDPR?

Residenza sì, sovranità no. Il DC di Amsterdam è di proprietà e gestito da DigitalOcean LLC, un'entità sotto controllo statunitense. Il CLOUD Act consente alle autorità statunitensi di richiedere la divulgazione di dati ovunque nel mondo. Per workload attenti a Schrems II, tale esposizione non è risolta dalla posizione geografica del datacenter.

L'affidabilità ne risentirà se lasciamo DigitalOcean?

Non nella nostra esperienza, ma la risposta onesta è che l'affidabilità deriva più dall'architettura che da un logo. Un'istanza singola senza failover è fragile ovunque. Ciò che costruiamo invece è ridondanza ai livelli che contano: database replicati con failover testato, load balancing tra i nodi, e monitoraggio che ci avvisa prima che se ne accorgano i vostri clienti. È questa la parte della migrazione che cambia il vostro uptime, non la scelta del datacenter.

E per quanto riguarda la sostituzione specifica di App Platform?

App Platform è genuinamente utile per i piccoli team che non vogliono gestire l'infrastruttura. Coolify, self-hosted e open source, offre un'esperienza App Platform comparabile su compute UE. Per i team che lo vogliono managed, gestiamo la container platform per voi.

Possiamo migrare gradualmente o deve essere fatto tutto in una volta?

Il graduale è la norma. Eseguire entrambi i provider in parallelo tramite suddivisione del traffico a livello DNS, migrare workload per workload, dismettere DigitalOcean una volta spostato l'ultimo servizio. Tempo trascorso tipico: 4-8 settimane per workload mid-market, 2-4 settimane per quelli piccoli.

Quanto tempo richiede un'uscita da DigitalOcean?

Per un workload tipico (5-20 Droplet, 1-2 database gestiti, Spaces, DNS): 3-6 settimane di tempo trascorso. Con un partner di infrastruttura gestita a guidarla: 2-4 settimane. Il lavoro tecnico è leggero; il programma è determinato dai gate di validazione e dalla disponibilità del team.

La migrazione creerà downtime?

No, se eseguita correttamente. La migrazione del database utilizza la replica logica, quindi il passaggio finale è un semplice cambio di DNS o di stringa di connessione. La migrazione del compute utilizza il blue-green a livello di load balancer o DNS. Lo storage a oggetti utilizza il dual-write durante la finestra di migrazione. Lo zero-downtime è l'aspettativa standard.

Pianifica la tua uscita da DigitalOcean.

Chiamata di scoping di 30 minuti. Mappiamo il tuo stack rispetto alle alternative solo UE, stimiamo lo sforzo di migrazione e ti diciamo se è la scelta giusta.

Prenota una chiamata Confronta un altro provider