Hosting Laravel costruito sul suo modo di pubblicare

Sì. Ogni piano include una shell SSH completa, quindi il deploy segue lo stesso flusso basato su Git che già usa in locale. Cloni il repository direttamente da GitHub, GitLab o Bitbucket nel suo account, esegua composer install per scaricare i pacchetti vendor, poi copi i valori di produzione nel file .env. Da lì prende il comando Artisan: php artisan key:generate imposta la chiave dell'applicazione e php artisan migrate costruisce lo schema del database. Pubblicare una release successiva è altrettanto rapido: git pull per prendere i nuovi commit, composer install per aggiornare le dipendenze, php artisan migrate per le eventuali nuove migrazioni e un rinfresco della cache per ripulire la vecchia configurazione. Poiché ha una shell vera e non un pannello con le mani legate, può seguire i log, correggere i permessi su storage e rieseguire qualsiasi comando se qualcosa richiede un secondo controllo. Punti la document root sulla cartella public e il sito è online in HTTPS.

Sì: Composer è installato su ogni account e già presente nel suo PATH, quindi non c'è nulla da scaricare, estrarre o configurare prima del primo deploy. Apra una sessione SSH nel momento in cui l'account viene attivato e composer install, composer update, composer require e composer dump-autoload funzioneranno subito con il binario PHP corretto. Per Laravel è importante, perché il framework e quasi tutti i pacchetti che aggiunge — dagli starter kit a Sanctum, Horizon e gli altri — si scaricano tramite Composer invece di essere inclusi nel repository. Mantiene i suoi composer.json e composer.lock, così le versioni che testa in locale sono quelle che arrivano sul server. Se le serve eseguire Composer con una specifica versione di PHP può farlo, dato che la versione è selezionabile per sito. In breve, il suo flusso di gestione delle dipendenze si comporta esattamente come sulla sua macchina.

Ha a disposizione PHP 8.x moderno e sceglie lei quale versione usare per ciascun sito dal pannello di controllo. Questa flessibilità conta perché ogni versione di Laravel dichiara un requisito minimo di PHP: le release recenti richiedono PHP 8.1 o superiore, mentre un'app con supporto a lungo termine più datata può essere vincolata a una build 8.x precedente. Invece di imporre un unico runtime a tutto, imposta la versione per dominio, così un vecchio progetto cliente e un'app nuova di zecca possono convivere sullo stesso account senza conflitti. Accanto al selettore può regolare le impostazioni a cui Laravel tiene: memory_limit per i comandi Artisan e le importazioni più pesanti, max_execution_time per le attività lunghe e OPcache perché il codice compilato resti caldo in memoria. Il cambio di versione è immediato e reversibile, il che rende poco rischioso testare un aggiornamento di PHP: alzi prima un dominio di staging, verifichi che la suite di test passi e poi sposti la produzione con un solo clic.

Entrambi sono di prima classe qui. Per il lavoro in coda avvii un worker persistente con php artisan queue:work così job, notifiche, mailable ed esportazioni pesanti girano fuori dalla richiesta web invece di bloccare il caricamento della pagina di un visitatore. Appoggi la coda su Redis e i job vengono presi e smaltiti rapidamente anche con traffico reale. Per il lavoro pianificato non aggiunge una lunga lista di righe cron separate. Registra invece tutto nello scheduler di Laravel nel codice dell'applicazione e poi aggiunge una sola voce cron che esegue php artisan schedule:run ogni minuto. Da quell'unica attività Laravel decide quali comandi sono in scadenza e li avvia: riepiloghi orari, pulizie notturne, report settimanali e così via. Dopo ogni deploy esegua php artisan queue:restart così i worker caricano il nuovo codice. È la configurazione Laravel standard che funziona esattamente come descrive la documentazione, senza soluzioni alternative specifiche della piattaforma da imparare.

Sì. Redis è disponibile per cache, archiviazione delle sessioni e code, la combinazione a cui ricorre la maggior parte delle app Laravel in produzione. Punti il driver di cache su Redis e i risultati di query costose, i frammenti già generati e i valori calcolati verranno serviti dalla memoria invece di essere ricostruiti a ogni richiesta. Sposti le sessioni su Redis e lo stato di login resterà rapido e coerente mentre il traffico cresce. Imposti la connessione di coda su Redis e i job in background verranno accodati ed elaborati con pochissimo sovraccarico, così i worker restano reattivi durante i picchi. Configura tutto questo nel file .env con le normali impostazioni dei driver di cache, sessione e coda: non serve alcuna configurazione su misura da parte nostra. Poiché Redis tiene questo insieme di dati in RAM anziché su disco, le pagine che sembravano pesanti diventano nettamente più scattanti e l'elaborazione in background sta al passo invece di accumulare arretrati quando arriva un'ondata di traffico.

Sì, ed è il modo corretto di servire un'app Laravel. Laravel mantiene un unico punto di ingresso nella cartella public e tiene il codice dell'applicazione, il file .env e la cartella storage sopra la web root, così nulla di sensibile è raggiungibile dal web. Dal pannello di controllo imposta la document root del suo dominio sulla cartella public del progetto e le richieste passano da index.php esattamente come il framework prevede. Insieme all'SSL gratuito a rinnovo automatico, la sua app risponde in HTTPS con URL puliti e senza index.php nella barra degli indirizzi. I permessi delle cartelle storage e bootstrap/cache si impostano facilmente via SSH, così cache, sessioni e caricamenti di file funzionano al primo colpo. Se ospita più app su un unico account, ogni dominio ha la propria document root puntata sulla propria cartella public, mantenendo i progetti ben separati pur condividendo lo stesso veloce server NVMe sottostante.

Yes. Our team transfers your codebase, exports and imports your MySQL database, and carries over your storage folder so uploaded files and cached data aren't left behind. We bring everything up on a temporary address first so you can confirm queues, the scheduler and Redis-backed sessions all still work, and only then do we walk through the DNS cutover.

Yes, daily backups cover your database and storage directory, giving you a restore point that sits alongside your own Git-based code rollbacks. If a migration or seed command goes wrong, you can restore the previous day's snapshot rather than trying to reverse the damage by hand.

Yes. Addon domains let you point a staging subdomain and your live domain at the same account, each with its own document root and database. Push and test on staging first, run your Artisan migrations there, and only promote to the production domain once you're confident.

Higher tiers support up to 100 MySQL databases, which in practice means room for several Laravel projects — a mix of client sites, side projects and staging copies — on a single account, each with its own domain, database and .env.

Every plan is covered by a 30-day money-back guarantee, so you can deploy your actual project, run it under real traffic, and check queue throughput and Redis caching behave the way you expect before committing beyond the trial period.

Plans are priced in USD starting at $2.42/mo, and geo-currency detection displays that price converted into your local currency at checkout, so what you see is what gets billed rather than a rate you have to calculate yourself. Billing itself runs through Bohzo Ltd (UK).