Хостинг Laravel, створений під те, як ви викочуєте код

Так. Кожен тариф має повну оболонку SSH, тож розгортання — це той самий процес на базі Git, яким ви вже користуєтеся локально. Клонуйте репозиторій прямо з GitHub, GitLab чи Bitbucket у свій акаунт, виконайте composer install, щоб підтягнути пакети vendor, а потім перенесіть у .env свої продакшн-значення. Далі естафету бере Artisan: php artisan key:generate задає ключ застосунку, а php artisan migrate будує схему бази даних. Викотити наступний реліз так само швидко: git pull, щоб узяти нові коміти, composer install, щоб оновити залежності, php artisan migrate для нових міграцій і оновлення кешу, щоб позбутися старої конфігурації. Оскільки у вас справжня оболонка, а не замкнена панель, ви можете читати логи, виправляти права на storage і перезапустити будь-яку команду, якщо щось потребує другого погляду. Спрямуйте кореневий каталог сайту на теку public — і сайт живий по HTTPS.

Так — Composer встановлений у кожному акаунті й уже в вашому PATH, тож перед першим деплоєм нічого не треба завантажувати, розпаковувати чи налаштовувати. Відкрийте сесію SSH тієї ж миті, коли акаунт готовий, — і composer install, composer update, composer require й composer dump-autoload одразу працюють із правильним бінарником PHP. Для Laravel це важливо, бо і сам фреймворк, і майже кожен пакет, який ви додаєте — від стартових наборів до Sanctum, Horizon і решти, — підтягуються через Composer, а не комітяться в репозиторій. Ви тримаєте власні composer.json і composer.lock, тож версії, які ви тестуєте локально, — це саме ті версії, що потрапляють на сервер. Якщо колись знадобиться запустити Composer під конкретним релізом PHP, ви це зможете, адже версія PHP обирається для кожного сайту. Коротко: ваш процес роботи із залежностями поводиться точно так, як на вашій власній машині.

Ви отримуєте сучасний PHP 8.x і самі обираєте в панелі керування, який реліз працює на кожному сайті. Ця гнучкість важлива, бо кожна версія Laravel заявляє мінімальну вимогу до PHP: свіжі релізи очікують PHP 8.1 чи новіший, а старіший застосунок із довготривалою підтримкою може бути прив'язаний до ранішої збірки 8.x. Замість того щоб нав'язувати одне середовище виконання всьому, ви задаєте версію для кожного домену, тож успадкований клієнтський проєкт і зовсім новий застосунок живуть в одному акаунті без конфліктів. Поруч із селектором ви налаштовуєте параметри, які важать для Laravel: memory_limit для важчих команд Artisan та імпортів, max_execution_time для довгих завдань і OPcache, щоб скомпільований код лишався гарячим у пам'яті. Перемикання версій миттєве й оборотне, тож перевірка оновлення PHP малоризикована — спершу підніміть тестовий домен, переконайтеся, що тести проходять, і переведіть продакшн одним кліком.

Обидва тут почуваються повноцінно. Для роботи з чергами запустіть постійний воркер командою php artisan queue:work, щоб завдання, сповіщення, листи й важкі експорти виконувалися поза вебзапитом, а не блокували завантаження сторінки для відвідувача. Підкріпіть чергу Redis — і завдання підхоплюються й розгрібаються швидко навіть під реальним трафіком. Для запланованої роботи не потрібно додавати довгий перелік окремих рядків cron. Натомість ви реєструєте все в планувальнику Laravel у коді застосунку, а потім додаєте один запис cron, що щохвилини виконує php artisan schedule:run. З цього єдиного завдання Laravel сам вирішує, які команди настали, і запускає їх — щогодинні дайджести, нічні чистки, тижневі звіти тощо. Після кожного деплою виконуйте php artisan queue:restart, щоб воркери підхопили новий код. Це стандартна схема Laravel, що працює точно так, як описано в документації, без жодних платформних милиць.

Так. Redis доступний для кешування, зберігання сесій і черг — саме та комбінація, до якої тягнеться більшість продакшн-застосунків на Laravel. Спрямуйте драйвер кешу на Redis — і дорогі результати запитів, готові фрагменти й обчислені значення віддаватимуться з пам'яті замість того, щоб збиратися заново на кожен запит. Перенесіть сесії на Redis — і стан авторизованих користувачів лишиться швидким і послідовним у міру зростання трафіку. Задайте Redis як з'єднання для черг — і фонові завдання ставитимуться й оброблятимуться з дуже малими накладними витратами, тож воркери лишатимуться чуйними під час сплесків. Усе це ви налаштовуєте у своєму .env стандартними параметрами драйверів кешу, сесій і черг — жодної особливої конфігурації з нашого боку не потрібно. Оскільки Redis тримає цей робочий набір в RAM, а не на диску, сторінки, які раніше здавалися важкими, помітно жвавішають, а фонова обробка встигає, замість того щоб накопичувати завал під час напливу трафіку.

Так, і це правильний спосіб обслуговувати застосунок Laravel. Laravel тримає єдину точку входу в теці public, а код застосунку, .env і storage — вище кореня сайту, тож нічого чутливого недосяжне з вебу. У панелі керування ви задаєте кореневим каталогом свого домену теку public вашого проєкту, і запити йдуть через index.php саме так, як задумав фреймворк. У поєднанні з безкоштовним SSL з автопродовженням ваш застосунок відповідає по HTTPS із чистими, охайними URL-адресами й без index.php в адресному рядку. Права на storage і bootstrap/cache легко виставити через SSH, тож кешування, сесії й завантаження файлів працюють із першого разу. Якщо ви розміщуєте кілька застосунків в одному акаунті, кожен домен отримує власний кореневий каталог, спрямований на свою теку public, тож проєкти лишаються охайно розділеними, попри спільний швидкий сервер NVMe під ними.

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