--- title: "Migrare da hosting condiviso a VPS per Laravel: perché, quando e come farlo senza perdere dati" description: "Migrazione Laravel da hosting condiviso a VPS: analisi dei rischi reali, procedura operativa testata e hardening post-migrazione. Guida da esperienza diretta." canonical: "https://www.mauriziofonte.it/blog/post/transizione-server-condiviso-vps-laravel.html" author: "Maurizio Fonte" date: "2025-06-23T07:23:19+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Informatica" tags: ["Sicurezza Informatica", "VPS & Hosting"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) # [Migrare da hosting condiviso a VPS per Laravel: perché, quando e come farlo senza perdere dati](https://www.mauriziofonte.it/blog/post/transizione-server-condiviso-vps-laravel.html) Lunedì 23 Giugno 2025, alle 07:23 ![Migrare da hosting condiviso a VPS per Laravel: perché, quando e come farlo senza perdere dati](https://www.mauriziofonte.it/image/001840200-transizione-server-condiviso-vps-laravel.jpg) Nella mia esperienza di consulente su infrastrutture Laravel per PMI italiane, la migrazione da hosting condiviso a VPS è uno dei momenti più delicati e sottovalutati del ciclo di vita di un'applicazione. Lo dico perché ho gestito personalmente questa transizione in contesti molto diversi - dall'e-commerce B2B con 400 SKU e ordini giornalieri, al gestionale interno di un'azienda manifatturiera con 80 utenti concorrenti, fino alla piattaforma SaaS di una startup che aveva superato i limiti del suo piano hosting senza rendersene conto per mesi. Il pattern è quasi sempre lo stesso: l'applicazione nasce su un hosting condiviso perché costa poco e "per ora basta", cresce nel tempo assorbendo complessità (queue, scheduled task, cache Redis, storage file), e a un certo punto inizia a manifestare sintomi - rallentamenti intermittenti, timeout sulle API, job che si accavallano, sessioni che scadono senza motivo. Il team di sviluppo (o più spesso l'unico sviluppatore freelance) attribuisce il problema al codice, ottimizza query, aggiunge indici, riduce il payload delle risposte. Ma il codice non è il collo di bottiglia: lo è l'infrastruttura condivisa che non può garantire risorse dedicate. ## Perché un hosting condiviso è inadeguato per Laravel in produzione? La risposta breve è: isolamento insufficiente e controllo assente. La risposta lunga richiede di capire cosa succede realmente sotto la superficie di un hosting condiviso quando ci metti sopra un'applicazione Laravel non banale. Su un hosting condiviso, la tua applicazione PHP gira sullo stesso server di decine o centinaia di altri siti. Le risorse (CPU, RAM, I/O disco) sono ripartite con meccanismi di throttling che il provider non ti documenta. PHP viene eseguito in una configurazione standardizzata che non puoi modificare: la versione è quella che il provider decide di supportare, le estensioni disponibili sono quelle che servono alla maggioranza dei clienti, i limiti di `memory_limit`, `max_execution_time` e `upload_max_filesize` sono impostati per non far crollare il server condiviso - non per far funzionare la tua applicazione. La [documentazione ufficiale PHP sulla sicurezza](https://www.php.net/security-note.php) è esplicita su questo punto: in un ambiente condiviso, `open_basedir` non è una soluzione di sicurezza completa. Le librerie di terze parti possono essere indotte ad accedere a file al di fuori del perimetro previsto, e l'isolamento tra tenant è strutturalmente debole. Per applicazioni critiche, PHP stesso raccomanda di eseguire web server separati, ciascuno con il proprio user ID, idealmente in filesystem chroot-ati. Nel contesto di un'applicazione Laravel che gestisce dati aziendali - fatture, anagrafiche clienti, credenziali di accesso, documenti - questa raccomandazione non è opzionale. È un requisito minimo. > Se stai valutando la migrazione della tua infrastruttura Laravel e vuoi un parere tecnico indipendente, nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su stack Laravel in produzione e gestione VPS. ## I segnali concreti che indicano la necessità di migrare Nel mio lavoro, ho imparato a riconoscere i segnali che precedono il punto di rottura. Non sono sempre evidenti, perché il degrado è graduale: **Timeout intermittenti sulle API.** Laravel risponde in 200ms la mattina e in 3 secondi nel pomeriggio. Il motivo è che un altro sito sullo stesso server sta eseguendo un cron job pesante, e il tuo `php-fpm` viene strozzato dal kernel. Non c'è nulla che tu possa fare lato codice. **Queue worker che si bloccano o ripartono.** Se usi `php artisan queue:work` su un hosting condiviso (ammesso che il provider lo permetta), il processo viene killato periodicamente dal sistema di resource enforcement. I job restano in stato `reserved` e nessuno li processa. Su un VPS, il queue worker gira sotto `supervisor` con restart automatico e log dedicati. **Impossibilità di aggiornare PHP.** La tua applicazione Laravel 10+ richiede PHP 8.1 come minimo. Il provider condiviso offre PHP 8.0 perché "è la versione stabile". Non puoi installare estensioni (`imagick`, `redis`, `swoole`), non puoi modificare `php.ini`, non puoi compilare moduli custom. Sei bloccato. **Backup non verificabili.** Il provider dice che fa backup giornalieri. Tu non li hai mai testati. Non sai dove sono, non sai come ripristinarli, non sai in quanto tempo. Quando serve davvero - e nella mia esperienza serve sempre nel momento peggiore - scopri che il backup è vecchio di 72 ore e non include il database. Quando osservo due o più di questi segnali in un audit iniziale, la raccomandazione è sempre la stessa: migrare su un VPS dove hai pieno controllo. Il costo mensile è spesso comparabile (un VPS entry-level su Hetzner parte da meno di 5 euro al mese per 2 vCPU e 4 GB di RAM), ma la differenza in termini di affidabilità, sicurezza e autonomia operativa è enorme. > Se gestisci un'infrastruttura cloud per applicazioni business-critical, Hetzner rappresenta un'opzione concreta per rapporto qualità/prezzo, conformità GDPR (data center in Germania e Finlandia) e affidabilità comprovata. Digital Ocean, Contabo, OVH e Aruba sono alternative valide con posizionamenti diversi. Hetzner offre un [credito di 20 euro](https://hetzner.cloud/?ref=TpoHUoEN4lKP) per nuovi account, sufficiente per testare un VPS CX22 per oltre un mese. ## La procedura operativa che applico nelle migrazioni reali Ogni migrazione che gestisco segue una sequenza rigida in cinque fasi. Non è un protocollo teorico - è il risultato di errori che ho commesso e corretto negli anni, cristallizzato in un processo che minimizza il rischio di downtime e data loss. ### Fase 1: inventario completo dell'ambiente sorgente Prima di toccare qualsiasi cosa, mappo lo stato attuale. Questo significa: ```bash php artisan --version php -v php -m | sort composer show --installed | wc -l mysql -V df -h du -sh storage/app/ storage/framework/ storage/logs/ crontab -l ``` Documento versione PHP esatta, estensioni installate, numero di dipendenze Composer, versione MySQL, spazio disco occupato da storage e log, cron job attivi. Questo inventario mi serve per due cose: configurare il VPS target con lo stesso stack, e identificare in anticipo le incompatibilità (estensioni mancanti, versioni PHP divergenti, storage locale che dev'essere migrato su object storage). ### Fase 2: provisioning del VPS con hardening base Il VPS target viene provvisionato con Debian 12 o Ubuntu 24.04 LTS. La prima cosa che faccio non è installare Laravel - è hardenizzare il server: ```bash apt update && apt upgrade -y # Utente non-root per il deploy adduser deploy usermod -aG sudo deploy # SSH solo con chiavi, no password, no root login sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config systemctl restart ssh # Firewall: solo SSH, HTTP, HTTPS ufw default deny incoming ufw default allow outgoing ufw allow ssh ufw allow 80/tcp ufw allow 443/tcp ufw enable ``` Solo dopo l'hardening installo lo stack applicativo: Nginx, PHP-FPM (versione corrispondente all'inventario), MySQL o MariaDB, Redis, Composer, Certbot per SSL. La [documentazione ufficiale di Laravel sul deployment](https://laravel.com/docs/12.x/deployment) elenca i requisiti server e le ottimizzazioni obbligatorie per la produzione - la seguo alla lettera. ### Fase 3: trasferimento dati con verifica di integrità Il trasferimento non è un semplice `scp`. La sequenza è: ```bash # Sul VPS target, come utente deploy git clone /var/www/app cd /var/www/app composer install --no-dev --optimize-autoloader # Database: dump strutturato con lock per consistenza # Sull'hosting sorgente mysqldump --single-transaction --routines --triggers \ -u user -p database > dump_$(date +%Y%m%d_%H%M%S).sql # Sul VPS target mysql -u root -p -e "CREATE DATABASE app CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" mysql -u root -p app < dump.sql # Verifica: conteggio record sulle tabelle principali mysql -u root -p app -e "SELECT 'users' AS t, COUNT(*) AS n FROM users UNION ALL SELECT 'orders', COUNT(*) FROM orders UNION ALL SELECT 'products', COUNT(*) FROM products;" ``` La verifica del conteggio record è un passaggio che molti saltano, e che mi ha salvato più volte. In un caso specifico, il dump dall'hosting condiviso si era interrotto silenziosamente a metà della tabella `order_items` - 12.000 righe su 48.000. Senza il conteggio incrociato, il cliente avrebbe scoperto il problema solo quando un ristoratore avrebbe cercato lo storico ordini del 2024. ### Fase 4: configurazione applicativa e warm-up cache ```bash cp .env.example .env # Configurazione manuale di DB_*, REDIS_*, MAIL_*, APP_URL php artisan key:generate php artisan migrate --force php artisan optimize php artisan storage:link ``` Il comando `php artisan optimize` - introdotto come comando unificato nelle versioni recenti di Laravel - compila in cache configurazione, route, view ed eventi in un'unica operazione. In produzione è obbligatorio: riduce i tempi di bootstrap del 40-60% eliminando il parsing dei file a ogni richiesta. ### Fase 5: cutover DNS e verifica post-migrazione Il cutover è il momento in cui il dominio punta al nuovo server. Lo faccio sempre di sera o nel weekend, con un TTL DNS abbassato a 300 secondi almeno 48 ore prima. Dopo il cutover, verifico: - Risposta HTTP 200 su tutte le route principali - Login funzionante (sessioni, CSRF token) - Job in coda che vengono processati (`php artisan queue:monitor`) - Certificato SSL attivo e valido (`certbot --nginx -d dominio.it`) - Backup automatico configurato e primo backup eseguito con successo Se tutto è green, alzo il TTL DNS a 3600 secondi e disattivo il vecchio hosting. Non lo cancello per almeno 30 giorni - è il mio fallback estremo. ## Cosa fare dopo la migrazione: il debito tecnico non finisce qui La migrazione è solo il primo passo. Un VPS senza manutenzione è più pericoloso di un hosting condiviso, perché ti dà l'illusione del controllo senza l'obbligo di esercitarlo. L'[OWASP Top 10 2025](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/) classifica la Security Misconfiguration come il secondo rischio più critico per le applicazioni web, con un tasso di incidenza del 100% nei test effettuati. Su un VPS, la responsabilità dell'hardening è interamente tua. Dopo ogni migrazione, implemento un piano post-migrazione che include: **Backup automatici verificati.** Non backup "che dovrebbero funzionare" - backup che vengono testati con ripristino periodico. Ho documentato le strategie avanzate in un [articolo dedicato ai backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html). **Hardening applicativo e infrastrutturale.** Firewall, fail2ban, aggiornamenti automatici di sicurezza, header HTTP (CSP, HSTS, X-Frame-Options), rate limiting. La checklist completa per applicazioni Laravel e Symfony è documentata nella [guida all'hardening NIS2-ready](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html). **Monitoring proattivo.** CPU, RAM, disco, latenza delle risposte HTTP. Prometheus + Grafana su un secondo VPS dedicato, o servizi SaaS come Uptime Robot per il monitoring base. L'obiettivo è sapere che qualcosa si sta rompendo *prima* che il cliente te lo segnali. **Pipeline CI/CD.** Anche minimale - un deploy script con `git pull`, `composer install --no-dev`, `php artisan optimize`, `php artisan migrate --force`. Automatizzare il deploy elimina la classe di errori "ho fatto un deploy manuale e mi sono dimenticato di eseguire le migration". Per chi prevede una migrazione tra provider in futuro, ho documentato anche la procedura di [migrazione VPS a zero downtime](https://www.mauriziofonte.it/blog/post/migrazione-sicura-vps-unmanaged-zero-downtime-aziende.html). ## Il costo reale della non-migrazione Le PMI che rimandano la migrazione da hosting condiviso a VPS lo fanno quasi sempre per una ragione: "funziona ancora, perché cambiare?". È una domanda legittima, e la risposta è nei numeri. Un hosting condiviso costa tipicamente 5-15 euro al mese. Un VPS equivalente su Hetzner costa 4-8 euro al mese. La differenza di costo infrastrutturale è spesso **zero o negativa**. Il costo reale è nel tempo di migrazione e nella competenza necessaria per farla bene. Ma il costo della non-migrazione è molto più alto. Nel mio lavoro ho visto aziende perdere ordini per settimane a causa di timeout intermittenti attribuiti a "problemi di rete", quando il problema era un hosting condiviso saturo. Ho visto applicazioni compromesse perché un altro tenant sullo stesso server aveva una vulnerabilità sfruttata, e l'attaccante aveva fatto lateral movement sulle directory condivise. Ho visto backup dichiarati dal provider risultare inutilizzabili al momento del ripristino. Questi non sono scenari ipotetici. Sono situazioni che ho gestito personalmente, e che si sarebbero evitate con una migrazione pianificata su VPS al momento giusto. Se stai gestendo un'applicazione Laravel su hosting condiviso e riconosci i segnali che ho descritto - timeout, queue instabili, impossibilità di aggiornare, backup opachi - il momento di migrare è adesso, non dopo il prossimo incidente. [Contattami](https://www.mauriziofonte.it/pages/contattami) per valutare insieme la situazione e pianificare la transizione con un approccio strutturato che protegga i tuoi dati e la continuità del tuo business. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteReverse engineering di Laravel 8 su PHP 7.4 EOL senza documentazione: come ho mappato in dodici giorni il gestionale interno di una catena di cliniche dentistiche veronesi con 23 studi e 180 utenti attivi20 Giugno 2025](https://www.mauriziofonte.it/blog/post/recupero-controllo-laravel-legacy-senza-documentazione.html)[Articolo successivo »Conformità GDPR nelle applicazioni Laravel: dove le PMI sbagliano e come correggere prima di un'ispezione24 Giugno 2025](https://www.mauriziofonte.it/blog/post/gestione-urgente-gdpr-laravel-sicurezza.html) ### Articoli correlati a Migrare da hosting condiviso a VPS per Laravel: perché, quando e come farlo senza perdere dati - [Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/blog/post/migrazione-sicura-vps-unmanaged-zero-downtime-aziende.html) Una PMI ligure con e commerce Laravel su OVH VPS pagava 89€/mese per un server con problemi di I/O ricorrenti. Ho migrato tutto su Hetzner CPX31 · 8 Luglio 2025 ![Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/image/002020070-migrazione-sicura-vps-unmanaged-zero-downtime-aziende.jpg) - [Direttiva NIS2: guida pratica alla compliance per aziende con server su Hetzner, OVH e provider simili](https://www.mauriziofonte.it/blog/post/direttiva-nis2-guida-compliance-server-hetzner-ovh.html) La Direttiva NIS2 sta cambiando le regole della cybersecurity in Europa, con obblighi tecnici precisi e scadenze ravvicinate. Se la tua infrastruttura · 11 Giugno 2025 ![Direttiva NIS2: guida pratica alla compliance per aziende con server su Hetzner, OVH e provider simili](https://www.mauriziofonte.it/image/001730070-direttiva-nis2-guida-compliance-server-hetzner-ovh.jpg) - [Gestione urgente di intrusioni su VPS: guida al ripristino rapido e sicuro per server Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/gestione-urgente-intrusioni-vps-unmanaged-debian-ubuntu.html) VPS compromesso: CPU al 100 , login SSH a forza bruta riusciti, un cryptominer nascosto in /dev/shm camuffato da thread del kernel. Il playbook · 8 Luglio 2025 ![Gestione urgente di intrusioni su VPS: guida al ripristino rapido e sicuro per server Debian e Ubuntu](https://www.mauriziofonte.it/image/002010070-gestione-urgente-intrusioni-vps-unmanaged-debian-ubuntu.jpg) - [Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili](https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html) Infrastructure as Code definisce l'infrastruttura in file versionabili invece che in procedure manuali. Il report Firefly State of IaC 2025 mostra · 27 Mag 2025 ![Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili](https://www.mauriziofonte.it/image/001470070-infrastructure-as-code-iac-benefici-azienda.jpg) - [Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy](https://www.mauriziofonte.it/blog/post/subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.html) Un gestionale PHP su VPS OVH, il freelance sparito da tre mesi, credenziali perse, nessun backup del codice e il certificato SSL in scadenza · 11 Settembre 2025 ![Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy](https://www.mauriziofonte.it/image/002290070-subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.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, "Migrare da hosting condiviso a VPS per Laravel: perché, quando e come farlo senza perdere dati", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/transizione-server-condiviso-vps-laravel.html Pubblicato: 2025-06-23 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.