Come è ospitato DevQuake

Questo articolo contiene un link di referral a Hostinger. Se ti iscrivi tramite quel link possiamo ricevere una commissione, senza costi aggiuntivi per te. Il nostro hosting lo paghiamo noi, e tutto ciò che segue ci è successo davvero.

Chi costruisce piccoli siti chiede spesso cosa serve davvero per far funzionare qualcosa come DevQuake. Ecco la nostra configurazione, compresa la parte che è andata male.

Cosa gira e dove

DevQuake è un’applicazione Next.js con app indipendenti, ognuna sul proprio sottodominio: darts.devquake.com, utilities.devquake.com e così via. Gira su un piano Node.js gestito di Hostinger, con database MySQL sullo stesso piano.

Il sito e ogni sottodominio di app eseguono una propria copia dell’applicazione. Questo solo fatto determina quasi tutte le altre scelte, come vedrai.

La pubblicazione è semplice: un merge nel ramo principale avvia una build, che pubblica un pacchetto pronto da eseguire, e l’host lo reinstalla. Sul server non si compila nulla.

A cosa fare attenzione sul prezzo

La pubblicità e i referral del blog aiutano a pagare l’hosting, così le app possono restare senza pubblicità.

L’hosting non è l’unica spesa. Il dominio e il servizio di sintesi vocale dietro le voci naturali del coach di allenamento si pagano a parte. Controlla il prezzo attuale prima di decidere, perché i piani costano spesso molto meno nel primo periodo che al rinnovo.

Il giorno in cui abbiamo finito le risorse

Il 22 ottobre 2026 il nostro piano ha finito le risorse. Le pagine hanno iniziato a rispondere con la pagina di errore 503 dell’host, o semplicemente si bloccavano.

La causa erano i thread. Un piano come il nostro limita i processi e i thread che puoi eseguire, 120 nel nostro caso. Ogni copia dell’applicazione richiedeva circa sette thread, e con più di una dozzina di copie eravamo vicini al limite prima ancora che arrivasse un visitatore.

Cosa abbiamo cambiato

• Le copie inattive si chiudono. Un sottodominio che nessuno usa si spegne e riparte alla visita successiva. Un’app poco usata non costa quasi nulla, al prezzo di una prima pagina più lenta.
• Meno thread per copia. Node.js può girare con pool di thread più piccoli di quelli predefiniti, e i nostri ora sono limitati.
• Niente lavori sempre attivi. Il lavoro pianificato gira in un’unica esecuzione comune, non in timer dentro ogni processo.
• Il lavoro pesante avviene nel browser. Leggere la foto di un contatore o rimpicciolire un’immagine avviene sul dispositivo del visitatore, non sul nostro server.
• I file stanno nel database. Una pubblicazione sostituisce la cartella dell’applicazione, quindi ciò che è su disco andrebbe perso.
• Ogni nuova funzione passa un controllo dei costi: thread, memoria, lavori e spazio.

A chi è adatta

Va bene se gestisci un sito o poche piccole app, hai traffico moderato, vuoi un solo pannello per domini, SSL, database ed email e non vuoi occuparti di un server.

Non fa per te se ti servono processi in background di lunga durata, moduli nativi con thread propri o molti processi sempre attivi. Raggiungerai il limite dei processi, e ti conviene una VPS.

Cosa diremmo a noi stessi

1. Scopri il limite dei processi prima di aggiungere la decima app. Guarda la pagina delle risorse nel pannello, non solo lo spazio su disco.
2. Conta i thread, non solo la memoria.
3. Inserisci subito lo spegnimento per inattività.
4. Prendi il certificato SSL di un nuovo sottodominio prima di aprirlo, soprattutto se il sito invia HSTS con i sottodomini inclusi: senza, i browser lo rifiutano.

Se vuoi provare

Se questa configurazione si adatta a ciò che stai costruendo, puoi iscriverti con il nostro link di referral: vedi i piani di Hostinger. Non ti costa nulla in più e aiuta a pagare DevQuake. Se non si adatta, una piccola VPS è l’alternativa onesta.

Come funziona DevQuake