Hetzner Online GmbH: cos’è e perché è la scelta ideale per il deploy di applicazioni Laravel ad alte prestazioni

Quando una PMI mi chiede dove mettere in produzione la propria applicazione Laravel, la prima risposta che do non riguarda quasi mai il prezzo del server. Riguarda l'architettura: quante istanze servono, come separare il database dalla cache, dove finisce il dato, chi tiene aggiornato il sistema operativo e chi risponde alle tre del mattino quando il php-fpm smette di rispondere. Su questo terreno Hetzner Online GmbH resta, per i progetti che gestisco in autonomia, il riferimento europeo per il cloud self-managed: hardware enterprise a prezzi che nessun provider statunitense regge, datacenter in Unione Europea e un rapporto prezzo/prestazioni che da anni è il benchmark del mercato. Non è la scelta giusta per tutti, ed è proprio la differenza fra "self-managed" e "gestito" che voglio rendere esplicita in questo articolo, perché è lì che la maggior parte delle PMI italiane sbaglia.

Hetzner è un provider tedesco con sede a Gunzenhausen, con una lunga tradizione nei datacenter professionali, nei server dedicati e nell'hosting cloud. I suoi datacenter europei stanno in Germania (Falkenstein, Norimberga) e in Finlandia (Helsinki), e l'infrastruttura, l'esercizio e il supporto di quei park sono certificati ISO/IEC 27001:2022 (ente di certificazione SOCOTEC) su Hetzner Online GmbH e Hetzner Finland Oy. Una precisazione che faccio sempre, perché online circola il contrario: Hetzner non espone una certificazione SOC 2 sulla propria pagina dedicata, solo la ISO 27001:2022. Se un fornitore ti racconta che "Hetzner è SOC 2", ha letto male.

Perché un consulente Laravel sceglie Hetzner per il deploy in self-managed?

Perché Hetzner ti consegna ferro veloce e una rete solida, e poi si fa da parte. Tutto il resto, lo stack, il tuning, la sicurezza, lo costruisci tu (o chi lavora per te). Questo è un vantaggio enorme se hai competenze sistemistiche a disposizione, ed è esattamente il motivo per cui lo preferisco quando progetto infrastrutture su misura per applicazioni critiche: posso dimensionare ogni componente, separare i workload e ottimizzare in profondità senza i layer software inutili che le piattaforme "tutto incluso" ti impongono. È, allo stesso tempo, una responsabilità che non puoi delegare al provider: gli aggiornamenti di kernel, le patch di sicurezza, i backup testati e il monitoring sono affar tuo.

Una moderna applicazione Laravel pensata per reggere carichi medi o elevati non può prescindere da una corretta integrazione di alcuni componenti. Redis come cache di applicazione, store di sessione e backend delle code asincrone; Nginx come web server e reverse proxy verso PHP-FPM; e, dove ha senso, Varnish come strato di caching HTTP davanti a tutto. Su un cloud server o un dedicato Hetzner installi lo stack che vuoi senza compromessi: storage NVMe per abbattere la latenza di I/O del database, tuning fine di PHP-FPM, Redis configurato distinguendo cache effimera e dato persistente, e una network interna privata fra i nodi che non paghi a traffico.

Una piattaforma Laravel ben progettata su un'infrastruttura dedicata raggiunge prestazioni che non sono lontanamente paragonabili a quelle di un hosting condiviso di fascia consumer. Ma il merito non è del marchio del provider: è dell'architettura che ci costruisci sopra.

Stai cercando un consulente che progetti e metta in produzione uno stack Laravel ad alte prestazioni, senza affidarti al "cugino che sa di computer"? Nel mio profilo professionale trovi l'esperienza concreta su server dedicati e cloud Hetzner, OVH e Aruba, hardening Linux e gestione di applicazioni ad alto traffico in produzione.

Lo stack che propongo: separare i ruoli, non ammucchiarli

L'errore più comune che vedo nelle PMI è il monolite infrastrutturale: web server, database, Redis e code tutti sulla stessa macchina, finché un picco di traffico non manda in swap il database e porta giù l'intero sito. Quando progetto un'infrastruttura Laravel su Hetzner per un'applicazione che deve durare, separo i ruoli su nodi distinti collegati da una rete privata. Una topologia tipica per un carico medio è questa:

un nodo dedicato a MySQL o PostgreSQL, con storage NVMe e RAM dimensionata sul working set del database;
un nodo dedicato a Redis, separato in modo che la pressione sulla cache non rubi memoria al database;
uno o più nodi web (Nginx più PHP-FPM, eventualmente Varnish davanti);
backup cifrati spinti offsite su storage separato, su una macchina che non condivide failure domain con la produzione.

Sui database conta scegliere versioni ancora supportate, non quelle che "hai sempre usato". Al momento in cui scrivo, MySQL 8.0 è in end of life da aprile 2026: chi sta partendo oggi dovrebbe orientarsi su MySQL 8.4 LTS, mentre su PostgreSQL la linea corrente è la 18 (la 17 e la 16 restano scelte solide e a lungo supportate). Lo stesso vale per il sistema operativo: parti da una Ubuntu 24.04 LTS o da una Debian 13 "trixie", non da una distribuzione vicina alla fine del supporto. Su PHP, la current stable è la 8.5, mentre la 8.4 è ancora in active support: sono le due righe su cui far girare un Laravel nuovo. La 8.3 è già in regime security-only, e non è una scelta di partenza.

Per dare un ordine di grandezza realistico dei costi, e qui sta una regola che applico sempre, un prezzo va citato con valuta, zona e data di rilevazione, altrimenti invecchia e inganna. I listini Hetzner sono separati per zona di rete e per valuta: stesso piano, prezzo diverso fra Europa e Stati Uniti, e perfino fra Germania e Finlandia sui dedicati. Sulle location europee (Falkenstein, Norimberga, Helsinki), a listino EUR e IVA esclusa, dopo il repricing entrato in vigore il 1° aprile 2026 la linea shared x86 cost-optimized parte dalla CX23 (2 vCPU, 4 GB) a 3,99 EUR/mese, sale alla CX33 a 6,49 EUR/mese, mentre i dedicated vCPU general purpose vanno dalla CCX13 a 15,99 EUR/mese fino ai tagli alti della famiglia. Esistono inoltre i piani Arm64 CAX (la CAX21 a 7,99 EUR/mese) e, per il bare metal, le linee dedicate EX (Intel), AX (AMD) e RX (Arm). L'IP IPv4 primario sul cloud costa 0,50 EUR/mese a parte. Una topologia a tre nodi come quella sopra, in zona europea, si colloca quindi in una classe di poche decine di euro al mese: cifra che per la stessa potenza, su un provider statunitense, semplicemente non esiste.

Quando Octane e FrankenPHP fanno davvero la differenza (e quando no)

Negli ultimi due anni il modo in cui Laravel gira in produzione è cambiato, e ignorarlo significa lasciare prestazioni sul tavolo. Il modello classico è PHP-FPM: a ogni richiesta il framework viene avviato da zero, paga il "boot tax" del bootstrap, serve la risposta e muore. Laravel Octane ribalta lo schema con il worker mode: l'applicazione viene avviata una volta sola e tenuta in memoria, poi riceve le richieste senza ripagare il costo di bootstrap a ogni colpo. Il driver che oggi consiglio per la maggior parte dei nuovi deploy è FrankenPHP, un application server costruito sul web server Caddy, con supporto first-party nel framework e installazione tramite il pacchetto ufficiale.

I numeri, quando il carico è giusto, sono notevoli. Su un endpoint con autenticazione e qualche query, i benchmark del 2026 mostrano FrankenPHP più Octane passare da circa 700 a oltre 3.000 richieste al secondo rispetto a PHP-FPM, con la latenza p95 che crolla. Ma qui scatta il distinguo che separa il consulente dal copia-incolla di benchmark: quel guadagno esiste solo dove il bootstrap pesa. Octane non rende più veloce il tuo codice, smette solo di ripagare l'avvio del framework. Se le tue richieste sono I/O-bound, cioè passano la maggior parte del tempo ad aspettare il database o una API esterna, il bootstrap che Octane elimina è una frazione minima del totale e i tuoi numeri non si muovono di molto. In classic mode, senza worker, FrankenPHP gira entro l'1% di PHP-FPM: il runtime in sé non è più veloce.

Octane brilla sui carichi CPU-bound con bootstrap pesante, tipicamente le applicazioni con pannelli ricchi come Filament o Nova e molti service provider. Su un'applicazione dominata dall'attesa del database, prima si sistemano gli indici e le query N+1, poi semmai si valuta il worker mode.

C'è poi un costo operativo che va capito prima, non scoperto in produzione. In worker mode l'applicazione resta in memoria fra una richiesta e l'altra: è la fonte del vantaggio e, insieme, il suo vincolo principale. Lo stato salvato in proprietà statiche o in singleton non resettati correttamente può "trapelare" da una richiesta all'altra. E i worker, come ogni processo PHP a vita lunga, accumulano memoria: per questo configuro sempre il riciclo periodico (--max-requests=1000), così ogni worker viene rigenerato dopo un numero fisso di richieste e la memoria non cresce all'infinito. Quando metto Octane in produzione, il supervisor (systemd o Supervisor) che gestisce i processi e il monitoraggio della memoria fanno parte del setup tanto quanto il codice.

Su Varnish, infine, la regola è la stessa di sempre: ha senso davanti a contenuti pubblici ad alta frequenza di accesso, con una cache policy che distingua utenti autenticati e guest e che non finisca per servire a un utente loggato la pagina cacheata di un altro. Non è uno strato da aggiungere per riflesso: lo metto quando il profilo di traffico lo giustifica, non prima.

Self-managed o gestito? La domanda che viene prima del provider

Qui arriva la distinzione che cambia tutto, ed è il motivo per cui scelgo Hetzner per alcuni progetti e lo sconsiglio per altri. Hetzner è unmanaged: ti dà il ferro e la rete, e si ferma lì. Se hai un team con competenze sistemistiche, o un consulente che presidia il sistema, è la scelta migliore in assoluto sul piano prezzo/prestazioni. Ma per molte PMI italiane non è così: non hanno un reparto IT strutturato, non vogliono (giustamente) gestire patch di kernel e disaster recovery in casa, e hanno spesso un requisito ulteriore, che il dato resti in Italia per ragioni di compliance, contrattuali o semplicemente di fiducia.

Per quel profilo, la prima scelta che indico non è Hetzner. È RHX: un provider italiano con private cloud iperconvergente, datacenter a Milano (adiacente al MiX, il Milan Internet eXchange) e a Padova, server di proprietà amministrati unicamente da personale interno, e soprattutto la gestione sistemistica inclusa come opzione. RHX è registrar accreditato del Registro .it dal 2004, iscritto al ROC e membro RIPE NCC con risorse IP proprie: un'infrastruttura interamente italiana, senza location estere, con il dato che non lascia il Paese e nessuna esposizione al CLOUD Act statunitense. Il confronto con i listini commodity non si fa sul prezzo nudo (il prezzo per core e per GB di RAM è di un altro ordine di grandezza), ma sul TCO di un'infrastruttura gestita: con RHX paghi anche il fatto che qualcuno tiene aggiornato e monitorato il sistema al posto tuo. Per una PMI che vuole un'infrastruttura NIS-compliant, gestita e con il dato in Italia, è la combinazione che raccomando.

La regola che do ai clienti è semplice: scegli Hetzner se hai (o paghi) le competenze per gestirti il sistema; scegli un provider italiano gestito come RHX se vuoi che del sistema si occupi qualcun altro e ti serve il dato in Italia. Il provider giusto dipende da chi terrà in piedi l'infrastruttura, non dal prezzo in homepage.

Se vuoi capire quale dei due modelli si adatta al tuo progetto, scrivimi e ne parliamo: nella maggior parte dei casi la scelta si chiarisce in una mezz'ora di conversazione, una volta messi sul tavolo budget, competenze interne e requisiti di compliance.

Le ottimizzazioni che applico su uno stack Laravel in produzione

Una volta scelta l'infrastruttura, il valore lo fa il tuning. La forza di una piattaforma Laravel non si misura solo nella correttezza del codice, ma nella qualità con cui lo stack sottostante è configurato. Su un'installazione che porto in produzione lavoro su più livelli, e il primo è quasi sempre il database, non il web server: la maggior parte dei rallentamenti "del server" sono in realtà query N+1, indici mancanti e full table scan che nessuna ottimizzazione di Nginx potrà mai compensare.

# PHP-FPM: dimensionare i worker sulla RAM disponibile, non a caso.
# In /etc/php/8.4/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20        # (RAM disponibile per FPM) / (RAM media per worker)
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500       # ricicla i worker, contiene i memory leak

Sul fronte applicativo, le ottimizzazioni che fanno la differenza maggiore in produzione sono note ma spesso disattese: la cache di config, route ed eventi compilata, e l'autoloader ottimizzato.

# Cache di produzione: compilare config, route, view ed eventi.
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

# Autoloader ottimizzato per la produzione.
composer install --no-dev --optimize-autoloader --classmap-authoritative

Redis lo configuro distinguendo con chiarezza i due usi: la cache effimera (maxmemory con policy di eviction allkeys-lru, dove la perdita di una chiave non è un problema) e il dato che deve sopravvivere a un riavvio, dove invece la persistence va abilitata con criterio. Le code Laravel girano su worker gestiti da systemd o Supervisor, mai con un fragile queue:work lanciato a mano in una sessione SSH che muore al primo logout. HTTPS automatizzato con Certbot e Let's Encrypt, un firewall configurato per esporre solo ciò che serve, e backup snapshot incrementali con ritenzione sensata e, soprattutto, testati nel ripristino: un backup che non hai mai provato a ripristinare non è un backup, è una speranza.

Se vuoi vedere come questa stessa filosofia di scelta del provider si applica al di là di Laravel, ne ho scritto in modo più ampio nell'articolo sul perché Hetzner è il miglior hosting per molti progetti: lì il taglio è sulla scelta del provider in generale, qui sull'architettura applicativa che ci costruisci sopra.

Quanto incide davvero l'infrastruttura sulle prestazioni di Laravel?

Incide moltissimo, ma quasi mai per i motivi che le PMI immaginano. La differenza fra un'applicazione lenta e una reattiva, nel 90% dei casi che vedo, non sta nel numero di core del server: sta nella separazione corretta dei workload, nell'assenza di query N+1, in una cache progettata e non improvvisata, e in uno stack ancora supportato e aggiornato. Comprare un server più grosso per mascherare un'architettura sbagliata è il modo più costoso e meno efficace di "ottimizzare". Un dedicato Hetzner con storage NVMe ti dà un floor di prestazioni altissimo, ma quel floor lo sprechi se sopra ci giri uno stack non tunato.

È esattamente per questo che la scelta di affidarsi a chi conosce sia le logiche applicative sia quelle sistemistiche non è un lusso, ma il punto in cui si decide il risultato. Laravel è un framework eccellente, ma senza la corretta progettazione dell'infrastruttura sottostante rischia di diventare lento, fragile e vulnerabile. Affidare un'applicazione critica a un generico "sysadmin" o a un "webmaster" senza competenze applicative è come montare un motore da Formula 1 su una scocca da utilitaria: la potenza c'è, ma non arriva a terra.

Domande frequenti

Hetzner ha un programma referral con 20 euro di credito gratuito? No, non più. Il programma referral di Hetzner è stato dismesso: i vecchi link referral personali non generano più credito e non vanno più diffusi. Per questo in questo articolo non trovi codici sconto né link affiliati: la promessa "20 euro di credito" legata ai referral non è più valida.

Conviene sempre attivare Laravel Octane su Hetzner? No. Octane (con FrankenPHP) dà guadagni notevoli sui carichi CPU-bound con bootstrap pesante, ma poco o nulla sulle applicazioni I/O-bound dominate dall'attesa del database. Prima si sistemano query, indici e cache; il worker mode si valuta dopo, quando il traffico lo giustifica e con il monitoraggio della memoria già in piedi.

Hetzner è conforme al GDPR e adatto a dati di clienti europei? Hetzner è una società tedesca con datacenter in Germania e Finlandia, certificata ISO/IEC 27001:2022 e con DPA GDPR standard: è una scelta solida per chi vuole infrastruttura cloud in Unione Europea. Per chi ha bisogno del dato fisicamente in Italia e di un'infrastruttura gestita, la scelta da valutare è invece un provider italiano come RHX.

Hetzner o un provider gestito italiano: come scelgo? Dipende da chi gestirà il sistema. Hetzner è unmanaged: ideale se hai competenze sistemistiche interne o un consulente. Se invece vuoi che patching, monitoring e disaster recovery siano inclusi e il dato resti in Italia, un provider gestito come RHX è la scelta più sensata.

Alla fine, la domanda "qual è il provider migliore per Laravel" è mal posta. La domanda giusta è quale architettura serve al tuo progetto, chi terrà in piedi l'infrastruttura e dove deve risiedere il dato. Una volta chiarito questo, la scelta fra un cloud europeo self-managed come Hetzner, sul quale costruire uno stack su misura con Octane, Redis e Varnish, e un'infrastruttura gestita italiana come RHX, con il dato che non lascia il Paese e la gestione sistemistica inclusa, diventa quasi ovvia. Il mio lavoro, in entrambi i casi, è trasformare un progetto Laravel da semplice idea in una piattaforma performante, resiliente e sicura, costruita con metodo e non con l'improvvisazione che troppo spesso governa l'IT delle PMI.