---
title: "Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto"
description: "Gestione log Laravel su server Hetzner/OVH: logrotate, Monolog JSON strutturato, canali separati, centralizzazione su Loki/ELK. Il caso del laravel.log da 87GB."
canonical: "https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html"
author: "Maurizio Fonte"
date: "2025-06-12T08:18:37+02:00"
modified: "2026-04-14T17:48:55+02:00"
section: "DevOps"
tags: ["DevOps", "Laravel"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html)

# [Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html)

Giovedì 12 Giugno 2025, alle 08:18 ![Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/image/001750200-gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.jpg)

A novembre 2024 ho ricevuto una telefonata di emergenza di un cliente cuneese del settore logistico che gestisce un WMS (Warehouse Management System) custom su Laravel 9 ospitato su un dedicato OVH SYS-3, con tre operatori del magazzino che dipendono dal sistema per scansionare i pacchi in entrata e in uscita. Verso le 11 del mattino di un mercoledì, gli operatori avevano iniziato a vedere errori 500 in cascata: ogni tentativo di registrare un nuovo movimento di magazzino falliva. Il responsabile mi ha chiamato in panico - il magazzino era fermo, i camion in attesa, i clienti finali in coda telefonica. Quando mi sono collegato in SSH al server, in trenta secondi avevo la diagnosi: `df -h` mostrava la partizione `/var` al 100%, con 87 gigabyte di file `storage/logs/laravel.log` accumulati in otto mesi di scrittura continua, senza alcuna rotazione. Laravel non riusciva più a scrivere nelle sessioni, MySQL aveva smesso di poter scrivere nei propri binlog, e l'applicazione era in stato di stallo completo.

Il fix immediato è stato banale e brutale: `truncate -s 0 storage/logs/laravel.log`, restart di PHP-FPM, sistema di nuovo in piedi in dodici minuti. Ma il fix immediato non è quello che ho fatturato - quello che ho fatturato sono i quattro giorni successivi spesi a costruire una vera *strategia di gestione dei log* per quel cliente, perché il fatto che 87 GB si fossero accumulati in otto mesi era il sintomo di un problema strutturale, non un incidente isolato. L'altra cosa rivelatrice di quei 87 GB era il loro contenuto: il 94% erano log di livello DEBUG generati da un servizio di import che nessuno usava più da un anno, e che continuavano ad essere scritti perché il livello di log non era mai stato alzato a INFO in produzione. Tutta quella scrittura aveva nascosto, dentro al rumore, decine di errori reali che il sistema produceva ogni giorno e che nessuno aveva mai notato. Questo articolo è il distillato del piano operativo che ho costruito su quel cliente e che ora applico come standard su tutti i Laravel in produzione: quattro componenti - rotazione di sistema, struttura JSON Monolog, canali separati per intento, centralizzazione fuori host - che insieme trasformano i log da debito tecnico invisibile a sistema nervoso dell'applicazione.

## Quando il log diventa l'incidente: ottantasette gigabyte che fermano un magazzino

Il primo punto culturale che cerco di trasmettere ai clienti dopo un incidente come quello cuneese è che il log non è uno scarto - è il *primo* sistema dell'applicazione che diventa critico quando qualcosa va storto. Un'applicazione che gira bene può sopravvivere senza un sistema di log strutturato (anche se non dovrebbe). Un'applicazione in crisi senza un sistema di log strutturato è impossibile da diagnosticare, e le decisioni di emergency triage vengono prese alla cieca, basate su intuizioni o, peggio, su `tail -f` che non vedono nulla di utile perché il segnale è sepolto nel rumore.

I tre rischi concreti della gestione passiva dei log che vedo sui clienti sono questi. Primo, l'esaurimento del disco - quello del cliente cuneese è il caso scolastico, ma succede in molte forme: log che non ruotano, sessioni che non si puliscono, cache che crescono senza limite, MySQL binlog non scaduti, dump cron job dimenticati. Quando `/var` raggiunge il 100%, in cascata smettono di funzionare il database (perché non riesce più a scrivere binlog), il web server (perché non riesce più a scrivere session), il sistema operativo stesso (perché non riesce più a scrivere log di sistema), e l'utente vede una pagina bianca o un errore 500 generico che non spiega niente. Secondo, la cecità operativa: quando arriva un bug intermittente e l'unica fonte di verità è un file di testo monolitico da gigabyte, anche `grep` diventa inefficiente - ogni invocazione consuma decine di secondi di CPU sul server di produzione e genera I/O che a sua volta rallenta l'applicazione che stai cercando di debuggare. Terzo, la non-conformità: i log applicativi quasi sempre contengono dati personali (IP utente, email, identificativi sessione), e tenerli per sempre senza una policy di retention violenta direttamente il principio di limitazione della conservazione del [GDPR articolo 5(1)(e), il cui testo ufficiale è consultabile su EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - cosa che diventa documentabile dal Garante in caso di audit successivo a un incident, esattamente lo scenario che descrivo nel mio [protocollo di incident response in 72 ore conforme NIS2](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html).

Il principio che ripeto sempre ai clienti dopo un incidente di questo tipo è che il log management non è una "best practice opzionale" - è una linea di difesa di primo livello, e va trattato con la stessa serietà dei backup. Senza log gestiti, il tuo sistema in produzione è una scatola nera, e quando la scatola nera si rompe non c'è modo di capire perché.

## Logrotate prima di tutto: la cura che evita il novanta per cento dei disastri

La singola misura più importante, e quella che applico nelle prime ore di qualsiasi intervento sui log di un cliente PMI, è l'attivazione di `logrotate` di sistema. È uno strumento Linux storico - esiste sostanzialmente da sempre nelle distribuzioni Debian/Ubuntu - documentato nella [pagina di manuale ufficiale logrotate(8) su man7.org](https://man7.org/linux/man-pages/man8/logrotate.8.html), che si occupa di ruotare, comprimere e cancellare i vecchi file di log secondo policy configurabili. Lo preferisco alla rotazione interna di Laravel (`daily` driver) per due motivi: primo, è più affidabile (è un cron di sistema che non dipende dal fatto che PHP riesca a girare correttamente - quindi funziona anche quando l'applicazione è in stato di crisi); secondo, è più potente (gestisce compressione, retention multipla, hook post-rotazione come segnali ai processi).

La configurazione che applico come standard sui clienti Laravel in produzione vive in `/etc/logrotate.d/laravel-app` e ha questa forma:

```bash
/var/www/app/storage/logs/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 deployer www-data
    sharedscripts
    postrotate
        /usr/sbin/service php8.3-fpm reload > /dev/null 2>&1 || true
    endscript
}
```

I parametri chiave sono cinque. `daily` esegue la rotazione una volta al giorno. `rotate 14` mantiene quattordici archivi storici e cancella tutto quello che è più vecchio (due settimane di retention sono il punto giusto per la maggior parte delle PMI - abbastanza per debuggare incidenti recenti, abbastanza poco da non accumulare gigabyte di storia). `compress` con `delaycompress` comprime i log dopo il primo ciclo di rotazione (la compressione gzip riduce tipicamente i log testuali al 5-10% del volume originale). `create 0640 deployer www-data` crea il nuovo file con permessi sicuri e ownership corretto. `postrotate` rilancia php-fpm in modo che riapra i descrittori di file verso il nuovo log path. Questa singola configurazione, applicata in cinque minuti, avrebbe completamente prevenuto l'incidente del cliente cuneese: i 87 GB sarebbero stati distribuiti su 14 archivi compressi da circa 600 MB compressi ciascuno, e dopo due settimane sarebbero stati automaticamente cancellati.

C'è un dettaglio importante: dopo aver attivato logrotate su un sistema esistente con file di log enormi, *non* devi cancellare manualmente il file vecchio con `rm`. Devi usare `truncate -s 0` o aspettare la prima rotazione, perché PHP-FPM ha un descrittore di file aperto verso il file vecchio, e un `rm` libera lo spazio su disco solo dopo che tutti i descrittori vengono chiusi (cioè dopo un restart di PHP-FPM). L'errore "ho fatto rm ma il disco è ancora pieno" è classico e l'ho visto fare a più di un sviluppatore alle prese con un incidente di disco pieno - è esattamente lo stesso pattern di problema invisibile per chi non è abituato all'analisi di sistema in emergenza che ho descritto nella mia guida all'[ottimizzazione delle performance PHP su Hetzner, OVH e Digital Ocean](https://www.mauriziofonte.it/blog/post/ottimizzazione-performance-php-server-hetzner-ovh-digital-ocean.html).

## JSON strutturato con Monolog: dal grep al filtro semantico

Una volta risolto il problema dello spazio disco con logrotate, il livello successivo è la *strutturazione* dei log. Laravel usa Monolog come backend di logging - una libreria PHP estremamente potente, [il cui repository ufficiale su GitHub di Seldaek](https://github.com/Seldaek/monolog) è il riferimento per tutte le sue capacità - e di default scrive i log in formato testuale leggibile dall'umano: una riga per evento con timestamp, livello e messaggio. Questo formato è utile in sviluppo ma è quasi inutile in produzione, perché ogni informazione strutturata (utente coinvolto, payload della request, identificativo della sessione, metadata dell'eccezione) finisce concatenata in un'unica stringa di testo che richiede un parser regex per essere riestratta.

Il formato che uso in produzione è JSON, che Monolog supporta nativamente tramite il `JsonFormatter`. Si configura in `config/logging.php` modificando il canale primario:

```php
'daily' => [
    'driver' => 'daily',
    'path' => storage_path('logs/laravel.log'),
    'level' => env('LOG_LEVEL', 'info'),
    'days' => 14,
    'formatter' => Monolog\Formatter\JsonFormatter::class,
    'formatter_with' => [
        'batchMode' => Monolog\Formatter\JsonFormatter::BATCH_MODE_NEWLINES,
        'appendNewline' => true,
    ],
],
```

Con questa configurazione, ogni evento di log diventa una riga JSON come `{"datetime":"2025-03-12T11:24:33+01:00","level":"ERROR","level_name":"ERROR","message":"...","context":{"user_id":4172,"order_id":88421,"exception":{...}},"channel":"production"}`. Le tre proprietà che cambiano tutto sono: la struttura dei campi (puoi filtrare via `jq` o tools di log management su `level=ERROR`, su `context.user_id=4172`, eccetera, in modo banale), la possibilità di iniettare context arrays ricchi (`Log::error('checkout failed', ['user_id' => $u->id, 'order_id' => $o->id, 'amount' => $o->total])`) che diventano automaticamente campi indicizzabili, e la compatibilità diretta con quasi tutti i sistemi di log management moderni che si aspettano JSON line. La [documentazione ufficiale di Laravel sul logging](https://laravel.com/docs/logging) descrive in dettaglio tutte le opzioni di configurazione disponibili e i vari driver supportati out-of-the-box.

L'altra cosa che faccio sempre quando passo i clienti a JSON Monolog è alzare il livello di default da `debug` a `info` in produzione (`LOG_LEVEL=info` nel `.env` di produzione). Questo elimina automaticamente tutto il rumore di basso livello - i 94% di log DEBUG del cliente cuneese, in pratica - e fa emergere solo gli eventi che meritano attenzione operativa. Il livello DEBUG ha senso in sviluppo, in produzione è un generatore di rumore che impedisce di vedere i segnali veri.

## Canali separati per intento: errori, sicurezza, audit, performance

Il terzo livello, quello che separa i setup di logging adeguati da quelli ottimi, è la *separazione dei canali per intento*. Invece di scrivere tutto in un unico `laravel.log`, configuro tipicamente quattro canali distinti su `config/logging.php`: un canale `errors` per le eccezioni e i log di livello ERROR/CRITICAL (retention 30 giorni, va monitorato attivamente), un canale `security` per gli eventi di sicurezza come login falliti, tentativi di accesso non autorizzato, modifiche di permessi (retention 365 giorni per audit, mai cancellato sotto i 12 mesi), un canale `audit` per le operazioni business-critical come modifiche di prezzi, cancellazioni di ordini, accessi a dati sensibili (retention indefinita, archiviato off-host), e un canale `performance` per le query lente, i timeout, le metriche di latenza (retention 7 giorni, è l'unico canale dove DEBUG ha senso temporaneamente). Ognuno di questi canali ha un suo file dedicato, una sua policy di rotazione in `/etc/logrotate.d/`, e idealmente un suo destination remoto.

Il vantaggio di questa separazione è triplo. Primo, ogni canale ha le sue policy di retention e compliance, in modo che i log di security/audit non vengano cancellati prematuramente solo perché stanno nello stesso file dei log applicativi rumorosi. Secondo, ogni canale può essere monitorato in modo diverso - gli errori critici devono triggerare un alert immediato, gli eventi di security devono andare a un SIEM, le performance possono essere campionate. Terzo, in caso di incidente, sai esattamente dove guardare: un breach va indagato dal canale `security`, un bug applicativo dal canale `errors`, una regressione di performance dal canale `performance`. È esattamente questo livello di granularità che permette di ricostruire la cronologia di un incidente in caso di compromissione, come ho descritto nel mio [protocollo di gestione di un sito PHP hackerato su Hetzner o OVH](https://www.mauriziofonte.it/blog/post/sito-php-hackerato-guida-ripristino-hardening-server-hetzner-ovh.html) - senza canali separati, le evidenze di un attacco sono sepolte in megabyte di log applicativi e quasi impossibili da estrarre nelle prime ore.

## Centralizzazione con Loki o ELK: log come sistema nervoso esterno

L'ultimo livello, quello che porta una PMI da "log gestiti decentemente" a "log come asset operativo", è la *centralizzazione* su un sistema di log management esterno al server di produzione. Le ragioni sono tre, e nessuna è secondaria. Prima ragione, sicurezza forensica: se il server di produzione viene compromesso, la prima cosa che un attaccante competente fa è cancellare i log locali per coprire le tracce. Avere i log spediti in tempo reale a un sistema esterno significa che le evidenze di un incidente sopravvivono anche se il server target viene completamente devastato - è un requisito di base per qualunque incident response degno del nome ed è esplicitamente raccomandato dalla [direttiva NIS2 nella mia guida operativa alla compliance NIS2 su server Hetzner/OVH](https://www.mauriziofonte.it/blog/post/direttiva-nis2-guida-compliance-server-hetzner-ovh.html). Seconda ragione, performance: l'analisi di log su un sistema dedicato non consuma risorse del server applicativo, e gli indici full-text del log management permettono ricerche istantanee su volumi enormi che sarebbero impossibili con `grep`. Terza ragione, alerting: un buon sistema di log management ti permette di definire regole tipo "se compaiono più di 10 errori 500 in un minuto, mandami una notifica Slack" - il che trasforma il monitoring da reattivo (qualcuno chiama in panico) a proattivo (l'alert arriva prima che il cliente se ne accorga).

Lo stack che configuro su quasi tutti i clienti PMI è Grafana Loki + Promtail + Grafana - economico, self-hosted, scalabile. Promtail è un agente leggero che gira sul server applicativo e fa il tail dei file JSON di log, spedendoli a Loki. Loki è il backend di storage e indicizzazione, ottimizzato per log strutturati ed economico in termini di storage (indicizza solo i metadata, non il contenuto, quindi costa molto meno di Elasticsearch su volumi elevati). Grafana è la UI che permette di fare query, dashboard, e alert. La [documentazione ufficiale di Grafana Loki](https://grafana.com/docs/loki/latest/) è eccellente e mantiene una guida specifica per setup small/medium che è perfetta per le PMI italiane con un singolo server applicativo. Per i clienti che hanno già Elasticsearch in casa per altri motivi, lo stack ELK (Elasticsearch + Logstash + Kibana) è un'alternativa più potente ma più cara in termini di RAM e storage. Sul cliente cuneese, dopo l'incidente, abbiamo configurato Loki su un VPS dedicato da 4 GB di RAM (costo: 12 euro/mese su OVH), con due settimane di retention dei log su Loki e archiviazione dei security/audit log su S3 a basso costo per la conservazione legale. Il risultato è che oggi, sei mesi dopo, il responsabile può aprire una dashboard Grafana e in dieci secondi vedere quanti errori ci sono stati nell'ultimo giorno, su quale endpoint, da quale utente - la differenza fra avere una scatola nera e avere un sistema osservabile.

Se gestisci una PMI con un'applicazione Laravel in produzione e i tuoi log sono ancora in stato "default Laravel + un po' di paura", non aspettare che 87 GB di laravel.log fermino il tuo magazzino o il tuo e-commerce. [Scopri come lavoro con i clienti sul tema dell'osservabilità delle applicazioni in produzione](https://www.mauriziofonte.it/pages/about): in dieci anni di consulenza ho introdotto setup di logging strutturato + centralizzazione su decine di clienti Laravel, e il pattern è sempre lo stesso - quattro giorni di lavoro, retention sotto controllo, alert proattivi, zero incidenti causati da log fuori controllo nei mesi successivi. Se vuoi una valutazione operativa del tuo setup di logging attuale con un piano di adozione progressiva di logrotate, JSON Monolog, canali separati e centralizzazione, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): in due giornate di lavoro tipicamente configuro logrotate sui file critici, attivo Monolog JSON con canali multipli, deploya un'istanza Loki + Grafana sul tuo VPS, e ti consegno una dashboard di monitoring base pronta da estendere con le metriche specifiche del tuo business.

Dall'articolo al lavoro vero

Se questo server lo devi tenere in piedi tu

Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino.

[Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteDeploy Laravel su Hetzner e OVH: come ho convertito un cliente dal venerdì del terrore al rollback in otto secondi con Deployer e GitHub Actions11 Giugno 2025](https://www.mauriziofonte.it/blog/post/automatizzare-deploy-laravel-server-linux-hetzner-ovh-con-deployer.html)[Articolo successivo »Migrare MySQL 5.7 EOL su Hetzner senza fermare il business: la strategia di replicazione che ho usato per spostare 78GB con quattro minuti di downtime12 Giugno 2025](https://www.mauriziofonte.it/blog/post/migrazione-database-mysql-guida-strategica-server-hetzner-ovh.html)

### Articoli correlati a Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto

- [Logging strategico in applicazioni Laravel e Symfony: da semplice debugging a strumento di sicurezza e analisi](https://www.mauriziofonte.it/blog/post/logging-strategico-laravel-symfony-debugging-sicurezza-analisi-applicativi-pmi.html)

  Per molte PMI, il logging negli applicativi Laravel o Symfony si limita al debugging degli errori. Tuttavia, una strategia di logging ben congegnata · 16 Gennaio 2025

  ![Logging strategico in applicazioni Laravel e Symfony: da semplice debugging a strumento di sicurezza e analisi](https://www.mauriziofonte.it/image/001110070-logging-strategico-laravel-symfony-debugging-sicurezza-analisi-applicativi-pmi.jpg)
- [Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/risolvere-problemi-spazio-disco-vps-debian-ubuntu.html)

  Un VPS Hetzner da 80GB al 100 : MySQL fermo, Laravel in errore 500, e dopo aver cancellato 30GB di log lo spazio non si liberava. La causa: file · 14 Luglio 2025

  ![Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/image/002090070-risolvere-problemi-spazio-disco-vps-debian-ubuntu.jpg)
- [Osservabilità minima per applicazioni PHP legacy: logging strutturato, metriche essenziali e alert senza riscrivere il codice](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html)

  Un gestionale PHP legacy dove gli errori si scoprivano dalle telefonate dei clienti: nessun log strutturato, nessun alert, MTTR medio di 4 ore. · 10 Settembre 2025

  ![Osservabilità minima per applicazioni PHP legacy: logging strutturato, metriche essenziali e alert senza riscrivere il codice](https://www.mauriziofonte.it/image/002280070-osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.jpg)
- [Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html)

  Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna · 16 Giugno 2025

  ![Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/image/001790070-ripristino-operativita-web-provider-vps-unmanaged.jpg)
- [NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/blog/post/nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.html)

  NIS2 non è solo un problema del CISO o del DPO riguarda chi scrive codice e chi gestisce server. Ho mappato gli articoli tecnici della direttiva · 13 Ottobre 2025

  ![NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/image/002560070-nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html

Pubblicato: 2025-06-12 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.