Laravel tárhely ahhoz igazítva, ahogy Ön szállít

Igen. Minden csomag teljes SSH shell-lel érkezik, így a telepítés ugyanaz a Git-alapú munkafolyamat, amelyet már helyben is használ. Klónozza a tárolóját egyenesen GitHubról, GitLabról vagy Bitbucketről a fiókjába, futtasson composer install parancsot a vendor csomagok behúzásához, majd másolja be az éles értékeit a .env fájlba. Innen az Artisan veszi át: a php artisan key:generate beállítja az alkalmazáskulcsát, a php artisan migrate pedig felépíti az adatbázissémáját. Egy későbbi kiadás szállítása ugyanilyen gyors — git pull az új commitokért, composer install a függőségek frissítéséhez, php artisan migrate az új migrációkhoz, és egy gyorsítótár-frissítés a régi konfiguráció ürítéséhez. Mivel valódi shell-je van, nem lezárt felület, naplókat követhet, tárolójogosultságokat javíthat, és újrafuttathat bármely parancsot, ha valamit még egyszer meg kell néznie. Irányítsa a dokumentumgyökerét a public mappára, és az oldal HTTPS-en él.

Igen — a Composer minden fiókon telepítve és már a PATH-on van, így nincs mit letölteni, kicsomagolni vagy beállítani az első telepítése előtt. Nyisson SSH munkamenetet abban a pillanatban, amint a fiókja kiépült, és a composer install, composer update, composer require és composer dump-autoload mind azonnal működik a megfelelő PHP binárissal. Ez a Laravelnél fontos, mert a keretrendszert és szinte minden hozzáadott csomagot — a kezdőkészletektől a Sanctumon és a Horizonon át a többiig — Composeren keresztül húz be, nem pedig a tárolójába commitolva. A saját composer.json és composer.lock fájlját megtartja, így azok a verziók kerülnek a szerverre, amelyeket helyben tesztelt. Ha valaha adott PHP kiadás alatt kell Composert futtatnia, megteheti, mivel a PHP verzió oldalanként választható. Röviden: a függőségkezelési munkafolyamata pontosan úgy viselkedik, mint a saját gépén.

Modern PHP 8.x-et kap, és a vezérlőpultból választja ki, melyik kiadást futtatja az egyes oldalak. Ez a rugalmasság azért fontos, mert minden Laravel verzió minimum PHP követelményt szab meg — a friss kiadások PHP 8.1-et vagy újabbat várnak, míg egy régebbi, hosszú távú támogatású alkalmazás egy korábbi 8.x buildhez lehet rögzítve. Ahelyett, hogy egyetlen futtatókörnyezetet kényszerítenénk mindenre, Ön domainenként állítja be a verziót, így egy örökölt ügyfélprojekt és egy vadonatúj alkalmazás konfliktus nélkül élhet ugyanazon a fiókon. A verzióválasztó mellett hangolhatja azokat a beállításokat, amelyek a Laravelnek számítanak: a memory_limit értéket a nehezebb Artisan parancsokhoz és importokhoz, a max_execution_time értéket a hosszan futó feladatokhoz, és az OPcache-t, hogy a lefordított kódja melegen maradjon a memóriában. A verzióváltás azonnali és visszafordítható, ami alacsony kockázatúvá teszi egy PHP frissítés tesztelését — előbb egy staging domaint léptet fel, ellenőrzi, hogy a tesztkészlete lefut, majd egyetlen kattintással átviszi az élest is.

Mindkettő elsőrangú szerepet kap nálunk. A sorba állított munkához indítson tartós sorkezelőt a php artisan queue:work paranccsal, hogy a feladatok, értesítések, levelek és nagy exportok a webes kérésen kívül fussanak, ahelyett hogy blokkolnák egy látogató oldalbetöltését. Támogassa a sort Redisszel, és a feladatok valós forgalom alatt is gyorsan felvevődnek és lefutnak. Az ütemezett munkához nem kell hosszú listányi külön cron sort felvennie. Ehelyett mindent a Laravel ütemezőjében regisztrál az alkalmazáskódjában, majd hozzáad egyetlen cron bejegyzést, amely percenként futtatja a php artisan schedule:run parancsot. Ebből az egyetlen feladatból a Laravel dönti el, mely parancsok esedékesek, és elindítja őket — óránkénti összefoglalók, éjszakai takarítás, heti jelentések és így tovább. Minden telepítés után futtassa a php artisan queue:restart parancsot, hogy a sorkezelői betöltsék az új kódot. Ez a szabványos Laravel felállás pontosan úgy működik, ahogy a dokumentáció leírja, platformspecifikus kerülőmegoldások nélkül.

Igen. A Redis elérhető gyorsítótárazáshoz, munkamenet-tároláshoz és sorokhoz, ez az a kombináció, amelyhez a legtöbb éles Laravel alkalmazás nyúl. Irányítsa a gyorsítótár-illesztőjét a Redisre, és a költséges lekérdezési eredmények, megjelenített részletek és számított értékek a memóriából érkeznek, ahelyett hogy minden találatnál újraépülnének. Helyezze a munkameneteket a Redisre, és a bejelentkezett állapot gyors és következetes marad a forgalom növekedésével. Állítsa a sorkapcsolatát Redisre, és a háttérfeladatok nagyon csekély többletterheléssel kerülnek sorba és dolgozódnak fel, így a sorkezelők csúcsok idején is reszponzívak maradnak. Mindezt a .env fájlban köti be a szabványos gyorsítótár-, munkamenet- és sorillesztő beállításokkal — a mi oldalunkon nincs szükség egyedi konfigurációra. Mivel a Redis ezt a munkakészletet a RAM-ban tartja, nem a lemezen, azok az oldalak, amelyek korábban nehézkesnek érződtek, érezhetően fürgébbek lesznek, a háttérfeldolgozás pedig lépést tart, ahelyett hogy torlódásba fulladna, amikor forgalmi hullám érkezik.

Igen, és ez a helyes módja egy Laravel alkalmazás kiszolgálásának. A Laravel egyetlen belépési pontot tart a public könyvtárában, az alkalmazáskódot, a .env fájlt és a tárolót pedig a webgyökér fölött, így semmi érzékeny nem érhető el a weben keresztül. A vezérlőpultból beállítja a domainje dokumentumgyökerét a projekt public mappájára, és a kérések pontosan úgy folynak át az index.php fájlon, ahogy a keretrendszer szánja. Az ingyenes, önmegújító SSL-lel kombinálva az alkalmazása HTTPS-en válaszol tiszta, szép URL-ekkel, index.php nélkül a címsorban. A storage és a bootstrap/cache könyvtárjogosultságai egyszerűen beállíthatók SSH-n, így a gyorsítótárazás, a munkamenetek és a fájlfeltöltések elsőre működnek. Ha több alkalmazást hosztol egy fiókon, minden domain saját dokumentumgyökeret kap a saját public mappájára irányítva, így a projektek tisztán elkülönülnek, miközben ugyanazon a gyors NVMe szerveren osztoznak.

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