Ogni settimana parlo con il proprietario di un hotel a Merano, un negozio a Bolzano, o una piccola agenzia da qualche parte in Val d'Isarco che mi dice di essere "sul cloud." Quello che intendono, quasi sempre, è che il loro sito è su un piano di hosting condiviso gestito da una server room in Virginia o Iowa. I dati, moduli di prenotazione, richieste di contatto, iscrizioni alla newsletter, vivono negli USA, su infrastrutture governate dalla legge americana, soggette a richieste del governo americano. È una situazione completamente evitabile, e questo articolo spiega perché è importante e cosa fare invece.
Dove vivono i tuoi dati è una questione legale, non solo tecnica
Il GDPR non è stato scritto per essere fastidioso. È stato scritto perché l'UE ha deciso che i dati personali dei suoi residenti meritano una protezione reale, anche da governi e aziende straniere. Quando un'azienda altoatesina conserva i dati dei clienti su infrastrutture americane, entra in un mondo complicato di Clausole Contrattuali Standard, Accordi per il Trattamento dei Dati e framework per il trasferimento dati UE, USA che sono stati contestati in tribunale, e annullati, due volte nell'ultimo decennio.
Operare su infrastrutture europee non rende automatica la conformità GDPR. Hai ancora bisogno di un corretto consenso ai cookie, delle giuste informative sul trattamento dei dati, e tutto il resto. Ma elimina la domanda più difficile: "Stai trasferendo dati personali verso un paese terzo?" Se il tuo server è in Germania e i backup sono in Finlandia, la risposta è no. Quella risposta semplifica considerevolmente la tua esposizione legale.
L'argomento dei costi non è nemmeno paragonabile
Un Hetzner CPX31, quattro vCPU dedicate, 8 GB di RAM, 160 GB NVMe e 20 TB di traffico in uscita, costa circa 15 EUR al mese. L'equivalente AWS più vicino, una volta aggiunto lo storage EBS e calcolato l'egress reale a qualsiasi volume, supera gli 80 EUR. Non è un margine. È cinque volte il denaro per un'infrastruttura fisicamente più lontana dai tuoi utenti.
Per il sito di un hotel con moduli di prenotazione, un ristorante con un menu PDF e una pagina di contatto, o un negozio al dettaglio con un piccolo catalogo prodotti, il carico di lavoro si adatta comodamente su un VPS Hetzner da 15-20 EUR. Gestisco questo sito più diversi progetti per clienti su un server e il conto non è cambiato in due anni. Le fatture del cloud americano tendono a salire. Quelle di Hetzner no.
La distanza fisica conta per le prestazioni
La luce viaggia veloce, ma non infinitamente veloce. Un server a Norimberga è a circa 700 km da Bolzano. Un server in Virginia è a circa 8.000 km. Questa differenza si traduce in latenza, il ritardo tra un utente che clicca un link e la risposta del server. Per una pagina server-rendered non cachata, la differenza può essere di 60-120 ms o più. Non è invisibile. I Core Web Vitals di Google misurano il Time to First Byte, e un server sullo stesso continente dei tuoi visitatori è un miglioramento gratuito delle prestazioni che nessuna ottimizzazione del codice può replicare completamente.
- Norimberga, Bolzano: ~700 km, ~5-10 ms di latenza di rete base
- Virginia, Bolzano: ~8.000 km, ~80-120 ms di latenza di rete base
- Helsinki (Hetzner), Bolzano: ~2.000 km, ~25-35 ms di latenza di rete base
- Cloudflare CDN davanti elimina la latenza per gli asset cachati indipendentemente dall'origin
- Le pagine server-rendered e le chiamate API dipendono ancora dal tempo di risposta dell'origin
La vera proprietà significa poter spostare, verificare e controllare
Il problema silenzioso dei grandi cloud gestiti è il vendor lock-in. Non un lock-in tecnico, puoi sempre migrare, ma psicologico. Più servizi adotti, più lo spostamento sembra un intervento chirurgico. Hetzner è un VPS Linux. Possiedi l'accesso root. Puoi fare uno snapshot, spostarlo su qualsiasi altro provider VPS nel mondo ed essere operativo entro un'ora. I backup sono dump SQL standard in un bucket compatibile S3 che controlli tu. Non c'è nulla di proprietario da sbrogliare.
Anche la verifica è semplice. Puoi vedere esattamente cosa è installato, cosa è in ascolto su quale porta e dove sono i dati. Per un imprenditore che deve mostrare a un revisore GDPR dove sono conservati i dati dei clienti e chi vi ha accesso, questa chiarezza è preziosa. Un setup AWS multi-account con dati sparsi su servizi gestiti è molto più difficile da spiegare.
Come gestisco tutto questo nella pratica: Hetzner + Ploi
Il compromesso onesto con l'infrastruttura VPS autogestita è che qualcuno deve gestirla. Su un hyperscaler, decine di team gestiscono il sistema operativo, le patch e la disponibilità dietro le quinte. Su un VPS, quella responsabilità si sposta su di te. Per molte aziende questo è un ostacolo, motivo per cui esistono hosting WordPress gestito e page builder. Ma se stai costruendo un sito o un'applicazione reale, esiste una via di mezzo.
Uso Ploi per gestire lo strato server. Ploi si connette all'API Hetzner, effettua il provisioning di nuovi server, installa Nginx, runtime Node o PHP, configura i certificati SSL tramite Let's Encrypt e gestisce i deployment attivati dai push Git. L'intero flusso di provisioning per un nuovo sito richiede circa dieci minuti. Dopo di che, i deployment avvengono automaticamente al push. Le patch di sicurezza e gli aggiornamenti del sistema operativo girano su un programma configurato senza alcun passaggio manuale. Il server è essenzialmente autogestito.
- Crea un account Hetzner Cloud e genera un token API
- Connetti Ploi a Hetzner usando il token API
- Avvia un nuovo server (CPX21 o CPX31 per la maggior parte dei progetti) dall'interno di Ploi
- Aggiungi un sito, punta il dominio e lascia che Ploi installi automaticamente Nginx + SSL
- Connetti il tuo repository Git e configura lo script di deploy
- Attiva i backup automatici su Hetzner Object Storage dalla dashboard di Ploi
Lo stack in esecuzione adesso
Questo sito e i progetti dei miei clienti girano sul setup descritto di seguito. Il server è attivo da oltre un anno, i certificati SSL si rinnovano da soli, i backup del database girano ogni sei ore e ottengo uno snapshot prima di ogni deploy. Non ho avuto bisogno di connettermi via SSH per un'emergenza da mesi. Questo è l'obiettivo.
# Stack summary, jumpinotech.com
# Provider : Hetzner Cloud (Germany, EU)
# Location : Nuremberg (NBG1), ~700 km from South Tyrol
server: CPX31
vCPU : 4 (dedicated)
RAM : 8 GB
Disk : 160 GB NVMe
OS : Ubuntu 24.04 LTS
services:
- nginx 1.26 # reverse-proxy, TLS termination
- node 22 (pm2) # app runtime
- mysql 8.4 # database, bound to localhost only
- certbot # Let's Encrypt, auto-renew via systemd timer
backups:
database : mysqldump every 6 h -> Hetzner Object Storage (FSN1, EU)
snapshot : before every deploy -> Hetzner Cloud Console
retention: 7 daily / 4 weekly
data residency: EU only, no US endpoint, no transatlantic transferIl deployment stesso è un breve script Bash che Ploi chiama dopo ogni push al branch main. Niente di magico, pull, install, build, reload. Il dettaglio importante è il pm2 reload alla fine, che esegue un riavvio a zero downtime: il vecchio processo rimane attivo finché quello nuovo non è pronto.
#!/usr/bin/env bash
# deploy.sh, triggered by Ploi on every push to main
set -euo pipefail
APP_DIR="/var/www/jumpinotech"
PM2_NAME="jumpinotech"
echo "[deploy] pulling latest..."
cd "${APP_DIR}"
git pull --ff-only origin main
echo "[deploy] installing dependencies..."
npm ci --omit=dev
echo "[deploy] building..."
npm run build
echo "[deploy] reloading process..."
pm2 reload "${PM2_NAME}" --update-env
echo "[deploy] done, $(date -u '+%Y-%m-%dT%H:%M:%SZ')"Dove i grandi cloud vincono ancora
Non mi interessano gli argomenti che pretendono che un approccio sia giusto per tutti. I grandi provider cloud americani esistono per buone ragioni. Se hai bisogno di una CDN distribuita globalmente con edge compute, Kubernetes gestito in scala, o endpoint di inferenza ML con accesso GPU, AWS e GCP sono soluzioni genuine. Se il tuo prodotto deve servire utenti con prestazioni uguali da San Paolo a Seoul, un singolo VPS Hetzner in Germania non è la risposta.
Ma la maggior parte delle aziende altoatesine non serve San Paolo. Servono Merano, Bressanone, Vipiteno, e i turisti che visitano ogni estate e inverno. Per quel pubblico, un server in Germania è più vicino, più veloce, meno costoso e più semplice dal punto di vista della governance dei dati rispetto a qualsiasi cosa si trovi in un datacenter americano. La corrispondenza delle dimensioni conta.
L'infrastruttura giusta è quella che si adatta al problema reale. Per un'azienda locale in Südtirol, il problema è servire clienti europei, mantenere la conformità GDPR e non pagare prezzi della Silicon Valley per farlo.
Un punto di partenza pratico
Se sei un'azienda in Alto Adige attualmente su hosting americano e vuoi capire le tue opzioni, la conversazione inizia con alcune domande: quali dati personali stai raccogliendo? Dove vanno dopo l'invio del modulo? Chi vi ha accesso? In molti casi la risposta è scomoda, non perché qualcuno stia facendo qualcosa di sbagliato, ma perché la scelta di default dell'hosting non è mai stata fatta con cura.
Passare a infrastrutture europee non richiede una riscrittura. Un sito statico o un semplice CMS può essere migrato in un giorno. Un'applicazione Node o PHP richiede un po' più di tempo, ma il processo è affidabile e ben documentato. Se vuoi aiuto nel ragionare su cosa abbia senso per la tua situazione specifica, sono facilmente raggiungibile. Questo è il tipo di lavoro che faccio per le aziende in Südtirol e nella più ampia UE, infrastrutture pratiche che capisci davvero e controlli tu.