Găzduire Laravel construită pentru felul în care livrați

Da. Fiecare plan vine cu un shell SSH complet, deci implementarea înseamnă același flux bazat pe Git pe care îl folosiți deja local. Clonați-vă depozitul direct din GitHub, GitLab sau Bitbucket în contul dumneavoastră, rulați composer install ca să aduceți pachetele din vendor, apoi copiați valorile de producție în fișierul .env. De acolo preia Artisan: php artisan key:generate vă setează cheia aplicației, iar php artisan migrate vă construiește schema bazei de date. Livrarea unei versiuni ulterioare este la fel de rapidă — git pull ca să luați noile modificări, composer install ca să actualizați dependențele, php artisan migrate pentru eventualele migrări noi și o împrospătare a cache-ului ca să eliminați configurația veche. Pentru că aveți un shell adevărat, nu un panou blocat, puteți urmări jurnalele, corecta permisiunile pe directorul storage și rula din nou orice comandă dacă ceva are nevoie de o a doua privire. Îndreptați directorul rădăcină către dosarul public și site-ul este activ prin HTTPS.

Da — Composer este instalat în fiecare cont și se află deja în PATH, deci nu aveți nimic de descărcat, de dezarhivat sau de configurat înainte de prima implementare. Deschideți o sesiune SSH în clipa în care contul este provizionat și composer install, composer update, composer require și composer dump-autoload funcționează imediat cu binarul PHP corect. Asta contează pentru Laravel, pentru că framework-ul și aproape fiecare pachet pe care îl adăugați — de la kiturile de pornire până la Sanctum, Horizon și restul — sunt aduse prin Composer, nu incluse în depozitul dumneavoastră. Vă păstrați propriile fișiere composer.json și composer.lock, deci versiunile testate local sunt versiunile care ajung pe server. Dacă vreodată trebuie să rulați Composer cu o anumită versiune de PHP, puteți, pentru că versiunea de PHP este selectabilă per site. Pe scurt, fluxul dumneavoastră de dependențe se comportă exact ca pe propria mașină.

Primiți PHP 8.x modern și alegeți din panoul de control ce versiune rulează fiecare site. Această flexibilitate contează, pentru că fiecare versiune de Laravel declară o cerință minimă de PHP — versiunile recente așteaptă PHP 8.1 sau mai nou, în timp ce o aplicație mai veche, cu suport pe termen lung, poate fi fixată pe o versiune 8.x anterioară. În loc să impunem un singur mediu de execuție pentru tot, setați versiunea per domeniu, deci un proiect vechi de client și o aplicație nou-nouță pot sta în același cont fără conflict. Pe lângă selector, puteți regla setările care contează pentru Laravel: memory_limit pentru comenzi Artisan și importuri mai grele, max_execution_time pentru sarcini de durată și OPcache, ca să vă țină codul compilat cald în memorie. Schimbarea versiunilor este instantanee și reversibilă, ceea ce face testarea unui upgrade de PHP să aibă risc mic — urcați întâi un domeniu de test, confirmați că trec testele, apoi mutați producția dintr-un singur clic.

Amândouă sunt tratate ca cetățeni de rangul întâi aici. Pentru munca din coadă, porniți un proces persistent cu php artisan queue:work, ca sarcinile, notificările, e-mailurile și exporturile mari să ruleze în afara cererii web, în loc să blocheze încărcarea paginii unui vizitator. Susțineți coada cu Redis, iar sarcinile sunt preluate și golite rapid, chiar și sub trafic real. Pentru munca programată, nu adăugați o listă lungă de linii cron separate. În schimb, înregistrați totul în planificatorul Laravel, în codul aplicației, apoi adăugați o singură intrare cron care rulează php artisan schedule:run în fiecare minut. Din acea unică sarcină, Laravel decide ce comenzi sunt scadente și le declanșează — rezumate orare, curățenii de noapte, rapoarte săptămânale și așa mai departe. După fiecare implementare, rulați php artisan queue:restart, ca procesele dumneavoastră să încarce noul cod. Este configurația standard Laravel, funcționând exact așa cum descrie documentația, fără soluții de ocolire specifice platformei.

Da. Redis este disponibil pentru cache, stocarea sesiunilor și cozi, adică exact combinația la care apelează majoritatea aplicațiilor Laravel de producție. Îndreptați driverul de cache către Redis, iar rezultatele scumpe de interogare, fragmentele randate și valorile calculate sunt servite din memorie, în loc să fie reconstruite la fiecare accesare. Mutați sesiunile pe Redis, iar starea utilizatorilor autentificați rămâne rapidă și consecventă pe măsură ce crește traficul. Setați conexiunea de coadă pe Redis, iar sarcinile de fundal sunt puse în coadă și procesate cu foarte puține costuri suplimentare, deci procesele rămân prompte în timpul vârfurilor. Configurați toate acestea în fișierul .env, cu setările standard pentru driverele de cache, sesiune și coadă — nu este nevoie de nicio configurație specială din partea noastră. Pentru că Redis ține acest set de date de lucru în memoria RAM, nu pe disc, paginile care păreau greoaie devin vizibil mai alerte, iar procesarea de fundal ține pasul, în loc să se adune într-un morman de restanțe când sosește o rafală de trafic.

Da, și este modul corect de a servi o aplicație Laravel. Laravel păstrează un singur punct de intrare în directorul său public și ține codul aplicației, fișierul .env și directorul storage deasupra rădăcinii web, deci nimic sensibil nu este accesibil prin internet. Din panoul de control setați directorul rădăcină al domeniului către dosarul public al proiectului, iar cererile trec prin index.php exact așa cum intenționează framework-ul. Combinat cu SSL gratuit și reînnoire automată, aplicația dumneavoastră răspunde prin HTTPS, cu adrese curate și fără index.php în bara de adrese. Permisiunile de director pe storage și bootstrap/cache se setează simplu prin SSH, deci cache-ul, sesiunile și încărcările de fișiere funcționează din prima. Dacă găzduiți mai multe aplicații într-un singur cont, fiecare domeniu primește propriul director rădăcină, îndreptat către propriul dosar public, ceea ce păstrează proiectele separate curat, deși împart același server NVMe rapid de dedesubt.

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