Hosting Laravel zbudowany pod to, jak wdrażasz

Tak. Każdy pakiet zawiera pełną powłokę SSH, więc wdrażanie to ten sam oparty na Gicie sposób pracy, którego już używasz lokalnie. Sklonuj repozytorium prosto z GitHuba, GitLaba albo Bitbucketa na swoje konto, uruchom composer install, by pobrać pakiety vendor, a potem skopiuj wartości produkcyjne do pliku .env. Dalej przejmuje Artisan: php artisan key:generate ustawia klucz aplikacji, a php artisan migrate buduje schemat bazy. Wypuszczenie kolejnego wydania jest równie szybkie — git pull po nowe commity, composer install dla aktualizacji zależności, php artisan migrate dla nowych migracji i odświeżenie cache, by wyczyścić starą konfigurację. Ponieważ masz prawdziwą powłokę, a nie zamknięty panel, możesz śledzić logi, poprawić uprawnienia katalogu storage i powtórzyć dowolne polecenie, gdy coś wymaga drugiego spojrzenia. Skieruj katalog główny domeny na folder public i strona działa po HTTPS.

Tak — Composer jest zainstalowany na każdym koncie i już w Twoim PATH, więc przed pierwszym wdrożeniem nie musisz niczego pobierać, rozpakowywać ani konfigurować. Otwórz sesję SSH w chwili, gdy konto zostanie uruchomione, a composer install, composer update, composer require i composer dump-autoload od razu działają na właściwym pliku binarnym PHP. Ma to znaczenie w Laravel, bo framework i niemal każdy dodawany pakiet — od zestawów startowych po Sanctum, Horizon i resztę — są pobierane przez Composera, a nie zatwierdzane w repozytorium. Trzymasz własne composer.json i composer.lock, więc wersje testowane lokalnie to te same wersje, które lądują na serwerze. Gdybyś kiedyś potrzebował uruchomić Composera pod konkretnym wydaniem PHP, możesz — wersję PHP wybiera się osobno dla każdej strony. Krótko mówiąc, praca z zależnościami zachowuje się dokładnie tak jak na Twoim komputerze.

Dostajesz nowoczesne PHP 8.x i sam wybierasz, które wydanie obsługuje każdą stronę, z poziomu panelu sterowania. Ta elastyczność ma znaczenie, bo każda wersja Laravel określa minimalne wymaganie PHP — nowsze wydania oczekują PHP 8.1 lub wyżej, a starsza aplikacja objęta długim wsparciem bywa przypięta do wcześniejszej wersji 8.x. Zamiast narzucać jedno środowisko wszystkim, ustawiasz wersję osobno dla każdej domeny, więc wysłużony projekt klienta i zupełnie nowa aplikacja mogą mieszkać na tym samym koncie bez konfliktu. Obok selektora dostroisz ustawienia, na których zależy Laravel: memory_limit dla cięższych poleceń Artisana i importów, max_execution_time dla długo działających zadań oraz OPcache, by skompilowany kod pozostawał gorący w pamięci. Zmiana wersji jest natychmiastowa i odwracalna, co czyni testowanie aktualizacji PHP niskiego ryzyka — najpierw podnieś domenę testową, potwierdź, że testy przechodzą, a potem przenieś produkcję jednym kliknięciem.

Jedno i drugie jest tu obywatelem pierwszej kategorii. Do pracy kolejkowej uruchom trwały worker poleceniem php artisan queue:work, by zadania, powiadomienia, wiadomości i ciężkie eksporty odbywały się poza żądaniem WWW, zamiast blokować ładowanie strony odwiedzającemu. Oprzyj kolejkę na Redisie, a zadania będą podejmowane i rozładowywane szybko nawet przy realnym ruchu. Do pracy zaplanowanej nie dodajesz długiej listy osobnych linii crona. Zamiast tego rejestrujesz wszystko w harmonogramie Laravel w kodzie aplikacji, a potem dodajesz jeden wpis cron uruchamiający php artisan schedule:run co minutę. Z tego jednego zadania Laravel decyduje, które polecenia są należne, i je odpala — godzinne podsumowania, nocne porządki, tygodniowe raporty i tak dalej. Po każdym wdrożeniu uruchom php artisan queue:restart, by workery podniosły nowy kod. To standardowa konfiguracja Laravel działająca dokładnie tak, jak opisuje dokumentacja, bez obejść specyficznych dla platformy.

Tak. Redis jest dostępny do cache, przechowywania sesji i kolejek, a to zestaw, po który sięga większość produkcyjnych aplikacji Laravel. Skieruj sterownik cache na Redisa, a kosztowne wyniki zapytań, wyrenderowane fragmenty i wyliczone wartości będą serwowane z pamięci, zamiast być budowane od nowa przy każdym trafieniu. Przenieś sesje na Redisa, a stan zalogowania pozostanie szybki i spójny w miarę wzrostu ruchu. Ustaw połączenie kolejki na Redisa, a zadania w tle będą kolejkowane i przetwarzane z bardzo małym narzutem, więc workery pozostaną responsywne w szczytach. Wszystko to podpinasz w swoim pliku .env standardowymi ustawieniami sterowników cache, sesji i kolejki — po naszej stronie nie trzeba żadnej specjalnej konfiguracji. Ponieważ Redis trzyma ten roboczy zestaw w pamięci RAM, a nie na dysku, strony, które wydawały się ciężkie, wyraźnie żwawieją, a przetwarzanie w tle nadąża, zamiast piętrzyć się w zaległościach przy nagłym napływie ruchu.

Tak, i to właściwy sposób serwowania aplikacji Laravel. Laravel trzyma jeden punkt wejścia w katalogu public, a kod aplikacji, plik .env i katalog storage znajdują się ponad katalogiem głównym serwera, więc nic wrażliwego nie jest osiągalne przez internet. W panelu sterowania ustawiasz katalog główny swojej domeny na folder public projektu, a żądania płyną przez index.php dokładnie tak, jak zamierza framework. W połączeniu z darmowym, samoodnawiającym się SSL Twoja aplikacja odpowiada po HTTPS z czystymi, przyjaznymi adresami i bez index.php w pasku adresu. Uprawnienia katalogów storage i bootstrap/cache ustawia się prosto po SSH, więc cache, sesje i przesyłanie plików działają za pierwszym razem. Jeśli hostujesz kilka aplikacji na jednym koncie, każda domena dostaje własny katalog główny wskazujący jej własny folder public, więc projekty pozostają czysto oddzielone, choć dzielą ten sam szybki serwer NVMe pod spodem.

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