Laravel-drift byggd för hur du levererar

Ja. Varje paket kommer med ett fullt SSH-skal, så driftsättningen är samma Git-baserade arbetsflöde du redan använder lokalt. Klona ditt repo direkt från GitHub, GitLab eller Bitbucket in i ditt konto, kör composer install för att hämta dina vendor-paket och kopiera sedan in dina produktionsvärden i .env. Därifrån tar Artisan över: php artisan key:generate sätter din appnyckel och php artisan migrate bygger ditt databasschema. Att leverera en senare utgåva går lika snabbt — git pull för att hämta de nya commitarna, composer install för att uppdatera beroenden, php artisan migrate för eventuella nya migreringar och en cacheuppdatering för att rensa den gamla konfigurationen. Eftersom du har ett riktigt skal snarare än en nedlåst panel kan du följa loggar, rätta rättigheter på storage och köra om vilket kommando som helst om något behöver en andra titt. Peka dokumentroten mot public-mappen så är sajten live över HTTPS.

Ja — Composer är installerat på varje konto och redan i din PATH, så det finns inget att ladda ner, packa upp eller konfigurera före din första driftsättning. Öppna en SSH-session i samma stund ditt konto är skapat så fungerar composer install, composer update, composer require och composer dump-autoload direkt mot rätt PHP-binär. Det betyder något för Laravel, eftersom ramverket och nästan varje paket du lägger till — från startpaketen till Sanctum, Horizon och resten — hämtas in via Composer snarare än checkas in i ditt repo. Du behåller dina egna composer.json och composer.lock, så att versionerna du testar lokalt är de versioner som landar på servern. Behöver du någonsin köra Composer under en särskild PHP-utgåva går det, eftersom PHP-versionen är valbar per sajt. Kort sagt beter sig ditt beroendeflöde precis som på din egen maskin.

Du får moderna PHP 8.x, och du väljer vilken utgåva varje sajt kör från kontrollpanelen. Den flexibiliteten betyder något eftersom varje Laravel-version anger ett lägsta PHP-krav — de senaste utgåvorna förväntar sig PHP 8.1 eller nyare, medan en äldre app med långt stöd kan vara låst till ett tidigare 8.x-bygge. I stället för att tvinga en körmiljö på allt sätter du versionen per domän, så att ett gammalt kundprojekt och en helt ny app kan bo på samma konto utan konflikt. Vid sidan av väljaren kan du trimma de inställningar Laravel bryr sig om: memory_limit för tyngre Artisan-kommandon och importer, max_execution_time för långa uppgifter och OPcache så att din kompilerade kod stannar varm i minnet. Att byta version är omedelbart och går att ångra, vilket gör det lågriskigt att testa en PHP-uppgradering — höj en testdomän först, bekräfta att din testsvit går igenom och flytta sedan produktionen med ett enda klick.

Båda är förstklassiga här. För köat arbete startar du en beständig arbetare med php artisan queue:work så att jobb, notiser, mejl och tunga exporter kör utanför webbförfrågan i stället för att blockera en besökares sidladdning. Backa kön med Redis så plockas jobben upp och betas av snabbt även under riktig trafik. För schemalagt arbete lägger du inte till en lång lista separata cron-rader. I stället registrerar du allt i Laravels schemaläggare i din appkod och lägger till en enda cron-post som kör php artisan schedule:run varje minut. Från den enda uppgiften avgör Laravel vilka kommandon som är på tur och avfyrar dem — timvisa sammanfattningar, nattliga städningar, veckorapporter och så vidare. Efter varje driftsättning kör du php artisan queue:restart så att dina arbetare laddar den nya koden. Det är standarduppsättningen för Laravel som fungerar precis som dokumentationen beskriver, utan plattformsspecifika kringgåenden att lära sig.

Ja. Redis finns tillgängligt för cachning, sessionslagring och köer, vilket är den kombination de flesta Laravel-appar i produktion sträcker sig efter. Peka din cachedrivrutin mot Redis så serveras dyra frågeresultat, renderade fragment och beräknade värden från minnet i stället för att byggas om vid varje träff. Flytta sessionerna till Redis så förblir inloggat läge snabbt och konsekvent när trafiken växer. Sätt din köanslutning till Redis så köas och behandlas bakgrundsjobb med väldigt lite omkostnad, så att arbetarna förblir responsiva under toppar. Du kopplar upp allt detta i din .env med standardinställningarna för cache-, sessions- och ködrivrutin — ingen skräddarsydd konfiguration krävs på vår sida. Eftersom Redis håller den här arbetsmängden i RAM i stället för på disk blir sidor som tidigare kändes tunga märkbart kvickare, och bakgrundsbehandlingen hänger med i stället för att växa till en eftersläpning när en trafikpuff kommer.

Ja, och det är det korrekta sättet att servera en Laravel-app. Laravel har en enda ingångspunkt i sin public-katalog och håller din applikationskod, .env och storage ovanför webbroten, så att inget känsligt går att nå över webben. Från kontrollpanelen sätter du din domäns dokumentrot till projektets public-mapp, och förfrågningarna flödar genom index.php precis som ramverket avser. Kombinerat med gratis SSL som förnyas automatiskt svarar din app över HTTPS med rena, snygga adresser och inget index.php i adressfältet. Katalogrättigheter på storage och bootstrap/cache är enkla att sätta över SSH, så cachning, sessioner och filuppladdningar fungerar första gången. Driftar du flera appar på ett konto får varje domän sin egen dokumentrot pekad mot sin egen public-mapp, vilket håller projekten rent åtskilda samtidigt som de delar samma snabba NVMe-server under.

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