Eigene Daten, eigene Kontrolle: Warum ein Südtiroler Betrieb auf europäischer Infrastruktur laufen sollteEigene Daten, eigene Kontrolle: Warum ein Südtiroler Betrieb auf europäischer Infrastruktur laufen sollteEigene Daten, eigene Kontrolle: Warum ein Südtiroler Betrieb auf europäischer Infrastruktur laufen sollte

Jede Woche spreche ich mit einem Hotelbesitzer in Meran, einem Geschäft in Bozen oder einer kleinen Agentur irgendwo im Eisacktal, die mir sagt, sie seien "in der Cloud." Was sie fast immer meinen: Ihre Website läuft auf einem Shared-Hosting-Plan, der von einem Serverraum in Virginia oder Iowa aus verwaltet wird. Die Daten — Buchungsformulare, Kontaktanfragen, Newsletter-Anmeldungen — liegen in den USA, auf Infrastruktur, die dem US-amerikanischen Recht unterliegt und US-Regierungsanfragen ausgesetzt ist. Das ist eine vollständig vermeidbare Situation, und dieser Beitrag erklärt, warum das wichtig ist und was man stattdessen tun kann.

Wo Daten gespeichert sind, ist eine Rechtsfrage, nicht nur eine technische

Die DSGVO wurde nicht geschrieben, um lästig zu sein. Sie wurde geschrieben, weil die EU entschieden hat, dass personenbezogene Daten ihrer Bürger echten Schutz verdienen — auch vor ausländischen Regierungen und Unternehmen. Wenn ein Südtiroler Betrieb Kundendaten auf US-amerikanischer Infrastruktur speichert, betritt er eine komplizierte Welt aus Standardvertragsklauseln, Datenverarbeitungsverträgen und EU–US-Datentransferrahmen, die in den letzten zehn Jahren zweimal vor Gericht angefochten und gekippt wurden.

Europäische Infrastruktur zu nutzen macht DSGVO-Konformität nicht automatisch. Man braucht weiterhin korrekte Cookie-Einwilligungen, ordnungsgemäße Datenschutzhinweise und alles andere. Aber es beseitigt die schwierigste Frage vollständig: "Übermitteln Sie personenbezogene Daten in ein Drittland?" Wenn der Server in Deutschland und die Backups in Finnland liegen, lautet die Antwort nein. Diese eine Antwort vereinfacht die rechtliche Risikoexposition erheblich.

Das Kostenargument ist nicht einmal knapp

Ein Hetzner CPX31 — vier dedizierte vCPUs, 8 GB RAM, 160 GB NVMe und 20 TB ausgehender Traffic — kostet etwa 15 EUR pro Monat. Das nächste AWS-Äquivalent, sobald man EBS-Storage hinzufügt und realistische Egress-Kosten bei irgendeinem Volumen einrechnet, übersteigt 80 EUR. Das ist kein Unterschied. Es ist fünfmal das Geld für Infrastruktur, die physisch weiter von den eigenen Nutzern entfernt ist.

Für eine Hotelwebsite mit Buchungsformularen, ein Restaurant mit PDF-Speisekarte und Kontaktseite oder ein Einzelhandelsgeschäft mit einem kleinen Produktkatalog passt die Arbeitslast problemlos auf einen 15–20-EUR-Hetzner-VPS. Ich betreibe diese Website plus mehrere Kundenprojekte auf einem Server, und die Rechnung hat sich in zwei Jahren nicht verändert. US-Cloud-Rechnungen haben die Angewohnheit zu steigen. Hetzner-Rechnungen nicht.

Physische Entfernung ist relevant für die Leistung

Licht reist schnell, aber nicht unendlich schnell. Ein Server in Nürnberg ist etwa 700 km von Bozen entfernt. Ein Server in Virginia ist etwa 8.000 km entfernt. Diese Lücke zeigt sich als Latenz — die Verzögerung zwischen einem Klick des Nutzers und der Serverantwort. Bei einer nicht gecachten, serverseitig gerenderten Seite kann der Unterschied 60–120 ms oder mehr betragen. Das ist nicht unsichtbar. Googles Core Web Vitals messen die Time to First Byte, und ein Server auf demselben Kontinent wie die Besucher ist eine kostenlose Leistungsverbesserung, die keine Code-Optimierung vollständig ersetzen kann.

• Nürnberg — Bozen: ~700 km, ~5–10 ms Basis-Netzwerklatenz
• Virginia — Bozen: ~8.000 km, ~80–120 ms Basis-Netzwerklatenz
• Helsinki (Hetzner) — Bozen: ~2.000 km, ~25–35 ms Basis-Netzwerklatenz
• Cloudflare CDN davor eliminiert Latenz für gecachte Assets unabhängig vom Origin
• Serverseitig gerenderte Seiten und API-Aufrufe hängen weiterhin von der Origin-Antwortzeit ab

Echtes Eigentum bedeutet, man kann migrieren, prüfen und kontrollieren

Das stille Problem großer verwalteter Clouds ist Vendor-Lock-in. Kein technischer Lock-in — man kann immer migrieren — sondern ein psychologischer. Je mehr Dienste man übernimmt, desto mehr fühlt sich das Wechseln wie eine Operation an. Hetzner ist ein Linux-VPS. Man besitzt den Root-Zugriff. Man kann einen Snapshot machen, ihn zu einem beliebigen anderen VPS-Anbieter weltweit verschieben und innerhalb einer Stunde laufen. Die Backups sind Standard-SQL-Dumps in einem S3-kompatiblen Bucket, den man selbst kontrolliert. Es gibt nichts Proprietäres zu entwirren.

Auditing ist ebenfalls unkompliziert. Man sieht genau, was installiert ist, was auf welchem Port lauscht und wo die Daten sind. Für einen Unternehmer, der einem DSGVO-Prüfer zeigen muss, wo Kundendaten gespeichert sind und wer darauf zugreifen kann, ist diese Klarheit wertvoll. Ein AWS-Multi-Account-Setup mit Daten auf verschiedenen verwalteten Diensten ist viel schwieriger zu erklären.

Wie ich das in der Praxis betreibe: Hetzner + Ploi

Der ehrliche Kompromiss bei selbstverwalteter VPS-Infrastruktur ist, dass jemand sie verwalten muss. Bei einem Hyperscaler kümmern sich Dutzende Teams im Hintergrund um das Betriebssystem, Patches und Verfügbarkeit. Beim VPS verlagert sich diese Verantwortung auf einen selbst. Für viele Betriebe ist das ein Ausschlusskriterium — weshalb es verwaltetes WordPress-Hosting und Page-Builder gibt. Aber beim Aufbau einer echten Website oder Anwendung gibt es einen Mittelweg.

Ich nutze Ploi, um den Server-Layer zu verwalten. Ploi verbindet sich mit der Hetzner-API, provisioniert neue Server, installiert Nginx, Node- oder PHP-Runtimes, konfiguriert SSL-Zertifikate über Let's Encrypt und handhabt Deployments, die durch Git-Pushes ausgelöst werden. Der gesamte Provisioning-Ablauf für eine neue Website dauert etwa zehn Minuten. Danach finden Deployments automatisch bei jedem Push statt. Sicherheits-Patches und OS-Updates laufen nach einem konfigurierten Zeitplan ohne manuelle Schritte. Der Server ist im Wesentlichen selbstheilend.

1. 01Hetzner-Cloud-Konto erstellen und API-Token generieren
2. 02Ploi mit Hetzner über den API-Token verbinden
3. 03Neuen Server (CPX21 oder CPX31 für die meisten Projekte) innerhalb von Ploi aufsetzen
4. 04Website hinzufügen, Domain verweisen und Ploi Nginx + SSL automatisch installieren lassen
5. 05Git-Repository verbinden und Deploy-Skript konfigurieren
6. 06Automatische Backups auf Hetzner Object Storage über das Ploi-Dashboard aktivieren

Der Stack, der gerade läuft

Diese Website und meine Kundenprojekte laufen auf dem unten beschriebenen Setup. Der Server ist seit über einem Jahr live, SSL-Zertifikate erneuern sich selbst, Datenbank-Backups laufen alle sechs Stunden, und ich bekomme einen Snapshot vor jedem Deployment. Ich musste seit Monaten nicht mehr per SSH eingreifen, um einen Notfall zu beheben. Das ist das Ziel.

# 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

Das Deployment selbst ist ein kurzes Bash-Skript, das Ploi nach jedem Push auf den Main-Branch aufruft. Nichts Magisches — pull, install, build, reload. Das wichtige Detail ist das pm2 reload am Ende, das einen Zero-Downtime-Neustart durchführt: Der alte Prozess bleibt aktiv, bis der neue bereit ist.

#!/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')"

Wo große Clouds weiterhin besser sind

Mich interessieren keine Argumente, die so tun, als wäre ein Ansatz für alle der richtige. Große US-Cloud-Anbieter existieren aus guten Gründen. Wenn man ein global verteiltes CDN mit Edge-Compute, verwaltetes Kubernetes in großem Maßstab oder ML-Inferenz-Endpunkte mit GPU-Zugang braucht, sind AWS und GCP echte Lösungen. Wenn das Produkt Nutzer mit gleicher Leistung von São Paulo bis Seoul bedienen muss, ist ein einzelner Hetzner-VPS in Deutschland nicht die Antwort.

Aber die meisten Südtiroler Betriebe bedienen nicht São Paulo. Sie bedienen Meran, Brixen, Sterzing und die Touristen, die jeden Sommer und Winter zu Besuch kommen. Für dieses Publikum ist ein Server in Deutschland näher, schneller, günstiger und einfacher aus Datenschutzperspektive als alles, was in einem US-Rechenzentrum steht. Die Passgenauigkeit des Maßstabs zählt.

Die richtige Infrastruktur ist die, die zum tatsächlichen Problem passt. Für einen lokalen Betrieb in Südtirol ist das Problem, europäische Kunden zu bedienen, DSGVO-konform zu bleiben und dafür keine Silicon-Valley-Preise zu zahlen.

Ein praktischer Ausgangspunkt

Wenn man in Südtirol ein Unternehmen ist, das aktuell auf US-amerikanischem Hosting läuft, und die Optionen verstehen möchte, beginnt das Gespräch mit einigen Fragen: Welche personenbezogenen Daten werden erhoben? Wohin gehen sie nach dem Absenden des Formulars? Wer hat darauf Zugriff? In vielen Fällen ist die Antwort unbequem — nicht weil jemand etwas Falsches tut, sondern weil die Hosting-Standardwahl nie bewusst getroffen wurde.

Der Wechsel zu europäischer Infrastruktur erfordert keine Neuprogrammierung. Eine statische Website oder ein einfaches CMS kann innerhalb eines Tages migriert werden. Eine Node- oder PHP-Anwendung dauert etwas länger, aber der Prozess ist zuverlässig und gut dokumentiert. Wer Hilfe dabei möchte, was für die eigene spezifische Situation sinnvoll ist, kann mich problemlos erreichen. Das ist die Art Arbeit, die ich für Betriebe in Südtirol und der weiteren EU mache — praktische Infrastruktur, die man wirklich versteht und selbst kontrolliert.