G.STANCUTA
Published · 2026 · 05 · 138 min read

Own Your Data: Why a South Tyrol Business Should Run on European Infrastructure

  • infrastructure
  • data-sovereignty
  • hetzner
  • eu

Defaulting to AWS or Azure makes sense until you ask where your customers' data actually lives. Here is why I run everything on Hetzner in Germany — and why local businesses in Südtirol should care.

Every week I talk to a hotel owner in Merano, a shop in Bolzano, or a small agency somewhere in the Eisacktal who tells me they are "on the cloud." What they mean, almost always, is that their website is on some shared hosting plan administered from a server room in Virginia or Iowa. The data — reservation forms, contact inquiries, newsletter signups — lives in the US, on infrastructure governed by US law, subject to US government requests. That is a completely avoidable situation, and this post is about why it matters and what to do instead.

GDPR was not written to be annoying. It was written because the EU decided that personal data about its residents deserves real protection, including from foreign governments and corporations. When a South Tyrol business stores customer data on US infrastructure, they enter a complicated world of Standard Contractual Clauses, Data Processing Agreements, and EU–US data transfer frameworks that have been challenged in court — and overturned — twice in the last decade.

Running on European infrastructure does not make GDPR compliance automatic. You still need correct cookie consent, proper data processing notices, and all the rest. But it removes the hardest question entirely: "Are you transferring personal data to a third country?" If your server is in Germany and your backups are in Finland, the answer is no. That one answer simplifies your legal exposure considerably.

Isometric diagram of a server block inside an EU boundary outline with a South Tyrol location pin, data staying local
When your server sits inside the EU, your customers' data never crosses a border.

The Cost Argument Is Not Even Close

A Hetzner CPX31 — four dedicated vCPUs, 8 GB RAM, 160 GB NVMe, and 20 TB of outbound traffic — costs around 15 EUR per month. The closest AWS equivalent, once you add EBS storage and price in realistic egress at any volume, runs north of 80 EUR. That is not a margin. It is five times the money for infrastructure that is physically farther from your users.

For a hotel website with booking forms, a restaurant with a PDF menu and a contact page, or a retail shop with a small product catalogue, the workload fits comfortably on a 15–20 EUR Hetzner VPS. I run this site plus several client projects on one server and the bill has not changed in two years. US cloud invoices have a way of drifting upward. Hetzner invoices do not.

Physical Distance Matters for Performance

Light travels fast, but not infinitely fast. A server in Nuremberg is roughly 700 km from Bolzano. A server in Virginia is roughly 8,000 km away. That gap shows up as latency — the delay between a user clicking a link and the server responding. For an uncached, server-rendered page, the difference can be 60–120 ms or more. That is not invisible. Google's Core Web Vitals measure Time to First Byte, and a server on the same continent as your visitors is a free performance improvement that no amount of code optimization can fully replicate.

  • Nuremberg to Bolzano: ~700 km, ~5–10 ms base network latency
  • Virginia to Bolzano: ~8,000 km, ~80–120 ms base network latency
  • Helsinki (Hetzner) to Bolzano: ~2,000 km, ~25–35 ms base network latency
  • Cloudflare CDN in front eliminates latency for cached assets regardless of origin
  • Server-rendered pages and API calls still depend on origin response time

Real Ownership Means You Can Move, Audit, and Control

The quiet problem with large managed clouds is vendor lock-in. Not technical lock-in — you can always migrate — but psychological lock-in. The more services you adopt, the more moving feels like surgery. Hetzner is a Linux VPS. You own the root access. You can take a snapshot, move it to any other VPS provider in the world, and be running within an hour. The backups are standard SQL dumps in an S3-compatible bucket you control. There is nothing proprietary to unpick.

Auditing is also straightforward. You can see exactly what is installed, what is listening on which port, and what data is where. For a business owner who needs to show a GDPR auditor where customer data is stored and who has access to it, that clarity is valuable. A multi-account AWS setup with data scattered across managed services is much harder to explain.

Isometric European data center with backup, lock, and auto-renew cycle icons
Automated backups, TLS auto-renewal, and regular snapshots run without touching a browser.

How I Actually Run This: Hetzner + Ploi

The honest trade-off with self-managed VPS infrastructure is that someone has to manage it. On a hyperscaler, dozens of teams handle the operating system, patching, and availability behind the scenes. On a VPS, that responsibility shifts to you. For many businesses that is a dealbreaker — which is why managed WordPress hosting and page builders exist. But if you are building a real website or application, there is a middle ground.

I use Ploi to manage the server layer. Ploi connects to the Hetzner API, provisions new servers, installs Nginx, Node or PHP runtimes, configures SSL certificates via Let's Encrypt, and handles deployments triggered by Git pushes. The entire provisioning flow for a new site takes about ten minutes. After that, deployments happen automatically on push. Security patches and OS updates run on a configured schedule without any manual step. The server is essentially self-healing.

  1. 01Create a Hetzner Cloud account and generate an API token
  2. 02Connect Ploi to Hetzner using the API token
  3. 03Spin up a new server (CPX21 or CPX31 for most projects) from inside Ploi
  4. 04Add a site, point your domain, and let Ploi install Nginx + SSL automatically
  5. 05Connect your Git repository and configure the deploy script
  6. 06Enable automated backups to Hetzner Object Storage from the Ploi dashboard

The Stack Running Right Now

This site and my client projects run on the setup described below. The server has been live for over a year, SSL certificates renew themselves, database backups run every six hours, and I get a snapshot before every deploy. I have not needed to SSH into it to fix an emergency in months. That is the goal.

yaml
# 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

The deployment itself is a short Bash script that Ploi calls after every push to the main branch. Nothing magic — pull, install, build, reload. The important detail is the pm2 reload at the end, which performs a zero-downtime restart: the old process stays alive until the new one is ready.

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

Where Big Clouds Still Win

I am not interested in arguments that pretend one approach is right for everyone. Large US cloud providers exist for good reasons. If you need a globally distributed CDN with edge compute, managed Kubernetes at scale, or ML inference endpoints with GPU access, AWS and GCP are genuine solutions. If your product needs to serve users with equal performance from São Paulo to Seoul, a single Hetzner VPS in Germany is not the answer.

But most South Tyrol businesses are not serving São Paulo. They are serving Merano, Brixen, Sterzing, and the tourists who visit every summer and winter. For that audience, a server in Germany is closer, faster, cheaper, and simpler from a data governance perspective than anything sitting in a US datacenter. The size match matters.

The right infrastructure is the one that fits the actual problem. For a local business in Südtirol, the problem is serving European customers, staying GDPR-compliant, and not paying Silicon Valley prices for it.

A Practical Starting Point

If you are a business in South Tyrol currently on US-based hosting and you want to understand your options, the conversation starts with a few questions: What personal data are you collecting? Where does it go after the form is submitted? Who has access to it? In many cases the answer is uncomfortable — not because anyone is doing anything wrong, but because the hosting default was never chosen thoughtfully.

Moving to European infrastructure does not require a rewrite. A static site or a simple CMS can be migrated in a day. A Node or PHP application takes a bit longer, but the process is reliable and well-documented. If you want help thinking through what makes sense for your specific setup, I am easy to reach. This is the kind of work I do for businesses in Südtirol and the broader EU — practical infrastructure that you actually understand and control.

Portfolio · Drawing Stamp
Drawn by
G. STANCUTA
Discipline
AI & AUTOMATION
Location
MORTER · SÜDTIROL
Status
Available
Languages
IT · EN · RO · DE+
Stack
PLOI · HETZNER
Revision
REV 2026.A
2026

© 2026 Gabriel Stancuta · jumpinotech.com — Architected with AI, built to run itself.