Hostinger ha costruito Web Apps Hosting intorno a una semplice promessa: spingi il tuo codice da GitHub, un file ZIP o il tuo agente di coding AI, e ottieni un’app live e pronta per la produzione in circa un minuto, senza alcun server da gestire. Volevo capire quanto di tutto ciò reggesse davvero quando sei tu a cliccare su deploy, quindi ecco cosa ho scoperto.

Distribuisci Web App più velocemente con Hostinger

Distribuisci moderne web app su Hostinger con build automatizzate, infrastruttura gestita, CDN globale, SSL, strumenti di sicurezza e una garanzia di rimborso di 30 giorni.

Visita Hostinger

Pro e Contro

Ripartizione del punteggio

Per assegnare un punteggio a Hostinger’s Web Apps Hosting, ho applicato la metodologia di valutazione di HostAdvice, lo stesso approccio standardizzato usato in ogni recensione del sito, così i punteggi restano ancorati a test reali e non al linguaggio del marketing. Ecco come si è classificato in ogni parametro.

Ospita le tue Web App senza il peso del DevOps

Distribuisci moderne applicazioni web su hosting completamente gestito con deploy automatizzati, SSL gestito, CDN globale e sicurezza integrata.

Visita Hostinger

Piani e prezzi

Hostinger vende Web Apps Hosting in due livelli, Business e Cloud Startup, entrambi costruiti appositamente per distribuire app Node.js e moderne applicazioni JavaScript, invece dei tradizionali website builder.

Cloud Startup, il livello che ho testato, raddoppia il numero di app consentite e i core CPU rispetto a Business, e entrambi i piani includono un dominio gratuito, un’email business gratuita e SSL gestito per il primo anno direttamente nel checkout.

Ci sono alcune cose da sapere prima di ordinare:

• Garanzia di rimborso: Web Apps Hosting rientra nelle condizioni standard di rimborso di Hostinger, una finestra netta di 30 giorni dalla data di acquisto. Questo è molto più semplice rispetto ai piani VPS di Hostinger, che hanno un cooldown aggiuntivo di 180 giorni tra una richiesta di rimborso e l’altra. Qui non si applica alcun cooldown del genere.
• Prova gratuita: Non ho trovato una prova gratuita dedicata. La garanzia di rimborso di 30 giorni è la tua finestra di valutazione.
• Metodi di pagamento: Il checkout mostrava il pagamento con carta come metodo predefinito, con i loghi Visa, Mastercard, Amex e Discover, oltre a un’opzione per aggiungere un metodo di pagamento diverso durante il checkout.
• Cosa è incluso: Un dominio gratuito per un anno, caselle email gratuite per un anno e SSL gestito sono tutti inclusi senza costi aggiuntivi oltre al prezzo del piano, quindi il prezzo esposto è molto vicino al costo reale per mettere online un deploy completamente funzionante e protetto.
• L’unico upsell: Hostinger Reach, un add-on di email marketing, appare nel carrello come una propria box evidenziata con un prezzo mensile separato. È facile da saltare e non viene incluso né preselezionato di default.

Se annulli un piano Web Apps Hosting entro 30 giorni, la policy di rimborso di Hostinger conferma che rientra nei termini standard invece che nell’elenco delle esclusioni, quindi una cancellazione semplice entro quella finestra dovrebbe dare diritto a un rimborso senza le condizioni aggiuntive applicate agli acquisti VPS o dominio.

Funzionalità

• Rilevamento automatico del framework e della versione Node
• Strumenti gestiti per la creazione di database MySQL
• CDN globale attiva di default
• WAF e protezione DDoS inclusi
• Backup giornalieri e su richiesta
• Scanner malware e scansione delle vulnerabilità
• Integrazione GitHub con auto-deploy
• Dominio, email e SSL gratuiti
• Accesso SSH per utenti avanzati

Dal codice all'app live con Hostinger

Collega il tuo repository GitHub o carica il tuo progetto e mettilo online con infrastruttura gestita, deploy automatici e backup giornalieri.

Visita Hostinger

Prestazioni

Poiché Web Apps Hosting è completamente gestito, non ottieni mai accesso shell a un server, quindi non c’è CPU, RAM o disco da benchmarkare direttamente come faresti in una recensione VPS.

Quello che puoi misurare è quanto velocemente l’app distribuita si carica e risponde, da luoghi reali in tutto il mondo. Ho testato questo da quattro angolazioni separate: GTmetrix da due continenti, un controllo di coerenza globale su oltre 50 punti e lo strumento di velocità integrato di Hostinger sia per desktop che per mobile.

L’app sotto test è il deploy Next.js trattato nella sezione Facilità d’uso qui sotto, attivo su ivory-llama-856835.hostingersite.com, in esecuzione sul piano Cloud Startup (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), con CDN attiva di default.

1. GTmetrix, testato da due continenti

Ho eseguito GTmetrix due volte da diverse parti del mondo per vedere se il risultato reggesse in modo coerente o se sembrasse buono solo da un punto di vista fortunato.

Entrambe le esecuzioni hanno ottenuto un perfetto 100% sia in Performance che in Structure, con zero layout shift e zero blocking time in entrambe le località, il che significa che nulla nella pagina ha gareggiato per l’attenzione del browser o è saltato mentre caricava.

Il dettaglio davvero interessante è che Frankfurt ha effettivamente superato Chicago in ogni metrica di timing, nonostante abbia scelto deliberatamente una posizione server statunitense per questa app. Questo risultato ha senso solo alla luce della CDN.

Una volta che una CDN è attiva, come in questo caso di default, il visitatore non raggiunge necessariamente direttamente il server origin.

Raggiunge il nodo edge cache più vicino, quindi un punto di test europeo può finire per essere più veloce di uno statunitense anche quando il server reale si trova negli USA. Questa è una conferma concreta e misurabile che la CDN attivata di default da Hostinger sta davvero facendo il suo lavoro e non è solo una casella di marketing.

2. Coerenza globale (Check-Host)

Ho eseguito un controllo HTTP sull’URL live da ogni checkpoint offerto da Check-Host, 54 località distribuite su sei continenti. Il quadro completo:

Ogni controllo riuscito ha restituito un pulito 200 OK, nessun errore, nessun fallimento parziale, nessun redirect imprevisto.

I tempi di risposta raccontavano chiaramente come funziona il caching della CDN a distanze reali:

I checkpoint europei hanno restituito costantemente i tempi più rapidi, diversi sotto i 50 millisecondi, mentre i checkpoint fisicamente più lontani da qualsiasi nodo edge, Tokyo, Singapore, Ho Chi Minh City, restituivano comunque 200 validi, solo più lentamente, nell’intervallo tra 0.3 e 0.8 secondi.

Questo è il comportamento atteso per un deploy supportato da CDN: veloce vicino agli edge, ancora pienamente funzionante lontano da essi.

I quattro timeout, Kazakhstan, Romania e due dei quattro checkpoint russi, non li leggerei come un problema dell’infrastruttura di Hostinger.

Altri checkpoint negli stessi paesi hanno avuto successo (Saint Petersburg è tornato pulito a 0.063s mentre due checkpoint di Moscow sono andati in timeout), il che punta a un filtraggio di rete regionale sul lato del checkpoint piuttosto che a qualcosa che non va nel deploy.

3. Lo strumento di velocità di Hostinger, desktop e mobile

Hostinger esegue il proprio test Page Speed direttamente nel dashboard dell’app, quindi ho confrontato i suoi numeri con i risultati indipendenti di GTmetrix invece di prendere alla cieca l’uno o l’altro.

Entrambi i tipi di dispositivo hanno ottenuto un 100 perfetto, e i numeri desktop si allineano da vicino a quanto misurato indipendentemente da GTmetrix, che è il vero punto del fare entrambi i test. Due strumenti diversi, due metodologie diverse, e si trovano d’accordo.

Il mobile è risultato più lento in ogni metrica di timing, come prevedibile su una connessione simulata più lenta e un processore più debole, ma comunque abbastanza veloce da far sì che un punteggio di 100 rifletta davvero ottime prestazioni reali su mobile, e non solo una scala di valutazione generosa.

Una incoerenza nello strumento stesso. Anche se il punteggio è un netto 100 su entrambi i dispositivi, il pannello Diagnostics sotto continua a segnalare alcune voci con punteggio letterale 0, network dependency tree, document request latency e avoiding multiple redirects, insieme a due elementi con punteggio 50, unused JavaScript e legacy JavaScript.

Nessuno di questi sotto-punteggi bassi ha abbassato il numero finale, quindi trattali come opportunità di ottimizzazione minori e realmente presenti, non come qualcosa di sbagliato nel deploy.

Separatamente, i “helpful links” che Hostinger mostra accanto a queste diagnostics sono tutti scritti per WordPress, “Speed up WordPress in 9 easy steps,” “How to optimize images for your WordPress site”, nonostante questo sia un’app Node.js senza alcun WordPress in tutta la stack. È un residuo di un template di diagnostica condiviso, non contenuti creati per questo prodotto.

Verdetto complessivo sulle prestazioni

Web App gestite da Hostinger

Concentrati sulla costruzione della tua app mentre Hostinger si occupa di deploy, infrastruttura, sicurezza, SSL, backup e distribuzione globale.

Visita Hostinger

Facilità d’uso

Ho testato Hostinger’s Web Apps Hosting dalla landing page fino al checkout, e poi da un account nuovo fino a un deploy Node.js completamente live e funzionante.

Questo ha coperto la scelta di un piano, il pagamento, la selezione del metodo di build, la connessione a GitHub e la visione della build completarsi in tempo reale. Ecco com’è andato davvero il processo.

1. Registrazione

Ho iniziato dalla landing page di Web Apps Hosting, che si apre con un’unica call to action: Start deploying.

Facendoci clic non si apre un modulo di registrazione. Ti porta direttamente alla sezione prezzi, quindi la prima vera decisione che prendi è quale piano comprare, non quali dati di account inserire.

Due piani erano affiancati:

Ho scelto Cloud Startup per avere il doppio del numero di app e più margine CPU rispetto al livello base. Una piccola incoerenza da segnalare qui: la pagina dei prezzi lo chiama “Cloud Startup”, ma una volta nel carrello lo stesso piano viene etichettato come “Startup plan”. Non è un problema funzionale, solo una discrepanza di nome tra due schermate dello stesso flusso di checkout.

Il carrello era pulito. Elencava il termine di 48 mesi, i risparmi, un dominio gratuito per un anno e le mailbox gratuite, poi proponeva un solo upsell, Hostinger Reach email marketing, dentro una propria box evidenziata e non preselezionata.

L’ho saltato e ho cliccato Continue senza attriti.

Se sei un nuovo cliente invece che uno esistente, il checkout inserisce qui una fase di creazione account prima di arrivare alla pagina dell’indirizzo di fatturazione e del pagamento.

Successivamente aggiungi un indirizzo di fatturazione, scegli un metodo di pagamento, carta, PayPal o una delle altre opzioni, e invii. Ho ricevuto un’email di conferma acquisto pochi istanti dopo aver cliccato Submit payment, poi sono arrivato direttamente nell’hPanel con il piano già provisionato.

Cosa ne penso: Il checkout è breve e l’upsell è facile da rifiutare senza cercare un link nascosto per saltarlo. La discrepanza nel nome del piano tra la pagina prezzi e il carrello è una piccola cosa, ma è il tipo di dettaglio che fa fermare un acquirente alla prima esperienza e controllare di aver scelto il livello giusto.

2. Dashboard

Una volta che il pagamento va a buon fine, arrivi in hPanel, il pannello di controllo proprietario di Hostinger costruito per gestire tutti i prodotti che vende, non una pagina creata specificamente attorno alla tua nuova Web App.

La pagina su cui arrivi per prima è Home, ed è costruita attorno a una barra di prompt AI in alto: “Hi, [your name]! How can I help you today?” con un campo di testo sotto e sei pulsanti rapidi: Get domain, Create website, Get email, Migrate site, Get VPS e Try email marketing.

Scorrendo oltre troverai:

• Tile promozionali di funzionalità per AI Builder, lo strumento online store, che rivendicano un business email gratuito, AI agents, un’app di automazione e un dominio gratuito
• Una checklist di cose da fare che spinge verso attività di setup, completare la configurazione di Reach, reclamare la tua email gratuita, reclamare il tuo dominio gratuito
• Your business, un elenco in corso di tutti i siti, app e istanze VPS collegati al tuo account, ciascuno con il proprio pulsante Manage site
• VPS, una tabella separata più in basso che elenca eventuali istanze VPS per indirizzo IP, stato e data di scadenza

Un pannello Agent si trova anche in modo permanente nell’angolo in alto a destra di ogni pagina di hPanel, non solo su Home. È lo stesso assistente Kodee usato per il supporto, ma posizionato qui come strumento di azione generale con prompt già pronti come “Deploy my Node.js app” o “Harden VPS updates” che puoi avviare senza digitare una domanda completa.

Home è davvero utile una volta che la tua app esiste già, tutto in Your business collega direttamente ad essa. Ma non è il posto in cui vai per creare una nuova Web App o raggiungere il pulsante Setup. Per quello, devi seguire un percorso diverso nella sidebar:

1. Clicca su Websites nella sidebar a sinistra
2. Si espande un sottomenu sotto di esso: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Clicca su Web Apps

Quel clic ti porta a una schermata completamente diversa da Home, organizzata attorno ai tuoi piani di hosting reali invece che a una barra di prompt.

Qui, ogni piano che possiedi ha la propria card. Nel mio account, ciò significava tre card impilate verticalmente:

La card Business aveva anche già un’app attiva elencata sotto da test precedenti, orange-walrus-700988.hostingersite.com, con i propri pulsanti Tools e Dashboard.

È una cosa utile da notare di per sé. Una volta che una Web App esiste, la sua card aggiunge una riga del genere che mostra direttamente il sito live, ed è esattamente l’aspetto che avrà la tua card Cloud Startup una volta completato il setup.

Dato che Cloud Startup era il piano che avevo appena acquistato e non ancora configurato, la sua card mostrava invece un singolo pulsante Setup. È quel pulsante che avvia davvero il wizard di creazione della Web App, e compare solo qui, sotto Websites → Web Apps, non dalla schermata Home in cui arrivi di default.

Cosa ne penso: hPanel è chiaro una volta che trovi la schermata giusta, ma Web Apps Hosting non ha una porta d’ingresso evidente. Atterrare su Home ti mostra una barra prompt e delle scorciatoie, non un percorso per creare un’app; devi sapere di cliccare su Websites, poi su Web Apps, prima ancora che appaia Setup. Sono un paio di clic in più per un prodotto venduto come “live in a minute”. Una volta arrivato lì, però, le card dei piani sono pulite e oneste sullo stato, e un piano con un’app già in esecuzione la mostra direttamente sulla card.

3. Distribuzione dell’app

Facendo clic su Setup sulla card del piano si apriva un breve flusso di onboarding: Where would you like to start? con tre opzioni, Create a new site, Migrate an existing site o I hired someone to build my site. Ho scelto Create a new site.

Questo portava a How do you want to build your website?, diviso in due opzioni rivolte ai principianti in alto, Hostinger AI Builder e WordPress + AI, e due opzioni sotto un’intestazione separata “for advanced users” in basso: Node.js web app e PHP/HTML website. Selezionare Node.js web app è ciò che ti porta effettivamente al prodotto Web Apps Hosting.

Questo è un vero dettaglio strutturale per chiunque stia confrontando i prodotti: Web Apps Hosting non ha un proprio flusso di registrazione dedicato.

È un ramo all’interno dello stesso wizard generale di creazione sito usato per AI Builder e WordPress.

Ho cliccato sul cerchio accanto a Node.js web app, poi ho cliccato Next.

Da lì:

• Schermata del dominio: ho scelto Use temporary domain invece di collegare un dominio reale, visto che si trattava di un deploy di test.

• Schermata della posizione server: Hostinger aveva preselezionato France, la regione più vicina al mio paese di fatturazione, e la mostrava a 167ms di latenza. Scorrendo fino all’opzione United States si vedevano 364ms, più del doppio.

Ho scelto comunque United States, Massachusetts, e questa è esattamente la lezione che il selettore di posizione insegna su ogni prodotto Hostinger: scegli in base a dove si trovano i tuoi visitatori reali, non al numero più basso nell’elenco.

Il pubblico previsto per la mia app di test è basato negli USA, quindi un server negli Stati Uniti li servirà davvero più velocemente di quanto farebbe un server in France, indipendentemente da ciò che il selettore mi mostrava dalla mia posizione. Il numero sullo schermo ti dice quanto velocemente il server risponde al test di Hostinger, non quanto velocemente risponderà alle persone che useranno davvero il tuo sito.

• Schermata del metodo di deploy: due opzioni principali, Import Git repository (segnata come Recommended) o Upload your files, più un callout sotto per distribuire direttamente da Claude Code, Cursor o VS Code tramite Hostinger Connector. Ho scelto Import Git repository e ho cliccato Connect with GitHub.

Questo ha aperto una vera finestra di accesso a GitHub se non eri già connesso, poi una schermata di autorizzazione intitolata Install & Authorize Hostinger, che ti chiedeva di scegliere tra:

• L’installazione su all repositories che possiedi, incluse quelle future, con accesso in sola lettura ai repository pubblici
• L’installazione su only select repositories scelti singolarmente e l’elenco esatto dei permessi concessi: accesso in lettura ad actions, metadata e repository hooks, e accesso in lettura e scrittura a administration, code e pull requests. Una volta che fai clic su Install & Authorize, GitHub ti reindirizza automaticamente di nuovo dentro hPanel.

Arrivi su Select Git repository to import, un elenco scorrevole di tutti i repository collegati al tuo account GitHub, ciascuno con il proprio pulsante Deploy accanto. Ho trovato il repository di test che avevo pushato in precedenza, hostadvice-webapps-test, e ho cliccato Deploy accanto ad esso.

Dal clic su quel pulsante, sono passati quasi 30 secondi senza alcun indicatore di avanzamento sullo schermo, abbastanza da farti chiedere se il clic fosse stato registrato o meno.

La pagina che si carica finalmente è intitolata Review build settings, e ti dice esattamente dove vivrà la tua app prima che tu confermi qualcosa: “Deploys to ivory-llama-856835.hostingersite.com.” Sotto, senza che tu toccassi un solo campo, aveva già rilevato automaticamente:

Ogni una di queste cinque righe ha il proprio pulsante Change o Add accanto, quindi nulla qui è bloccato se il rilevamento sbaglia qualcosa.

Ho cliccato Add accanto a Environment variables e ho impostato una coppia chiave-valore per confermare che sarebbe arrivata davvero all’app in esecuzione più tardi, poi ho cliccato Finish in quella finestra, poi ho cliccato il pulsante principale Deploy in fondo alla pagina.

Osservare la build

La schermata passa a una vista Deploying… con una barra di avanzamento etichettata, “Deployment from GitHub”, che cresce in fasi reali: l’ho vista passare al 28%, poi al 51%, mentre si avviava verso il completamento. Sotto la barra di avanzamento c’è un pannello Build logs collassabile, e aprirlo mostra output terminal live mentre accade, non uno spinner segnaposto:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Deploy completato

Una volta finita la build, arrivi a una schermata Deployment completed! con un’anteprima live in miniatura della tua app reale resa direttamente lì nella card, accanto a un riepilogo che mostra il nome del repository e l’URL live assegnato.

Da questa pagina puoi cliccare direttamente su Go to dashboard, che è dove gestisci l’app in seguito.

Cosa ne penso: Il rilevamento automatico è il vero punto forte qui. Framework, branch e Node version sono stati tutti correttamente rilevati senza un solo campo manuale, e il log di build live rende l’attesa trasparente invece che opaca. L’unico punto debole è quella pausa di 30 secondi prima ancora di raggiungere la schermata delle impostazioni, abbastanza lunga da farti pensare che qualcosa si sia bloccato prima che il processo inizi davvero a mostrarsi.

4. Conferma del deploy live

Prima di esplorare qualunque strumento di gestione, volevo confermare che l’app fosse davvero stata distribuita e funzionasse, non solo contrassegnata come “Completed” sullo schermo.

Dalla pagina Deployment completed, ho cliccato direttamente sull’URL live, ivory-llama-856835.hostingersite.com, invece di fidarmi solo della miniatura di anteprima del dashboard.

La pagina live si è caricata e ha mostrato esattamente ciò che l’app era stata programmata per mostrare:

• Server build time, un timestamp live che conferma che la pagina è stata compilata di recente, non servita da una cache vecchia
• Controllo variabile d’ambiente, che mostrava la variabile personalizzata che avevo impostato durante la schermata di deploy, confermata correttamente sul sito live reale, non solo nell’anteprima del dashboard

Ho poi cliccato il pulsante Ping the API route dell’app, che chiama un endpoint backend live invece di limitarsi a renderizzare contenuto statico. Ha restituito una risposta JSON pulita:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

Quella risposta conta più di quanto possa sembrare. Il caricamento corretto di una pagina prova solo che i file statici sono stati caricati.

Una chiamata API funzionante prova che il vero server Node.js è in esecuzione sotto e risponde a richieste reali, la parte del hosting “Node.js web app” che è facile da simulare con un file statico e difficile da simulare con un timestamp del server live generato esattamente nel momento in cui fai clic su un pulsante.

Cosa ne penso: Questo è il controllo che consiglierei prima di fidarti di qualsiasi deploy su questa piattaforma, o su una simile. Uno stato verde “Completed” e una miniatura di anteprima ti dicono che la build è finita. Cliccare sull’URL live e attivare qualcosa di dinamico, una chiamata API, una lettura del database, qualsiasi cosa che non possa essere falsificata da una pagina statica in cache, ti dice che il server è davvero attivo e fa ciò che hai costruito per fare.

5. Gestione della Web App

Con l’app live confermata funzionante, sono tornato in hPanel ed ho esplorato il dashboard di gestione dell’app end to end, il vero livello di gestione del server di questo prodotto, separato dalla Home generale di hPanel trattata prima.

Panoramica del dashboard. Nel momento in cui arrivi qui, quattro badge di stato ti mostrano lo stato generale a colpo d’occhio:

Tutti e quattro sono risultati verdi di default, senza che io dovessi attivare nulla manualmente. Sotto c’è una scheda Last deployment che conferma stato, repository, autore, commit, ora di deploy, stack rilevato e Node version, tutto ciò che vorresti verificare a colpo d’occhio senza scavare nei log.

Un test automatico Page Speed era già stato eseguito sul sito live da solo e aveva restituito un punteggio Desktop di 99/100 senza che lo avessi avviato io, accanto a un pannello Essentials con collegamenti rapidi a database connection, backup, file manager, runtime logs e cache.

Deployments, variabili d’ambiente e log. Tre pagine separate coprono questo ambito:

• Deployments manteneva un registro completo del push, autore, branch, hash del commit e stato di completamento, una cronologia reale e non solo l’ultima voce
• Environment variables mostrava correttamente quella che avevo impostato durante il deploy, confermando che era stata salvata e applicata, non solo mostrata una volta durante il setup e poi dimenticata
• Runtime logs trasmetteva in streaming l’output live del server mentre accadeva, le righe di avvio di Next.js, i timestamp di ready e un conteggio continuo di issue ed errori, che sono rimasti zero e zero per tutto il tempo in cui ho osservato

Sicurezza. Il Malware Scanner ha restituito un risultato pulito, “Your website is safe”, con una precisazione indicata chiaramente invece che nascosta nel testo piccolo: controlla solo i file del sito, non il contenuto del database, e per una pulizia più profonda che includa il database esiste un’opzione a pagamento. Anche la scansione Vulnerabilities è tornata pulita.

Database. Qui il marketing del prodotto crea un vero divario che dovresti capire prima di acquistare. La pagina del piano pubblicizza il managed MySQL come funzionalità principale, ma nulla viene provisionato automaticamente per te.

La sezione Databases si apre su un modulo manuale Create a New MySQL Database And Database User, il che significa che devi nominare e creare il database tu stesso prima che la tua app possa usarne uno. L’ho confermato direttamente con Kodee, trattato nella sezione Supporto qui sotto, e la risposta è stata diretta: managed significa che Hostinger gestisce l’infrastruttura del database dietro le quinte, non che un database venga creato per te nel momento in cui la tua app va online.

Accesso avanzato. L’accesso SSH esiste sotto Advanced, completo di IP, porta e username, ma è Inactive di default e richiede un clic manuale su Enable prima di poterlo usare. File Manager offre la scelta tra navigare solo i file di questa app o tutti i file dell’intero piano di hosting.

Cosa ne penso: Il dashboard quotidiano è completo e ben organizzato. Sicurezza e cronologia dei deploy, in particolare, sono facili da trovare e davvero informative, e il runtime log senza errori insieme alla scansione malware pulita mi hanno dato una reale fiducia che l’app fosse sana, non solo online.

L’unico punto in cui l’interfaccia promette più di quanto faccia è la sezione database, dove “managed MySQL” sulla pagina del piano fa pensare a qualcosa di pronto da usare appena l’app va online, mentre in pratica ottieni un modulo di creazione da compilare tu stesso, semplice da usare, ma pur sempre un passaggio che devi fare da solo.

Verdetto complessivo sulla facilità d’uso

Sviluppa, distribuisci e scala con Hostinger

Ospita moderne web app con integrazione GitHub, MySQL gestito, CDN globale, banda illimitata e strumenti di sicurezza integrati.

Visita Hostinger

Livello di supporto

Ho testato il supporto di Hostinger per Web Apps Hosting tramite Kodee, l’assistente AI integrato in hPanel, poi sono passato alla knowledge base per vedere quanta copertura offre senza dover chiedere a qualcuno. Kodee appare in due punti da distinguere: come Ask AI sul sito marketing pubblico e come pannello Agent disponibile da qualsiasi pagina all’interno di hPanel, incluso direttamente nel dashboard della Web App.

1. Supporto AI (Kodee)

Ho fatto due domande costruite attorno a lacune reali che avevo trovato durante il test, non a ricerche generiche che Kodee poteva risolvere copiando dalla documentazione.

Domanda 1 testava il comportamento in caso di deploy fallito e il momento delle variabili d’ambiente, entrambe vere preoccupazioni di produzione per chiunque pubblichi su questa piattaforma:

If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?

Kodee ha risposto in modo diretto e corretto su entrambi i punti. Una build fallita non sostituisce un’app attualmente in esecuzione; se un deploy precedente è riuscito, l’app continua a servire quell’ultima versione funzionante. Se si tratta del primo deploy e non c’è nulla a cui tornare, l’app rimane offline finché la build non viene corretta e ridistribuita, una risposta chiara e onesta invece di una rassicurazione vaga.

Per le variabili d’ambiente, ha confermato che puoi impostarle prima del primo deploy nelle impostazioni di deployment e, per un’app già attiva, ha spiegato i tre passaggi esatti: aprire Settings e Redeploy, aggiungere o modificare le variabili in Environment variables, salvare e redeployare.

Domanda 2 ha messo alla prova le due lacune che avevo trovato personalmente esplorando il dashboard, la formulazione “managed MySQL” rispetto al modulo di creazione manuale, e SSH inattivo di default:

This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?

La risposta di Kodee ha confermato esattamente ciò che avevo trovato nell’interfaccia, non una versione più morbida. Un database non viene creato automaticamente per ogni Web App; “managed” si riferisce al fatto che Hostinger gestisce il servizio e l’infrastruttura del database, mentre la creazione e configurazione di un database reale è compito tuo, tramite la stessa schermata Create a New MySQL Database che avevo già visto, seguita dall’aggiunta manuale dei dettagli di connessione nelle variabili d’ambiente della tua app.

Per SSH, ha confermato che lasciarlo inattivo non cambia nulla nel modo in cui l’app gira, si distribuisce o si connette a un database. È posizionato esclusivamente come strumento opzionale per comandi CLI, migrazioni o debug diretto dei file, non qualcosa da cui la piattaforma dipende silenziosamente in background.

Cosa ne penso: Entrambe le risposte coincidevano con ciò che avevo già verificato manualmente nel dashboard invece di contraddirlo o attenuarlo, che è il segno di uno strumento di supporto che controlla davvero lo stato del prodotto invece di recitare uno script. Nessuna delle due domande poteva essere risposta copiando una FAQ generica, e Kodee le ha gestite entrambe con risposte specifiche, strutturate, in due parti, in circa un minuto ciascuna.

2. Knowledge base

La knowledge base di Hostinger si apre con una griglia di categorie, 20 categorie in totale, ognuna con un conteggio di articoli. Alcune delle più grandi: AI Builder con 330 articoli, VPS con 276, Email con 127 e Website con 103.

Web Apps Hosting non ha una categoria dedicata. I suoi contenuti sono sparsi tra Getting Started, hPanel e Website, e questo è un vero dato da considerare per chi si aspetta una casa base unica, come avviene per VPS o Email.

La ricerca di “Web Apps” ha restituito 71 risultati in 8 pagine. I primi risultati erano un mix di contenuti direttamente pertinenti e altri solo vagamente collegati:

• How to deploy apps built with Codex on Hostinger, direttamente pertinente
• Hostinger AI Builder: How to create a web app in agentic mode, vicino ma diverso come prodotto
• How to add a Node.js Web App in Hostinger, direttamente pertinente
• How to install Flutter Web on a VPS at Hostinger, un prodotto diverso del tutto
• Diversi articoli di Website Builder sui metodi di pagamento (PayPal, WeChat Pay, BLIK), non pertinenti oltre a condividere le parole “web” e “app” da qualche parte nel testo

Ho aperto uno dei primi risultati, How to deploy apps built with Codex on Hostinger, per verificarne la profondità. Si è rivelato una guida completa e ben strutturata, con framework supportati elencati all’inizio, schermate passo-passo sia per il percorso di importazione da GitHub che per quello di upload ZIP, una sezione sulla configurazione delle build settings con comandi di esempio, una spiegazione della struttura dei file dopo il deploy, una guida al wizard di connessione al database, una sezione sul monitoraggio delle vulnerabilità e una FAQ finale.

Anche se è incentrato specificamente su Codex, la piattaforma sottostante è la stessa dietro il prodotto generale Node.js Web App, quindi gran parte si applica direttamente.

Cosa ne penso: Il conteggio degli articoli nella ricerca sembra forte sulla carta, 71 risultati per un termine, ma una parte significativa di quel volume è rumore proveniente da prodotti non collegati che condividono parole simili. L’articolo che ho aperto per intero ha mantenuto una buona qualità una volta entrato nel dettaglio, con passaggi chiari, screenshot reali e una vera sezione FAQ, ma trovarlo ha richiesto di scorrere risultati che non avevano nulla a che fare con ciò che stavo davvero cercando di distribuire.

Verdetto complessivo sul supporto clienti

Hosting semplice per web app moderne

Distribuisci React, Next.js, Vue, Node.js e altre applicazioni moderne senza gestire server o infrastrutture complesse.

Visita Hostinger

Dovremmo consigliare Hostinger Web Apps Hosting?

Sì. Il processo di deploy è la parte più forte di questo prodotto: rilevamento automatico corretto del mio stack, branch e Node version, un vero log di build in streaming invece di uno spinner, e un’app live che ha superato tutti i test di performance che le ho lanciato, punteggi GTmetrix perfetti da due continenti diversi, un controllo di coerenza globale pulito su 54 punti e punteggi 100/100 corrispondenti dagli strumenti di Hostinger sia su desktop che su mobile. Kodee ha rafforzato tutto questo con risposte accurate e specifiche a domande tecniche reali invece che con risposte scriptate generiche.

I difetti sono piccoli ma vale la pena conoscerli prima di acquistare. “Managed MySQL” sulla pagina del piano sembra qualcosa di pronto nel momento in cui la tua app va online, ma in pratica significa un modulo di creazione manuale. Il dashboard inoltre non offre a Web Apps Hosting un punto d’ingresso dedicato dalla schermata principale Home: devi sapere di entrare prima in Websites.

Per uno sviluppatore che vuole un deploy rapido e agnostico rispetto al framework su un’infrastruttura che ottiene benchmark così buoni, questa è una raccomandazione facile. Per chi si aspetta che ogni funzione pubblicizzata sia attiva nel momento in cui il checkout si completa, metti da parte qualche minuto in più per configurare tu stesso il database.

Hostinger

5.0

2,471 user reviews

€ 1,37 /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