Un allotjament Laravel fet per a la vostra manera de publicar

Sí. Tots els plans vénen amb un terminal SSH complet, així que desplegar és el mateix flux basat en Git que ja feu servir en local. Cloneu el vostre repositori directament des de GitHub, GitLab o Bitbucket dins del compte, executeu composer install per baixar els paquets de vendor i després copieu els vostres valors de producció al .env. A partir d'aquí Artisan pren el relleu: php artisan key:generate fixa la clau de l'aplicació i php artisan migrate construeix l'esquema de la base de dades. Publicar una versió posterior és igual de ràpid: git pull per agafar els commits nous, composer install per actualitzar dependències, php artisan migrate per a les migracions noves i un refresc de la memòria cau per netejar la configuració antiga. Com que teniu un terminal de veritat i no un tauler tancat, podeu seguir registres, arreglar els permisos de storage i tornar a executar qualsevol ordre si cal repassar alguna cosa. Apunteu l'arrel de documents a la carpeta public i el lloc ja és en línia amb HTTPS.

Sí: Composer ve instal·lat a tots els comptes i ja és al vostre PATH, així que no hi ha res per baixar, descomprimir ni configurar abans del primer desplegament. Obriu una sessió SSH en el moment que s'aprovisiona el compte i composer install, composer update, composer require i composer dump-autoload funcionen de seguida contra el binari de PHP correcte. Això compta amb Laravel, perquè el framework i pràcticament tots els paquets que hi afegiu (dels kits d'inici a Sanctum, Horizon i la resta) s'incorporen amb Composer i no confirmant-los al repositori. Manteniu el vostre propi composer.json i composer.lock, així les versions que proveu en local són les que aterren al servidor. Si mai us cal executar Composer amb una versió concreta de PHP, ho podeu fer, perquè la versió de PHP és seleccionable per lloc. En resum, el vostre flux de dependències es comporta exactament igual que a la vostra pròpia màquina.

Teniu PHP 8.x modern, i trieu vosaltres quina versió fa servir cada lloc des del tauler de control. Aquesta flexibilitat compta perquè cada versió de Laravel declara un requisit mínim de PHP: les versions recents esperen PHP 8.1 o superior, mentre que una aplicació antiga amb suport de llarga durada pot estar fixada a una compilació 8.x anterior. En comptes d'imposar un sol entorn d'execució a tot, fixeu la versió per domini, així un projecte antic d'un client i una aplicació nova de trinca poden conviure al mateix compte sense cap conflicte. A més del selector podeu ajustar els paràmetres que importen a Laravel: memory_limit per a ordres d'Artisan i importacions més pesades, max_execution_time per a tasques llargues i l'OPcache perquè el codi compilat es mantingui calent a memòria. Canviar de versió és immediat i reversible, cosa que fa que provar una actualització de PHP tingui poc risc: pugeu primer un domini de proves, confirmeu que la vostra bateria de proves passa i després moveu la producció amb un sol clic.

Totes dues coses hi són de primera categoria. Per a la feina encuada, arrenqueu un treballador persistent amb php artisan queue:work perquè tasques, notificacions, correus i exportacions pesades s'executin fora de la petició web en comptes de bloquejar la càrrega de pàgina d'un visitant. Si sosteniu la cua amb Redis, les tasques s'agafen i es buiden de pressa fins i tot amb trànsit real. Per a la feina programada, no cal afegir una llista llarga de línies de cron separades. En comptes d'això ho registreu tot dins del planificador de Laravel al codi de la vostra aplicació i després afegiu una sola entrada de cron que executi php artisan schedule:run cada minut. A partir d'aquesta única tasca, Laravel decideix quines ordres toquen i les dispara: resums horaris, neteges nocturnes, informes setmanals i el que calgui. Després de cada desplegament, executeu php artisan queue:restart perquè els vostres treballadors carreguin el codi nou. És la configuració estàndard de Laravel funcionant exactament com descriu la documentació, sense cap solució específica de la plataforma que us hàgiu d'aprendre.

Sí. Redis és disponible per a memòria cau, emmagatzematge de sessions i cues, que és la combinació a la qual recorren la majoria d'aplicacions Laravel en producció. Apunteu el vostre controlador de cau a Redis i els resultats de consultes costoses, els fragments dibuixats i els valors calculats se serveixen des de memòria en comptes de reconstruir-se a cada visita. Passeu les sessions a Redis i l'estat de sessió iniciada es manté ràpid i coherent a mesura que creix el trànsit. Fixeu la connexió de cua a Redis i les tasques de fons s'encuen i es processen amb molt poca sobrecàrrega, així els treballadors continuen àgils durant els pics. Tot això ho configureu al vostre .env amb els paràmetres estàndard dels controladors de cau, de sessió i de cua: no cal cap configuració a mida de la nostra banda. Com que Redis manté aquest conjunt de treball a la RAM i no al disc, les pàgines que abans es feien pesades es tornen notablement més àgils, i el processament de fons segueix el ritme en comptes d'acumular-se quan arriba una ràfega de trànsit.

Sí, i és la manera correcta de servir una aplicació Laravel. Laravel manté un únic punt d'entrada al seu directori public i deixa el codi de l'aplicació, el .env i storage per damunt de l'arrel web, així res sensible no és accessible des del web. Des del tauler de control fixeu l'arrel de documents del vostre domini a la carpeta public del projecte, i les peticions passen per index.php exactament com el framework preveu. Combinat amb el SSL gratuït de renovació automàtica, la vostra aplicació respon per HTTPS amb URL netes i sense cap index.php a la barra d'adreces. Els permisos de directori de storage i bootstrap/cache són fàcils de fixar per SSH, així la memòria cau, les sessions i les pujades de fitxers funcionen a la primera. Si allotgeu diverses aplicacions en un sol compte, cada domini té la seva pròpia arrel de documents apuntada a la seva pròpia carpeta public, i així els projectes queden ben separats tot i compartir el mateix servidor NVMe ràpid a sota.

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).