Для небольшого проекта на Laravel необязательно сразу арендовать VPS. Современный виртуальный хостинг может подойти, если дает актуальную версию PHP, SSH, Composer, Cron, необходимые расширения и позволяет настроить корневой каталог сайта на public. Но как только приложению нужны постоянно работающие очереди, Redis, собственные серверные настройки или предсказуемые ресурсы, VPS обычно становится более подходящим вариантом.
Именно поэтому выбирать хостинг для Laravel по одной надписи поддержка PHP не стоит. Два тарифа могут одинаково запускать PHP, но на одном Laravel развернется без особых проблем, а на другом уже при первом обновлении через Composer выяснится, что SSH отсутствует, фоновые процессы запрещены или нужные параметры изменить нельзя.
Разберемся, что действительно требуется Laravel-проекту, когда достаточно обычного хостинга и в какой момент разумнее сразу выбирать VPS.
Что должен поддерживать хостинг для Laravel
Laravel написан на PHP, поэтому базовые требования похожи на требования других современных PHP-приложений. Нужна совместимая версия PHP и набор расширений, который соответствует используемой версии фреймворка и установленным пакетам.
Но этим требования Laravel не заканчиваются.
Типичный проект устанавливает зависимости через Composer. Разработчик выполняет консольные команды Artisan, запускает миграции базы данных, очищает кеш, создает символические ссылки и выполняет другие операции из командной строки.
Поэтому одним из первых параметров при выборе виртуального хостинга становится SSH.
Теоретически Laravel можно подготовить локально и загрузить на сервер уже собранный проект. На практике отсутствие нормального консольного доступа быстро превращается в неудобство. Особенно если приложение развивается и регулярно обновляется.
Второй важный момент связан со структурой каталогов.
Веб-сервер должен отдавать посетителю содержимое каталога public, а не всего проекта Laravel. Файлы конфигурации, исходный код и другие внутренние данные не должны становиться публично доступными.
Поэтому перед покупкой виртуального хостинга полезно выяснить, можно ли назначить для домена собственный корневой каталог. Если панель жестко привязывает домен к определенной папке и не позволяет нормально настроить структуру Laravel, размещение проекта усложняется.
Нужна и база данных. Для большинства проектов подойдет MySQL или MariaDB, если приложение рассчитано на эту СУБД. Если разработка использует PostgreSQL, нужно отдельно проверить его наличие. На обычном хостинге поддержка MySQL встречается намного чаще, чем возможность свободно выбирать сервер базы данных.
Еще один обязательный инструмент для многих приложений — планировщик Cron.
У Laravel есть собственный механизм планирования задач. Вместо создания множества отдельных заданий в панели сервера обычно достаточно регулярно запускать планировщик фреймворка, а уже Laravel решает, какие действия необходимо выполнить.
Поэтому важно не просто наличие красивой кнопки Cron в панели, а возможность установить нужный интервал и выполнить необходимую консольную команду.
Стоит проверить и доступные параметры PHP. Приложению могут понадобиться определенные значения memory_limit, max_execution_time, upload_max_filesize и других настроек. На VPS их можно контролировать самостоятельно, а на виртуальном хостинге часть значений задает провайдер.
Для небольшого сайта стандартных ограничений может хватать годами. Проблемы чаще появляются во время импорта данных, обработки изображений, выполнения тяжелых команд или роста самого приложения.
Поэтому хороший хостинг для Laravel — это не специальный логотип Laravel в списке поддерживаемых технологий. Важнее реальный набор возможностей.
- Совместимая версия PHP.
- Необходимые расширения PHP.
- SSH-доступ.
- Возможность использовать Composer.
- Выполнение команд Artisan.
- Cron с подходящим интервалом запуска.
- MySQL, MariaDB или другая необходимая база данных.
- Возможность выбрать каталог public корнем сайта.
- Доступ к логам.
- SSL-сертификат.
- Резервное копирование файлов и базы данных.
Если все это доступно и приложение не требует постоянно работающих процессов, виртуального хостинга действительно может оказаться достаточно.
Когда Laravel можно разместить на обычном виртуальном хостинге
Laravel часто автоматически ассоциируют с VPS. Это не совсем правильно.
Фреймворк сам по себе не требует отдельного виртуального сервера. Небольшой корпоративный сервис, личный кабинет, каталог, внутреннее приложение или другой умеренно нагруженный проект вполне способен работать на качественном виртуальном хостинге.
Главное преимущество такого варианта — не нужно самостоятельно администрировать сервер.
Провайдер занимается операционной системой, веб-сервером, основной серверной конфигурацией и инфраструктурой. Пользователь получает панель, создает домен и базу, загружает проект и занимается приложением.
Для разработчика, которому не хочется параллельно становиться системным администратором, это серьезный плюс.
Виртуальный хостинг обычно обходится проще и с точки зрения обслуживания. Не нужно следить за обновлениями операционной системы, самостоятельно настраивать веб-сервер, файрвол и множество других компонентов.
Но свобода ограничена.
Вы не можете установить любое серверное программное обеспечение. Нельзя произвольно менять системную конфигурацию. Ресурсы процессора и оперативной памяти распределяются между клиентами согласно правилам тарифа.
Именно здесь проходит настоящая граница между подходящим и неподходящим хостингом для Laravel.
Если приложение работает как обычный веб-сайт: принимает HTTP-запрос, выполняет PHP-код, обращается к базе и возвращает страницу или API-ответ, хороший shared-хостинг может справляться с ним нормально.
Если проект начинает использовать инфраструктурные возможности Laravel активнее, ограничения становятся заметнее.
Хороший пример — очереди.
Laravel позволяет отправить долгую работу в очередь, чтобы пользователь не ждал ее выполнения внутри обычного веб-запроса. Через очередь можно отправлять письма, обрабатывать изображения, импортировать данные, обращаться к внешним API и выполнять множество других задач.
Для обработки очереди нужен worker.
На собственном VPS такой процесс можно запустить постоянно и настроить его автоматический перезапуск. На виртуальном хостинге постоянно работающие пользовательские процессы могут быть запрещены или ограничены.
Иногда проблему пытаются обойти запуском обработки очереди через Cron. Для небольшого проекта это может оказаться приемлемым компромиссом, но полноценной заменой постоянно работающему worker такая схема является не всегда.
Поэтому перед оплатой тарифа лучше не спрашивать поддержку абстрактно: работает ли Laravel?
Гораздо полезнее описать конкретные требования:
- можно ли запускать Composer через SSH;
- можно ли выполнять php artisan;
- какой минимальный интервал Cron;
- разрешены ли постоянно работающие PHP-процессы;
- можно ли использовать очереди;
- есть ли Redis;
- можно ли изменить document root домена.
Ответы на эти вопросы скажут о пригодности тарифа намного больше, чем наличие Laravel в рекламном списке технологий.
Когда для Laravel лучше сразу выбрать VPS
VPS становится логичным следующим шагом не тогда, когда проект написан на Laravel, а когда приложению становится тесно в рамках виртуального хостинга.
Один из наиболее очевидных признаков — необходимость постоянно работающих процессов.
Если приложение активно использует очереди, требуется несколько workers или процессы должны автоматически перезапускаться после ошибки, собственная серверная среда дает гораздо больше возможностей для нормальной настройки.
То же относится к Laravel Horizon. Если проект использует Redis и Horizon для управления очередями, VPS обычно намного естественнее виртуального хостинга.
Redis вообще является хорошим примером различия двух моделей.
На обычном хостинге он либо предоставляется провайдером как готовая услуга, либо отсутствует. На VPS его можно установить и настроить самостоятельно, если ресурсов сервера достаточно.
Собственный сервер полезен и тогда, когда приложение состоит уже не только из PHP и базы данных.
Например, рядом с Laravel может работать отдельный сервис, поисковый движок, Node.js-процесс, WebSocket-сервер или другое программное обеспечение. Пытаться собрать такую инфраструктуру на обычном виртуальном хостинге становится бессмысленно.
Еще одна причина перехода на VPS — необходимость контролировать окружение.
Можно самостоятельно выбрать и настроить веб-сервер, PHP-FPM, базу данных, Redis, системные библиотеки и правила запуска фоновых процессов. Это дает разработчику значительно больше свободы, но одновременно добавляет ответственность.
VPS нужно обновлять и защищать. Нужно следить за свободным местом, логами, резервными копиями, состоянием сервисов и безопасностью SSH. Ошибка администратора способна привести к проблемам, которых на виртуальном хостинге вообще не пришлось бы решать самостоятельно.
Поэтому для первого небольшого Laravel-проекта VPS не является автоматическим выбором.
Если виртуальный хостинг предоставляет все необходимые функции, приложение можно начать размещать там, а на сервер перейти по мере появления реальной необходимости.
Другая ситуация возникает у коммерческого веб-приложения, которое изначально проектируется с очередями, Redis, большим количеством фоновых задач и дальнейшим ростом. Здесь попытка сэкономить на инфраструктуре может лишь добавить лишний этап миграции.
В таком случае разумнее сразу рассматривать VPS.
При выборе конфигурации не стоит пытаться найти универсальное количество процессоров и памяти именно для Laravel. Два приложения на одном фреймворке могут отличаться по нагрузке в десятки раз.
Небольшая административная система и популярный сервис с постоянными запросами используют один Laravel, но требования к серверу у них совершенно разные.
Смотреть нужно на реальную нагрузку приложения: количество запросов, работу базы, фоновые процессы, кеширование, объем данных и потребление памяти.
Для нового проекта полезна возможность увеличивать ресурсы VPS без сложного переезда. Если первоначальной конфигурации перестанет хватать, CPU, RAM или диск можно увеличить внутри инфраструктуры провайдера.
Как сравнить тарифы и выбрать хостинг для Laravel
Начать лучше не с поиска самого дешевого тарифа, а с архитектуры приложения.
Если это небольшой проект без постоянно работающих очередей и специфических серверных компонентов, сначала можно рассмотреть виртуальный хостинг с SSH, Composer и Cron. Такой вариант избавит от большей части серверного администрирования.
Если приложение использует Redis, Horizon, постоянные workers, собственные сервисы или требует изменения системной конфигурации, сравнивать стоит уже VPS.
Цена при этом не должна рассматриваться отдельно от состава тарифа.
У виртуального хостинга выясните реальные ограничения CPU, памяти и процессов. Не ограничивайтесь размером диска: для динамического приложения 50 ГБ вместо 20 ГБ могут вообще ничего не изменить, если сайт постоянно упирается в вычислительные лимиты.
Проверьте, какой тип диска используется, но не выбирайте площадку только по надписи NVMe. Производительность Laravel зависит также от процессора, базы данных, PHP, кеширования и качества самого кода.
Для VPS посмотрите количество виртуальных ядер, RAM, размер и тип диска, скорость сетевого порта, включенный трафик и наличие публичного IP. Уточните, входит ли резервное копирование в стоимость или его необходимо заказывать отдельно.
Отдельно решите вопрос администрирования.
Если разработчик умеет обслуживать Linux-сервер, обычный VPS дает максимальную свободу. Если заниматься сервером некому, дешевый неуправляемый VPS способен оказаться менее удобным решением, чем более дорогой сервер с администрированием.
Перед переносом рабочего проекта полезно развернуть его копию.
Установите зависимости через Composer, выполните миграции, проверьте загрузку файлов, отправку почты, Cron и очереди. Посмотрите логи Laravel и сервера. Запустите типичные тяжелые операции приложения.
Такой тест намного полезнее обещания провайдера о полной поддержке Laravel.
Особенно внимательно проверьте резервное копирование. Для Laravel-проекта недостаточно сохранить только исходный код, тем более если он уже находится в Git. Самые ценные изменяемые данные обычно находятся в базе и пользовательских файлах.
Нужно понимать, как часто создаются копии, где они хранятся и насколько быстро можно восстановить приложение после ошибки.
В итоге выбор между виртуальным хостингом и VPS для Laravel довольно прост.
Если приложению нужны PHP, база данных, Composer, SSH и периодический Cron, а нагрузка невелика, качественного виртуального хостинга может быть вполне достаточно.
Если нужны постоянные очереди, Redis, Horizon, дополнительные сервисы, собственная конфигурация сервера или гарантированно доступные ресурсы, лучше смотреть в сторону VPS.
Не стоит переплачивать за сервер только ради названия фреймворка. Но и пытаться втиснуть серьезное Laravel-приложение в самый дешевый shared-тариф тоже невыгодно. Хороший хостинг для Laravel — тот, который соответствует архитектуре проекта сегодня и позволяет без болезненного переезда получить больше ресурсов завтра.
