Hostginger vende il suo Laravel VPS come un server preinstallato e gestito dall’AI, costruito per portare online rapidamente un progetto Laravel. Gran parte di questa promessa è stata confermata durante i test reali, con benchmark solidi, un agente di supporto AI competente, backup confermati in esecuzione secondo la pianificazione.

Un pulsante della dashboard mi ha però portato in un posto in cui non mi aspettavo di finire, ed è bene saperlo prima di cliccarlo anche tu. Ecco l’analisi completa.

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Pro e Contro

Dettaglio della valutazione

Per assegnare il punteggio all’hosting VPS Laravel di Hostinger, ho applicato la metodologia di valutazione di HostAdvice, lo stesso approccio standardizzato usato in ogni recensione del sito, così i punteggi restano coerenti e basati su test reali invece che su affermazioni di marketing. Ecco come si è comportato in ciascun parametro.

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Piani e Prezzi

Hostinger vende l’hosting Laravel come uno dei quattro livelli VPS KVM, da KVM 1 a KVM 8, ognuno dei quali scala insieme core CPU, RAM, spazio disco NVMe e banda man mano che si sale di livello.

Laravel non è un acquisto separato, è un’applicazione installabile con un clic sovrapposta al livello che scegli durante il checkout, con Cloudpanel incluso come vero pannello di controllo per gestire l’installazione una volta online.

Ci sono alcune cose utili da sapere prima di ordinare:

• Termini di fatturazione: I piani si pagano in anticipo con formule da 1, 12 o 24 mesi, e i termini più lunghi offrono sconti reali sulla tariffa mensile. Consulta il widget dei prezzi qui sotto per il dettaglio completo per livello e durata.
• Garanzia di rimborso: I piani VPS includono una garanzia di 30 giorni, ma le condizioni aggiungono un limite reale. Puoi richiedere un rimborso VPS solo una volta ogni 180 giorni, quindi una seconda richiesta su un altro acquisto VPS entro quel periodo non andrà a buon fine. Gli upgrade di un piano VPS esistente sono esclusi del tutto.
• Prova gratuita: Non ho trovato una prova gratuita dedicata per l’hosting VPS Laravel, solo la garanzia di rimborso di 30 giorni. Pianifica il tempo di valutazione tenendo presente questo limite.
• Metodi di pagamento: Carta (Visa, Mastercard, Amex, Discover), PayPal, Google Pay, AliPay nelle varianti separate per Cina e Hong Kong, e Coingate per le criptovalute. I pagamenti in crypto rientrano al di fuori della politica di rimborso, quindi tienilo presente se la garanzia per te conta.
• Cosa è incluso: Ogni livello include un dominio .cloud gratuito per il primo anno, accesso root completo, integrazione Git e Cloudpanel senza costi extra, quindi il prezzo esposto è più vicino al costo reale rispetto agli host che fanno pagare separatamente il pannello di controllo.

Le linee guida ufficiali di Hostinger suggeriscono che KVM 1 sia sufficiente per un semplice sito Laravel, mentre KVM 8 è consigliato per progetti più pesanti e ad alto consumo di risorse.

Da aggiungere a questo, dai test, la confusione sul pulsante Manage App per la gestione dell’app e lo scanner malware lasciato disattivato per impostazione predefinita valgono per tutti i livelli allo stesso modo, quindi aumentare il piano non risolverà nessuno dei due problemi. Scegli il piano in base alle esigenze di CPU e traffico, e gestisci quei due aspetti specifici allo stesso modo indipendentemente dal livello che sceglierai.

Funzionalità

• Processori AMD EPYC su tutti i livelli
• Storage SSD NVMe su tutti i piani
• Integrazione Git per una distribuzione del codice semplificata
• Pieno accesso root via SSH
• Pannello di controllo Cloudpanel incluso di default
• Agente AI per attività di gestione del VPS
• Backup automatici settimanali su ogni piano
• Velocità di rete da 1 Gbps per piano
• Dominio .cloud gratuito per un anno

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Prestazioni

Un’applicazione Laravel vive o muore sul server su cui gira tanto quanto sul codice stesso. Il caricamento delle pagine dipende dalla velocità della CPU per eseguire PHP, le query del database dipendono dall’I/O del disco, sessioni e cache dipendono dalla memoria, e se l’app esegue job in coda o ha visitatori reali, il throughput di rete e la capacità di sostenere il carico contano altrettanto.

Laravel in sé non cambia nulla di tutto questo, è ancora PHP in esecuzione su Linux, quindi il vero test qui è il VPS.

Ho eseguito una suite completa di benchmark sul server, coprendo CPU, memoria, disco, rete e una prova di stress prolungata, per vedere cosa offre davvero questo piano e cosa significa per un’applicazione reale.

L’istanza che ho testato era il piano KVM 2, quello che ho scelto durante il checkout:

• CPU: 2 vCPU, ricavate da un host che esegue un processore AMD EPYC 9354P
• RAM: 7.8GB utilizzabili degli 8GB allocati, più 2GB di swap
• Disco: 96GB utilizzabili dei 100GB assegnati in NVMe
• OS: Ubuntu 24.04.4 LTS, kernel 6.8.0-137-generic

Prima di entrare nei numeri, è utile sapere che la linea Laravel VPS di Hostinger usa gli stessi quattro livelli del resto della gamma VPS, da KVM 1 a KVM 8, e che KVM 2 si colloca al secondo posto dal basso, un gradino sopra l’opzione più economica e ben al di sotto dei livelli KVM 4 e KVM 8 pensati per carichi di lavoro più pesanti e multi-applicazione.

Quello che segue riflette un progetto Laravel di piccole-medie dimensioni, una singola applicazione che serve un traffico reale ma moderato, non una grande piattaforma che esegue diversi servizi su un solo server.

1. Prestazioni CPU

• Single-thread: 1,624.55 eventi al secondo, latenza media 0.61ms, 95º percentile 0.64ms

• Multi-thread, 2 thread: 2,864.02 eventi al secondo, latenza media 0.70ms, 95º percentile 1.10ms

• Deviazione standard dell’equità dei thread: 182.50 su una media di 14,321.5 eventi per thread

Questo numero single-thread, in pratica, significa quanto segue. Una tipica richiesta Laravel, che renderizza una vista Blade, esegue alcune query Eloquent, controlla una sessione, passa la maggior parte del tempo su un solo core CPU a fare lavoro PHP invece di distribuirsi su più core contemporaneamente.

Con 0.61ms di latenza media per evento computazionale in questo test, la CPU non è la parte dello stack che farà sembrare lenta una pagina.

Anche il divario tra latenza media e 95º percentile è ridotto, 0.61ms contro 0.64ms, il che significa che le prestazioni sono rimaste costanti invece di avere richieste occasionali molto più lente delle altre, un pattern che si tradurrebbe in caricamenti di pagina casualmente lenti per i visitatori reali.

Il risultato multi-thread è il numero più utile per capire la concorrenza. Passare da un thread a due ha quasi raddoppiato il throughput, circa 88 percent di efficienza di scaling, il che significa che questo VPS non perde molta capacità a causa dell’overhead o di altri tenant che competono per gli stessi core fisici

In termini pratici, PHP-FPM con due processi worker su questo piano può gestire all’incirca il doppio del volume di richieste rispetto a uno scenario single-thread, prima che la CPU diventi il collo di bottiglia, invece di qualcosa di molto meno del doppio, come accadrebbe se le due vCPU si contendessero i cicli.

Il dato di fairness dei thread, circa 1.3 percent di varianza tra i due thread, conferma che entrambi i core hanno svolto una parte di lavoro simile invece che uno solo portasse il carico mentre l’altro restava inattivo. Per un sito reale, questo significa che le richieste vengono distribuite in modo uniforme tra i worker PHP-FPM invece di accumularsi dietro al worker occupato in quel momento.

2. Velocità della memoria

• Scrittura sequenziale: 5,865.22 MiB/sec

• Lettura sequenziale: 7,155.43 MiB/sec

La velocità della memoria conta per Laravel in un modo facile da trascurare. Ogni lookup di OPcache, ogni lettura di sessione, ogni array o collection che la tua applicazione costruisce durante la gestione di una richiesta vive in RAM, e se sullo stesso server gira anche un livello di cache come Redis, sta competendo per la stessa larghezza di banda della memoria.

A circa 5.9 GiB al secondo in scrittura e 7.2 GiB al secondo in lettura, questo VPS può trasferire dati da e verso la memoria abbastanza velocemente da rendere molto improbabile che le operazioni in memoria siano ciò che rallenta una richiesta; il collo di bottiglia per una tipica app Laravel è quasi sempre il disco o la rete prima della RAM.

Ciò che conta di più per la memoria, però, è la capacità più che la velocità. Con 7.8GB utilizzabili e 2GB di swap a supporto, questo piano può eseguire comodamente PHP-FPM, MySQL o PostgreSQL e una piccola istanza Redis sullo stesso server per una singola applicazione, ma non lascia molto margine se stai eseguendo più siti sullo stesso VPS o un database con un working set grande.

Lo swap è una rete di sicurezza per un breve picco di memoria, non un sostituto della RAM se l’applicazione è davvero sottodimensionata per questo piano.

3. I/O del disco

• Scrittura sequenziale: 740 MiB/s (776 MB/s), 740 IOPS

• Lettura sequenziale: 749 MiB/s (785 MB/s), 748 IOPS

• Lettura/scrittura mista random 4K: circa 9,400 IOPS in ciascuna direzione, circa 36.7 MiB/s di throughput per direzione

La velocità sequenziale è il numero che conta per operazioni grandi e singole, ripristinare un backup del database, estrarre un archivio caricato, scrivere un file di log di grandi dimensioni.

Con circa 740-750 MiB/s in entrambe le direzioni, e con lettura e scrittura che si collocano entro il due percento l’una dall’altra, questo disco non presenta la debolezza sbilanciata in una direzione che si vede su alcuni storage cloud, dove le letture sono veloci ma le scritture sono molto più lente.

Le prestazioni random 4K sono il numero che predice davvero come si comporterà una app Laravel nell’uso quotidiano, perché un database non legge e scrive in grandi blocchi sequenziali, ma legge e scrive piccoli blocchi sparsi sul disco mentre cerca righe, aggiorna indici e scrive il proprio journal di transazione.

Poco più di 9,000 IOPS in ciascuna direzione si traduce in circa 9,000 operazioni database piccole al secondo prima che l’I/O del disco diventi il fattore limitante.

Una tipica pagina Laravel potrebbe attivare da poche a qualche decina di query, a seconda di come è costruita l’app, il che significa che questo disco ha margine per un numero significativo di utenti concorrenti che colpiscono il database contemporaneamente prima che le query inizino a mettersi in coda in attesa dell’accesso al disco.

Servirebbe un carico di lavoro decisamente orientato alla scrittura, logging ad alto volume, una coda molto attiva, scritture frequenti della cache su disco, per raggiungere questo limite specifico.

4. Velocità di rete

• Run 1: Download 990.06 Mbps, Upload 910.87 Mbps, latenza idle 0.31ms, 0% packet loss

• Run 2: Download 985.24 Mbps, Upload 947.82 Mbps, latenza idle 0.27ms, 0% packet loss

Entrambe le esecuzioni hanno ottenuto risultati su un server a Phoenix, Arizona, corrispondente alla località United States che ho selezionato durante il checkout, vicina a un gigabit pieno in entrambe le direzioni con zero packet loss in entrambi i tentativi.

Per un’app Laravel, questo numero conta soprattutto per due cose, quanto velocemente il server può servire asset e risposte API ai visitatori, e, se l’app chiama API esterne o recupera dati da altri servizi, quanto velocemente si completano quelle chiamate in uscita.

Un throughput vicino al gigabit significa che la banda non sarà il vincolo per una tipica applicazione web; servirebbe un volume molto alto di trasferimenti di file grandi, video, grandi download, esportazioni massive, prima che questo diventi il fattore limitante invece di CPU o disco.

I risultati quasi identici su due esecuzioni separate, effettuate a pochi minuti di distanza, escludono anche un risultato fortunato isolato: questo è il comportamento costante della connessione, non un numero che è semplicemente salito una volta.

5. Stress Test

Ho eseguito stressori di CPU, memoria e disco per 180 secondi ciascuno per vedere come il server regge sotto carico sostenuto invece che sotto un picco rapido:

• Stress CPU, 2 worker: 540,042 bogo ops, 0 failures

• Stress memoria, 2 worker: 24,335,966 bogo ops, 0 failures

• Stress disco, 2 worker: 2,655,058 bogo ops, 0 failures

I singoli valori di bogo ops contano meno di ciò che non è accaduto.

Zero worker falliti e zero metriche inaffidabili in tutti e tre i test, eseguiti in sequenza per tre minuti completi ciascuno, significa che il server ha mantenuto CPU, memoria e disco tutti sotto pressione simultanea senza andare in crash, senza degradare in uno stato inaffidabile, e senza restituire risultati che il benchmark stesso ha segnalato come sospetti. Questo è il più vicino che questo tipo di test arrivi a simulare un picco di traffico reale, con più risorse al massimo contemporaneamente, e il risultato è quello che conta di più per chi teme che il sito crolli durante un periodo di forte affluenza invece di funzionare bene solo in test isolati uno per volta.

Verdetto complessivo sulle prestazioni

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Facilità d’uso

Ho testato il VPS Laravel di Hostinger dal checkout fino all’apertura degli effettivi strumenti di gestione inclusi.

Questo ha coperto la scelta di un piano e della posizione del server, la creazione dell’account, il pagamento e poi il capire come gestire davvero un deployment Laravel una volta che il server era online. Quello che segue è com’è andato realmente il processo, compreso un momento in cui l’interfaccia mi ha mandato dove non mi aspettavo di andare.

1. Registrazione

Ho iniziato sulla landing page del VPS Laravel, che si apre con tre affermazioni da ricordare:

• Backup settimanali automatici gratuiti
• VPS gestito dall’AI
• Scanner malware automatico

Ho scelto il piano KVM 2, un compromesso ragionevole per una singola applicazione Laravel piuttosto che per una build pesante, e sono passato al carrello.

Da lì, la pagina del carrello mostrava tutto in un unico schermo:

• Periodo di fatturazione: 1, 12 o 24 mesi, con il risparmio mostrato per ogni opzione
• Posizione del server: regioni raggruppate per continente, con stima della latenza accanto a ciascuna
• Marketplace delle app: oltre mille opzioni one-click tra OS, pannelli e applicazioni

Ho scelto 24 mesi per la tariffa più bassa, poi ho passato più tempo del previsto sulla scelta della posizione del server.

Il Regno Unito risultava con la latenza migliore nell’elenco, ma ho scorsiato comunque il resto delle regioni per confrontarle. Il Nord America mostrava un risultato solido per gli Stati Uniti, e l’opzione più veloce dell’Asia, la Malesia, risultava molto più lenta rispetto a entrambe.

Dato che il sito che avevo in mente avrebbe avuto un pubblico per lo più americano, ho scelto gli Stati Uniti invece dell’opzione tecnicamente più veloce del Regno Unito.

Vale la pena segnalarlo per chiunque confronti le regioni in questa pagina. La latenza migliore per te, seduto davanti al tuo laptop, non è il numero che conta. Conta la latenza verso le persone che visiteranno davvero il sito, quindi scegli in base al tuo pubblico, non ai risultati dei tuoi test personali.

Successivamente, ho aperto il marketplace delle applicazioni, dove Laravel era già selezionato, lo stesso schema di setup one-click che Hostinger usa in tutto il suo catalogo di app. Non c’era nulla da cambiare, quindi sono passato direttamente al checkout.

Ero già loggato in un account Hostinger esistente, quindi la registrazione vera e propria ha richiesto un solo clic.

Dopo di che, la schermata di indirizzo di fatturazione e pagamento offriva:

• Carta, incluse Visa, Mastercard, Amex e Discover
• PayPal
• Google Pay
• AliPay, nelle varianti separate per Cina e Hong Kong
• Coingate, per i pagamenti in crypto

Tutto su un’unica pagina, senza redirect separati. Ho inviato il pagamento, ho ricevuto subito un’email di conferma e sono tornato in hPanel con il nuovo server già elencato come attivo.

Ciò che si nota qui è quanta scelta Hostinger offra al checkout senza rendere nulla obbligatorio.

Il confronto delle posizioni in particolare merita attenzione invece di essere saltato, visto che il suggerimento predefinito della pagina del piano non sempre corrisponderà a chi userà davvero il server.

2. Dashboard/Area clienti

Una volta andato a buon fine il pagamento, hPanel si è aperto sulla home, lo stesso pannello centrale dell’account che gestisce domini, email, website builder e VPS da un unico punto.

Mi ha accolto con il mio nome, una barra prompt AI, una fila di pulsanti rapidi, una checklist di cose da fare e un elenco in continuo aggiornamento di tutti i siti e server dell’account più in basso nella pagina.

Ho poi scorsevuto fino alla tabella VPS, dove il nuovo server risultava già marcato come Running, con hostname, indirizzo IP, piano e data di scadenza visibili senza aprire nulla.

Ho cliccato Manage per entrare nel pannello specifico del server.

Atterrare subito sulla home dell’account dopo il pagamento, con il server già provisionato e visibile nell’elenco, è la parte di questo flusso che funziona sempre bene.

Non c’è una schermata di attesa separata e non c’è bisogno di scavare nei menu per trovare ciò che hai appena comprato.

3. Gestione di Laravel e del server

Cliccando Manage si è aperta la pagina VPS Overview, ed è qui che iniziano a vedersi le vere differenze.

In alto c’era una card app etichettata Laravel con un pulsante Manage App, a conferma che Laravel era stato installato automaticamente durante il provisioning.

Subito sotto c’era una seconda card che non mi aspettavo:

• Cloudpanel, basato su Ubuntu 24.04
• Username admin mostrato in chiaro
• Link per il reset della password
• Il suo pulsante Manage panel, separato da quello della card Laravel sopra

Quella seconda card conta più di quanto sembri. Cloudpanel è un pannello di controllo completo per il server, incluso insieme a Laravel, non un semplice wizard di configurazione, e si è rivelato la vera interfaccia per gestire file, siti e il server giorno per giorno.

Scorrendo oltre entrambe le card, l’istanza Ubuntu 24.04 sottostante era visibile più in basso, segnata come Running, con controlli di riavvio e terminale e i dettagli SSH root disposti allo stesso modo di ogni altro VPS su questo account.

Poiché questo server era stato appena provisionato, i grafici delle risorse non erano ancora popolati; hPanel mostrava un messaggio che invitava a controllare di nuovo tra circa 30 minuti per vedere i dati di utilizzo, un modo onesto di gestire un server che non ha ancora alcuna cronologia di traffico invece di mostrare grafici vuoti come se significassero qualcosa.

Più in basso, ho trovato:

• Gestione delle chiavi SSH
• Regole del firewall
• Snapshot di backup
• Scanner malware: non installato

Quest’ultima riga è la prima vera mancanza. Lo scanner malware è indicato come Not installed, proprio sotto una pagina del piano che elenca uno scanner malware automatico come una delle tre funzionalità principali di questo prodotto. Qualunque sia la promessa del marketing, non è attivo di default sul server che ricevi davvero.

Curioso di vedere se l’altra promessa principale reggesse meglio, ho controllato Backups & Monitoring. Il registro Latest Actions mostrava:

• Un’azione recreate registrata lo stesso giorno
• Voci weekly backup_create, ciascuna marcata Success, risalenti a oltre un mese fa

Questa affermazione risultava confermata dai log dell’account, un contrasto netto rispetto allo scanner malware lasciato disattivato a una sola sezione di distanza.

Vale la pena sapere che Hostinger fornisce alcune delle funzionalità dichiarate di default e ne lascia altre da attivare manualmente, e l’unico modo per capire quali sono quali è andare a controllare, visto che la pagina del piano le presenta tutte come ugualmente incluse.

Ho quindi tornato alla card Laravel e cliccato Manage App, aspettandomi che aprisse una sorta di schermata di setup o gestione file specifica per Laravel, come invece faceva il pulsante di Cloudpanel.

Invece ha aperto una pagina intitolata “Let’s get started”, con link alla documentazione di Laravel e ai tutorial video di Laracasts, e un solo pulsante sotto con scritto Deploy now.

Ho cliccato comunque per vedere dove portasse, e mi ha mandato su laravel.com/cloud, la pagina di registrazione di Laravel Cloud.

Ecco la distinzione da precisare bene.

Laravel Cloud non è un prodotto Hostinger e non ha nulla a che fare con il VPS che avevo appena pagato. È una piattaforma di hosting completamente gestita, separata, costruita e venduta direttamente dal team Laravel, in concorrenza nello stesso spazio di un servizio come Vercel o Heroku, con un proprio sistema di account, i propri prezzi e il proprio credito gratuito iniziale.

Registrarsi lì significherebbe pagare Laravel, oltre a quanto hai già pagato a Hostinger, per ospitare la tua applicazione da un’altra parte del tutto.

Quanto al motivo per cui Manage App punta lì, ho controllato l’articolo ufficiale della knowledge base che anche Kodee citava quando ho chiesto, “How to use the Laravel VPS template at Hostinger“. Quell’articolo spiega come accedere a CloudPanel tramite l’IP del VPS sulla porta 8443, modificare il file .env e lanciare i comandi Composer e Artisan via SSH.

Non menziona mai il pulsante Manage App, e non menziona mai Laravel Cloud. Quindi non è un caso in cui la spiegazione esista da qualche parte ma io non l’abbia guardata.

La guida ufficiale di Hostinger per questo template specifico non riconosce nemmeno l’esistenza di quel pulsante, e Kodee, quando ho chiesto direttamente, ha confermato che Manage App non gestisce il VPS e ha avvertito che iscriversi a Laravel Cloud da lì avrebbe significato una seconda fattura separata.

Chiunque clicchi Manage App aspettandosi di gestire la propria app si ritrova invece davanti alla pagina di registrazione di un prodotto diverso e a pagamento, senza alcuna documentazione che lo segnali in anticipo.

Il pulsante che porta davvero lì si trova una card più sotto. Manage panel, sulla card di Cloudpanel.

Cliccandolo si apre una schermata di login che richiede username e password, e qui è importante essere precisi, visto che il pannello non offre indizi una volta arrivati su quella schermata.

L’username è admin, e la password è quella del server che Hostinger ha inviato via email quando il VPS è stato provisionato per la prima volta, non la password del tuo account Hostinger.

Se quell’email non c’è più, il link Reset accanto al campo password della card Cloudpanel genera una nuova password senza dover scavare nella posta.

Una volta effettuato l’accesso, Cloudpanel si apre su un elenco Sites, con l’hostname del VPS già configurato come sito live, PHP impostato come tipo di applicazione e un link Manage accanto.

Aprendo le impostazioni del sito è apparsa una riga completa di schede: Settings, Vhost, Databases, Varnish Cache, SSL/TLS, Security, SSH/FTP, File Manager, Cron Jobs e Logs.

Questo è un pannello di controllo davvero completo, e vale la pena sottolineare che la scheda Cron Jobs è lì, direttamente nello stesso ambiente. Kodee mi ha guidato nell’aggiungere a mano via SSH l’entry cron dello scheduler, il che funziona bene, ma Cloudpanel ha un modo point-and-click per fare la stessa cosa senza toccare un terminale, e né Kodee né l’articolo della knowledge base hanno menzionato questa possibilità.

Con questa parte chiusa, il menu laterale sinistro su la pagina di gestione del server è dove si trovano i controlli reali.

Ecco cosa offre:

• Overview: la pagina riepilogativa stessa, con le card Laravel e Cloudpanel, l’utilizzo delle risorse e i collegamenti rapidi a tutto ciò che segue
• Settings: configurazione a livello di server, che include cose come reset della password root e modifica dell’hostname
• OS & Panel: controllo del sistema operativo e del pannello di controllo installato sul server
• Backups & Monitoring: si espande in Snapshots & Backups, Server Usage e Latest Actions, dove ho trovato il log dei backup settimanali che confermava la validità della promessa
• Security: copre lo scanner malware e le impostazioni del firewall, la sezione in cui ho trovato lo scanner disattivato
• API: apre la documentazione API di Hostinger in una nuova scheda, per chi automatizza la gestione del server al di fuori del pannello
• DNS Manager: gestione del dominio e dei record DNS collegati al server
• Tutorials: un link esterno ai contenuti di supporto di Hostinger

È una gamma abbastanza ampia da poterla definire una copertura completa per l’amministrazione di un VPS. Impostazioni del server, controllo dell’OS, sicurezza, backup, DNS e accesso API sono tutti rappresentati come categorie separate anziché nascosti dentro un menu di impostazioni generico, e non ho trovato nulla di cui avessi bisogno che mancasse da questo elenco.

Quello che non fa è inglobare strumenti specifici per Laravel: deploy del codice, gestione dei file .env, esecuzione dei comandi Artisan, tutto questo avviene tramite Cloudpanel o terminale, non tramite questa barra laterale.

Questo mi porta al pulsante terminale sulla card Ubuntu. Il suo scopo è offrire accesso diretto alla riga di comando del server, aprendo una sessione SSH live nel browser senza bisogno di un client SSH separato o di copiare una chiave privata sul proprio computer.

Cliccandolo sono entrato direttamente in una shell root, già autenticata, con il banner di benvenuto di Cloudpanel sullo schermo che mostrava il suo indirizzo web e uno strumento CLI chiamato clpctl per gestire il pannello dalla riga di comando.

Per chi è a proprio agio a lavorare da terminale, questa è la strada più veloce per configurare davvero l’installazione Laravel, distribuire il codice, modificare le variabili d’ambiente, eseguire le migrazioni, visto che nulla di tutto questo ha un pulsante dedicato in hPanel.

Verdetto complessivo sulla facilità d’uso

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Livello di supporto

Kodee, l’assistente AI di Hostinger, si trova dietro il pulsante Ask AI in hPanel e gestisce qui il supporto, come fa per tutti gli altri prodotti Hostinger.

L’ho testato con due domande tecniche separate su questo VPS, una riguardante un problema dell’interfaccia che avevo già incontrato, e una seconda, più approfondita, su come Laravel gira davvero in produzione su questo server.

Dopo di ciò, ho consultato la knowledge base di Hostinger per vedere quanta parte di questo territorio copre senza dover chiedere a nessuno.

1. Supporto AI (Kodee)

La mia prima domanda nasceva direttamente dal test della card app Laravel, il cui pulsante Manage App aveva aperto Laravel Cloud, una piattaforma a pagamento separata, invece di qualcosa collegato al VPS stesso.

Ho chiesto direttamente a Kodee se quel pulsante dovesse aprire Laravel Cloud o gestire l’installazione già in esecuzione tramite Cloudpanel, e cosa sarebbe realmente successo se mi fossi registrato a Laravel Cloud da lì.

Kodee ha risposto entro un minuto:

• Ha confermato che Manage App non gestisce l’installazione VPS esistente
• Lo ha identificato correttamente come un link a Laravel Cloud, una piattaforma di deployment separata
• Ha indicato Cloudpanel, accessibile all’IP del VPS sulla porta 8443, come la vera interfaccia di gestione
• Ha avvertito che registrarsi a Laravel Cloud avrebbe creato un ambiente separato e fatturato indipendentemente, senza distribuire nulla sul VPS che avevo già pagato

È una risposta chiara e corretta a una domanda che ha un costo reale se la sbagli, e veniva accompagnata da una citazione alla documentazione di Hostinger, non da un’ipotesi.

Poi ho chiesto qualcosa di più tecnico. Le applicazioni Laravel in produzione dipendono da una voce cron per lo scheduler dei task e da un processo Supervisor per mantenere attivi i worker della coda, e volevo sapere se il template VPS configurasse automaticamente una delle due cose, e se Supervisor stesso sarebbe sopravvissuto a un riavvio se l’avessi configurato io.

Kodee ha detto che avrebbe controllato direttamente il server prima di rispondere, e lo ha fatto:

• Ha segnalato che non era presente alcuna voce cron schedule:run 
• Ha segnalato che non era configurato alcun servizio Supervisor
• Ha segnalato che non era stato impostato alcun worker di coda
• Ha fornito la riga cron esatta necessaria per lo scheduler
• Ha fornito un blocco completo di configurazione Supervisor per un worker di coda, con i flag corretti
• Ha confermato che Supervisor persiste dopo un riavvio una volta abilitato con systemctl enable –now supervisor
• Ha aggiunto il promemoria di eseguire php artisan queue:restart dopo il deploy di nuovo codice, un dettaglio facile da dimenticare che causa veri bug di produzione se omesso

Che cosa ho pensato del supporto AI: Kodee si è meritato le risposte. Confermare l’assenza della cron dello scheduler e del processo Supervisor prima di raccomandare qualsiasi cosa è la differenza tra una risposta da checklist e una risposta fondata su ciò che questo server specifico stava davvero facendo, e il promemoria di riavviare il worker della coda dopo i deploy è il tipo di dettaglio che compare solo quando qualcuno, o qualcosa, capisce davvero come si comportano le code di Laravel in produzione.

Due domande, due risposte accurate e complete, entrambe fornite nel giro di un paio di minuti.

2. Knowledge Base

La knowledge base di Hostinger è organizzata allo stesso modo per ogni prodotto: grandi riquadri di categoria con il numero di articoli, una barra di ricerca e un filtro per categoria in alto.

Invece di navigare, sono andato direttamente alla ricerca e ho digitato “laravel”, ottenendo 15 risultati su due pagine, sensibilmente più di quanto ne restituisca una singola app one-click più limitata.

Vale però una precisazione. Più risultati non significa risultati più pertinenti, visto che diverse corrispondenze erano solo marginalmente collegate: un articolo sulle limitazioni della posta PHP e un altro sui problemi di migrazione del sito comparivano semplicemente perché citano Laravel di sfuggita.

Il risultato più pertinente, “How to use the Laravel VPS template at Hostinger,” spiega come accedere a Cloudpanel, capire la struttura delle cartelle di Laravel, modificare il file .env, eseguire Composer e lanciare le migrazioni.

È una guida solida per far partire un primo progetto Laravel su questo template. Quello che non copre sono lo scheduler o i worker di coda, esattamente il vuoto che Kodee ha dovuto colmare quando gliel’ho chiesto.

Guardando più a fondo nei risultati di ricerca è emerso qualcosa di utile da segnalare. Un articolo più vecchio, “How to deploy Laravel 8 at Hostinger,” include effettivamente un esempio cron funzionante per lo scheduler, ma è scritto per una configurazione diversa e più vecchia, che distribuisce Laravel manualmente su hosting shared o cloud invece che sull’attuale template VPS, con una struttura di file public_html che non ha nulla a che fare con il modo in cui Cloudpanel organizza un VPS.

Chiunque, su questo template VPS, cercasse nella knowledge base indicazioni sullo scheduler finirebbe su un articolo che descrive un prodotto diverso prima di trovare qualcosa che si applichi davvero al proprio server.

Che cosa ho pensato della knowledge base: Il conteggio degli articoli sembra forte sulla carta, 15 risultati per un termine di ricerca, ma il volume grezzo nasconde quanto sia disperso il contenuto davvero utile. L’articolo principale sul template VPS è ben scritto e permette di far partire un primo progetto, ma si ferma esattamente dove un deployment in produzione inizia a farsi serio, e l’unico pezzo di documentazione che copre lo scheduler appartiene a una configurazione di hosting vecchia e diversa.

Un lettore che si affidasse solo alla knowledge base potrebbe facilmente seguire quella guida più vecchia e configurare male il VPS copiando comandi pensati per una struttura di file completamente diversa.

Verdetto complessivo sul supporto

Hosting VPS Laravel di Hostinger

Scopri come Hosting VPS Laravel di Hostinger offre un ambiente flessibile per distribuire applicazioni Laravel con risorse server dedicate, pieno controllo, prestazioni scalabili e configurazioni personalizzabili per progetti web moderni.

Visita Hostinger

Consigliamo l’hosting Laravel di Hostinger?

Sì. Le fondamenta qui sono solide. Laravel e Cloudpanel arrivano preinstallati e funzionanti, l’hardware sottostante ottiene buoni risultati nei benchmark di CPU, memoria e disco, e Kodee ha fornito due risposte tecniche accurate e consapevoli dello stato del server quando l’ho messo alla prova. I backup settimanali risultavano confermati dai log dell’account, esattamente come promesso.

I punti deboli sono limitati ma vale la pena conoscerli prima dell’acquisto. Lo scanner malware indicato come funzionalità principale non era attivo di default, e il pulsante Manage App sulla card Laravel ti indirizza verso Laravel Cloud, un prodotto separato a pagamento, invece di qualcosa che assomigli a una gestione dell’app, senza alcuna documentazione che ti avverta in anticipo.

Nessuno dei due è difficile da aggirare una volta che sai che Cloudpanel è la vera interfaccia di gestione, ma nessuno dei due dovrebbe richiedere di tirare a indovinare.

Per uno sviluppatore che vuole Laravel operativo rapidamente su un’infrastruttura solida, e che è disposto a dedicare cinque minuti a trovare Cloudpanel invece del pulsante etichettato male accanto a esso, questa è una raccomandazione facile. Per chi vuole che ogni funzionalità pubblicizzata sia attiva nel momento in cui il server si avvia, senza dover fare alcun controllo incrociato, conviene prevedere qualche minuto in più di configurazione prima di considerarlo pronto.

Hostinger

5.0

2,471 user reviews

€ 1,38 /mo

Prezzo iniziale

Visita Hostinger

Rating based on expert review

• Intuitività
  4.9
• Supporto
  4.9
• Funzioni
  4.8
• Affidabilità
  4.7
• Prezzi
  4.5