Come ridurre i costi di hosting della tua app

Per ridurre i costi di hosting, scopri cosa è davvero in esecuzione e perché, poi lascia tutto in stop quando nessuno lo usa. Sugli host che scalano a zero, un’app inattiva e un database in stop costano pochissimo, quindi i risparmi maggiori di solito arrivano dalla rimozione di ciò che li tiene svegli — più spesso codice che controlla il database ogni pochi secondi — e poi dalla riduzione della banda e dall’eliminazione delle app che nessuno usa.

La maggior parte delle piccole app non ha un problema di traffico. Ha un problema di “qualcosa è sempre acceso”. Questa guida mostra come trovarlo e risolverlo, con prompt da dare a un creatore di app basato sull’IA.

Cosa paghi davvero

Le bollette di hosting delle piccole app derivano da alcune voci. Capire quale sia la più grande ti dice dove guardare.

Molti host moderni, incluso Mythex, scalano a zero: quando nessuno usa l’app, il server si ferma e non costa nulla in calcolo, poi si riattiva alla visita successiva. Così la domanda cambia da “quanto è grande il mio server?” a “perché il mio server è acceso?”.

Passo 1: guarda dove finiscono i soldi

Prima di cambiare qualcosa, apri la pagina di utilizzo del tuo host e individua:

• Quale progetto costa di più. Spesso una sola app è la maggior parte della bolletta.
• Quale categoria — calcolo, database, banda o archiviazione.
• Quando spende. Una linea piatta di notte, quando non hai utenti, è l’indizio che qualcosa tiene sveglia l’app.

Su Mythex, Dettagli utilizzo mostra gli ultimi 30 giorni divisi in Build (l’agente IA) e Run (hosting, banda, database e archiviazione file), con una suddivisione per progetto.

Passo 2: lascia dormire app e database inattivi

Questa è la leva principale per la maggior parte delle piccole app. Un database che va in stop quando è inattivo e si riattiva alla richiesta successiva costa quasi nulla nelle ore di calma. Un database interrogato ogni pochi secondi non diventa mai inattivo, quindi lo paghi tutto il giorno.

I limiti di hosting di Mythex spiegano come funziona per le app pubblicate: un’app in stop non consuma nulla in calcolo, e il database parte alla dimensione minima, cresce mentre è occupato, va in stop dopo 5 minuti di inattività e viene addebitato in base alla sua dimensione moltiplicata per il tempo in cui è stato attivo. Quindi un’app che interroga il database anche solo una volta ogni pochi minuti, di giorno e di notte, viene fatturata come se fosse sempre occupata — mentre la stessa app senza traffico di fondo costa pochissimo.

Cose comuni che tengono sveglia un’app:

• Polling. Una pagina che chiede al server “c’è qualcosa di nuovo?” ogni 2–5 secondi. Se lasci aperta quella scheda su un solo portatile, il database non va mai in stop.
• Dashboard con aggiornamento automatico che ricaricano i dati con un timer, anche quando nessuno le guarda.
• Monitor di uptime che fanno un ping all’app ogni minuto.
• Cicli in background nel codice del server — un setInterval che pulisce o sincronizza i dati per sempre.
• Richieste “keep-alive” programmate che qualcuno ha aggiunto per evitare un primo accesso lento — funzionano impedendo lo stop, cioè esattamente ciò che costa denaro.

Chiedi all’IA di trovarli:

Cerca nel codice tutto ciò che viene eseguito con un timer o interroga ripetutamente il database: polling, setInterval, aggiornamento automatico, cicli in background. Elenca ciascuno, con la frequenza con cui viene eseguito e se gira anche quando nessuno ha la pagina aperta. Non cambiare ancora nulla.

Poi correggili uno alla volta:

La dashboard interroga /api/orders ogni 3 secondi. Cambiala perché si aggiorni solo mentre la scheda del browser è visibile, e ogni 60 secondi invece di 3. Aggiungi un pulsante di aggiornamento manuale.

Se la tua app ha davvero bisogno di aggiornamenti in tempo reale (una chat, un tabellone live), chiedi se può inviare aggiornamenti solo quando qualcosa cambia, invece di chiederli di continuo. Per molte app, “aggiorna quando l’utente torna sulla scheda” è sufficiente.

Passo 3: dimensiona correttamente il server

Le macchine più potenti costano di più all’ora. Molte app create con l’IA partono da una dimensione predefinita che va bene; i problemi nascono quando si chiede “più potenza” per risolvere una lentezza che in realtà dipendeva da una query lenta.

• Mantieni la dimensione più piccola che serve il tuo traffico senza errori.
• Se vedi crash per memoria, chiedi prima all’IA se l’app carica troppo in memoria (un’intera tabella invece di una sola pagina di risultati).
• Aggiungi macchine solo se hai misurato un traffico che le richiede.

Su Mythex, la dimensione della macchina viene scelta alla pubblicazione in base a ciò che l’app richiede, e macchine aggiuntive si avviano solo quando il traffico è alto e tornano in stop quando cala. Il costo segue la dimensione, quindi chiedi in chat una dimensione più piccola se pensi che sia sovradimensionata.

Passo 4: riduci la banda

La banda è ciò che scaricano i visitatori. Le immagini sono di solito la parte più grande.

• Comprimi le immagini e usa formati moderni come WebP o AVIF.
• Ridimensiona le immagini alla dimensione con cui vengono mostrate. Una foto da 4.000 pixel visualizzata come miniatura da 400 pixel spreca quasi tutto ciò che viene scaricato.
• Carica in modo pigro (lazy-load) le immagini sotto la prima schermata.
• Metti in cache i file statici (script, stili, immagini) perché i visitatori di ritorno non li riscarichino. Vedi che cos’è la cache.
• Non far scaricare file pesanti a ogni visualizzazione di pagina.

Controlla ogni immagine dell’app. Ridimensionale alla dimensione più grande con cui vengono mostrate, convertile in WebP e carica in modo pigro tutto ciò che è sotto la prima schermata. Dimmi la dimensione totale prima e dopo.

Pagine più veloci e banda più bassa di solito vanno insieme — vedi come rendere più veloce il tuo sito web.

Passo 5: elimina ciò che nessuno usa

• Annulla la pubblicazione delle app vecchie — deployment di prova, esperimenti terminati, il sito dell’evento dell’anno scorso.
• Elimina upload, log ed esportazioni vecchi che non ti servono.
• Elimina i link di anteprima condivisi che non usi più. Su Mythex, aprire un link di anteprima sveglia il progetto e usa i tuoi crediti, quindi un link dimenticato che qualcuno continua ad aprire costa comunque.
• Rimuovi i servizi inutilizzati — un server API o un worker che l’app non chiama più.

Passo 6: valuta un sito statico

Se il tuo sito non ha login, né dati utente salvati, né logica lato server — un sito marketing, un portfolio, un menu — può essere un sito statico: semplici file serviti da una CDN. Non c’è nessun server né database da tenere in esecuzione. Su Mythex, i siti statici non consumano crediti mentre restano lì.

Questo sito non ha login né dati salvati. Si può ricostruire come sito statico senza server? Cosa perderemmo?

Passo 7: tieni d’occhio le chiamate API a pagamento

Per le app che chiamano modelli IA, mappe o SMS, le bollette dei terzi possono superare di gran lunga l’hosting.

• Richiedi il login per qualsiasi cosa che costi denaro a ogni chiamata.
• Aggiungi un limite per utente (vedi cos’è il rate limiting).
• Metti in cache le risposte che non cambiano, come la geocodifica dello stesso indirizzo.
• Imposta limiti di spesa o avvisi presso ogni provider.

Errori comuni

• Tirare a indovinare invece di misurare. Controlla prima la suddivisione dell’utilizzo; la parte costosa spesso non è quella che ti aspetti.
• Comprare un server più grande per risolvere la lentezza. Di solito la vera causa è un indice mancante nel database o il caricamento di troppi dati.
• Fare polling di tutto. Ogni timer da pochi secondi è un motivo perché il database resti sveglio.
• Fare ping all’app per tenerla “calda”. Così elimini il risparmio che dà lo scala-a-zero. Accetta un breve risveglio alla prima visita, oppure paga per un’app sempre attiva, ma consapevolmente.
• Dimenticare i deployment vecchi. Le app inutilizzate con database e job in background si sommano in silenzio.
• Immagini non compresse. Spesso è il singolo costo di banda più grande sui siti piccoli.

Checklist

• So quale progetto e quale categoria (calcolo, database, banda, archiviazione) costa di più.
• Niente interroga il database ogni pochi secondi quando nessuno guarda.
• Le dashboard si aggiornano con un intervallo sensato oppure solo mentre la scheda è visibile.
• Nessun monitor di uptime o ciclo in background tiene sveglia l’app senza un motivo.
• Il server è la dimensione più piccola che funziona.
• Le immagini sono ridimensionate, compresse e caricate in modo pigro; i file statici sono in cache.
• Le app vecchie sono non pubblicate, i file vecchi eliminati, i link di anteprima inutilizzati rimossi.
• I siti senza dati o login sono statici.
• Le API a pagamento hanno login, limiti per utente e avvisi di spesa presso i provider.

Ridurre i costi su Mythex

Mythex usa un unico saldo di crediti sia per costruire sia per l’hosting, quindi i risparmi sull’hosting lasciano più crediti per costruire. Alcuni punti specifici di Mythex:

• Le app pubblicate e i loro database vanno in stop quando sono inattivi e si riattivano alla visita successiva. Il database va in stop dopo 5 minuti di inattività, quindi eliminare il polling continuo è di solito il guadagno più grande.
• Il piano Pro paga metà della tariffa Free per hosting, database, banda, archiviazione file e la sandbox di anteprima; l’IA costa lo stesso in entrambi i piani. Vedi Crediti.
• Ricevi un’email prima che un saldo basso metta in pausa un’app pubblicata, e le app in pausa conservano database e file.

Per il quadro generale sui costi di esercizio, vedi quanto costa costruire un’app e cos’è l’hosting web.

Domande