I tuoi dati sono tuoi: perché un'azienda in Alto Adige dovrebbe usare infrastrutture europeeI tuoi dati sono tuoi: perché un'azienda in Alto Adige dovrebbe usare infrastrutture europeeI tuoi dati sono tuoi: perché un'azienda in Alto Adige dovrebbe usare infrastrutture europee

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.

1. 01Crea un account Hetzner Cloud e genera un token API
2. 02Connetti Ploi a Hetzner usando il token API
3. 03Avvia un nuovo server (CPX21 o CPX31 per la maggior parte dei progetti) dall'interno di Ploi
4. 04Aggiungi un sito, punta il dominio e lascia che Ploi installi automaticamente Nginx + SSL
5. 05Connetti il tuo repository Git e configura lo script di deploy
6. 06Attiva 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 transfer

Il 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.