- Опубликовано: 28 июл 2026
- 28
Современный PHP-хостинг: зачем Laravel и Symfony нужны SSH, Composer, Node.js, cron и отдельная public-директория
Часть 8 из 14 · Серия «Хостинг без магии»
Проект прекрасно работает на компьютере разработчика. Laravel показывает главную страницу, Symfony подключается к базе, административная панель открывается, CSS и JavaScript собраны. Остаётся самая простая часть — загрузить сайт на хостинг.
Файлы отправляются по FTP в public_html, домен подключается — и вместо сайта появляется ошибка 500. Или открывается список каталогов. Или главная страница работает, а остальные адреса возвращают 404. После нескольких перестановок файлов сайт наконец запускается, но без стилей. Затем выясняется, что не отправляются письма, не выполняются задания по расписанию, а после установки нового пакета проект снова перестаёт открываться.
Обычно в этот момент звучит вывод: «Laravel нельзя разместить на виртуальном хостинге, ему обязательно нужен VPS».
Это не совсем так.
Современному PHP-фреймворку действительно недостаточно тарифа, на котором можно только загрузить файлы через FTP и создать базу MySQL. Но полноценный VPS ему тоже нужен далеко не всегда. Между этими крайностями существует виртуальный хостинг с SSH, Composer, Node.js, cron, выбором версии PHP и возможностью назначить отдельную публичную директорию.
Разберёмся, какие именно возможности нужны Laravel, Symfony, Yii, CakePHP, Drupal и другим современным PHP-проектам — и какие вопросы следует задать хостеру до оплаты тарифа.
Современный PHP-сайт — это уже не папка с index.php
Классический PHP-сайт можно было представить так:
public_html/
├── index.php
├── catalog.php
├── contacts.php
├── images/
└── css/
Загрузили папку на сервер, прописали доступ к базе — сайт работает.
Современное приложение устроено иначе:
project/
├── app/ # код приложения
├── config/ # конфигурация
├── database/ # миграции и структура базы
├── resources/ # исходники шаблонов, CSS и JavaScript
├── routes/ # маршруты
├── storage/ # логи, кэш и загруженные файлы
├── vendor/ # PHP-зависимости Composer
├── node_modules/ # зависимости frontend-сборки
├── public/ # единственная публичная директория
│ ├── index.php
│ └── build/
├── .env # пароли и настройки окружения
├── composer.json
├── composer.lock
└── package.json
Посетителю сайта нужна только папка public. Всё остальное — исходный код, настройки, логи, служебные команды и пароли — должно оставаться за пределами доступной из интернета директории.
Symfony прямо рекомендует использовать public/ как корневой каталог веб-сервера. Laravel также отделяет публичные файлы от кода приложения и хранит доступные посетителям ресурсы внутри public.
Поэтому вопрос «поддерживает ли хостинг PHP?» почти ничего не говорит о возможности разместить современный проект. Правильный вопрос звучит так:
Можно ли на этом хостинге воспроизвести структуру и рабочие процессы, для которых создавался проект?
Для ответа придётся проверить несколько отдельных возможностей.
Требование №1. Публичная директория должна указывать на public
Представим, что проект находится здесь:
/home/user/www/example.com/project/
Корень сайта, который обслуживает домен example.com, должен указывать сюда:
/home/user/www/example.com/project/public/
Не на весь project, не на домашний каталог пользователя и не обязательно на стандартный public_html.
Это называется Document Root, web-root или корневая директория сайта.
Правильная схема выглядит так:
Интернет
│
▼
example.com
│
▼
project/public/index.php
Недоступны из интернета:
project/.env
project/config/
project/storage/
project/vendor/
project/composer.json
Если панель хостинга позволяет изменить корневую директорию домена, задача решается за минуту: выбираем project/public и больше ничего не переносим.
Если изменить Document Root нельзя, начинаются компромиссы:
- содержимое
publicкопируют вpublic_html; - исправляют пути в
index.php; - приложение оставляют уровнем выше;
- создают символическую ссылку из
public_htmlнаproject/public; - переименовывают или перестраивают каталоги проекта.
Некоторые из этих решений работают, но усложняют обновления и увеличивают вероятность ошибки. Symfony, например, отдельно описывает варианты размещения на shared-хостинге через переименование публичного каталога или символическую ссылку на него.
Лучший вариант — когда структура проекта остаётся стандартной, а панель хостинга умеет назначать public корнем конкретного домена или поддомена.
Как это устроено на Siteko. Панель хостинга позволяет назначить корневой папкой сайта произвольную подпапку проекта —
publicу Laravel и Symfony,webу Yii или любую другую. Код,.envиvendorостаются выше корня и недоступны из браузера. А если при заказе включить опцию «Подготовить окружение под фреймворк», корень сайта сразу будет указывать наpublic.
Почему нельзя просто положить весь проект в public_html
Потому что вместе с сайтом можно случайно открыть доступ к тому, что посетители видеть не должны:
- файлу
.envс паролем от базы; - репозиторию
.git; - логам приложения;
- резервным копиям;
- исходникам и конфигурации;
- служебным JSON- и YAML-файлам;
- временным экспортам базы данных.
Веб-сервер может запретить доступ к части таких файлов правилами конфигурации. Но безопасная архитектура лучше длинного списка запретов: интернет изначально видит только public, а не весь проект.
Требование №2. SSH — это рабочий инструмент, а не доступ администратора
Название SSH часто пугает владельцев сайтов. Кажется, что это какая-то функция для системных администраторов, после включения которой придётся настраивать Linux и вручную перезапускать сервер.
На виртуальном хостинге SSH обычно работает иначе. Пользователь получает ограниченный доступ только к своему аккаунту и своим файлам. Он не управляет сервером целиком, не меняет настройки других клиентов и не устанавливает системные пакеты.
SSH нужен для обычной работы с проектом:
cd ~/www/example.com/project
php -v
composer install
php artisan migrate
php artisan cache:clear
npm run build
Без SSH разработчику приходится выполнять команды на своём компьютере, а затем загружать на хостинг готовые каталоги. Иногда это допустимо, но быстро приводит к проблемам:
- каталог
vendorсодержит тысячи файлов и долго передаётся по FTP; - часть файлов может не загрузиться;
- зависимости могут быть собраны под другую версию PHP;
- невозможно удобно запускать миграции;
- нельзя проверить серверное окружение;
- очистка кэша превращается в удаление файлов через файловый менеджер;
- диагностика ошибок ограничивается тем, что показывает браузер.
SSH не делает виртуальный хостинг VPS. Он просто даёт проекту нормальную консоль.
Как это устроено на Siteko. Полноценный shell — не только файловый менеджер — доступен на тарифах Master и Expert: именно они рассчитаны на проекты с Composer и консольными командами. Start и Optima — тарифы для сайтов на CMS, консоли там нет.
Что проверить в SSH-доступе
Сам факт наличия SSH ещё не гарантирует, что через него можно развернуть приложение. После подключения должны выполняться хотя бы такие команды:
php -v
php -m
composer --version
node --version
npm --version
git --version
Также полезно проверить:
php -r "echo PHP_VERSION, PHP_EOL;"
composer check-platform-reqs
Последняя команда сравнивает требования установленных PHP-пакетов с реальной версией PHP и доступными расширениями.
Требование №3. Composer должен работать непосредственно на хостинге
Composer для современного PHP-проекта играет ту же роль, что магазин приложений для телефона: он скачивает нужные библиотеки, проверяет совместимость версий и собирает автозагрузчик классов.
Список зависимостей хранится в двух файлах:
composer.json
composer.lock
composer.json описывает допустимые версии пакетов, а composer.lock фиксирует конкретный набор, который уже был проверен разработчиком.
На боевом сервере обычно выполняют:
composer install \
--no-dev \
--prefer-dist \
--optimize-autoloader \
--no-interaction
Здесь важны два слова: composer install, а не composer update.
install читает composer.lock и устанавливает заранее зафиксированные версии. update подбирает новые версии пакетов и перезаписывает lock-файл. Делать это прямо на боевом сайте — всё равно что менять детали двигателя во время поездки.
Флаг --no-dev исключает зависимости, предназначенные для разработки и тестирования, а --optimize-autoloader оптимизирует автозагрузчик для production-окружения. Оба режима предусмотрены официальной документацией Composer.
Почему встроенной кнопки «Установить Laravel» недостаточно
Автоустановщик полезен для нового типового проекта. Но он не решает задачу размещения существующего приложения, потому что у проекта могут быть:
- собственные Composer-пакеты;
- конкретный
composer.lock; - миграции базы данных;
- дополнительные PHP-расширения;
- приватные репозитории;
- нестандартная структура;
- frontend-сборка;
- команды после установки.
Поэтому важнее не наличие логотипа Laravel в панели, а возможность самостоятельно выполнить Composer-команды в каталоге сайта.
Как это устроено на Siteko. Composer установлен глобально и доступен сразу после входа по SSH:
composer installработает без установки и без указания путей к PHP. Отдельно скачиватьcomposer.pharили подбирать обёртки не нужно.
Требование №4. Версия PHP в консоли и на сайте должна совпадать
Панель показывает, что для домена выбрана PHP 8.x. Разработчик подключается по SSH, запускает:
php -v
и получает другую версию.
Это одна из самых неприятных особенностей некоторых хостингов: сайт обслуживает один PHP, а консольная команда php запускает другой.
В результате Composer может отказаться устанавливать зависимости, хотя сайт теоретически поддерживает нужную версию. Или наоборот: зависимости успешно установятся через современный CLI, а веб-сайт откроется через старый обработчик и завершится фатальной ошибкой.
Проверять нужно обе среды.
Версию в консоли показывает:
php -v
Версию веб-обработчика можно временно проверить отдельным файлом:
<?php
echo PHP_VERSION;
После проверки файл следует удалить.
На хорошем хостинге версия PHP выбирается отдельно для каждого сайта, а в документации указано, как запустить ту же версию через SSH. Например:
php8.4 artisan migrate
php8.4 /usr/local/bin/composer install
Конкретный путь зависит от панели, но принцип один: Composer, консольные команды и запросы посетителей должны работать в совместимом окружении.
Как это устроено на Siteko. Версия PHP выбирается в панели отдельно для каждого сайта — доступны версии от 5.2 до 8.5. При этом версия в консоли и в cron совпадает с версией сайта, поэтому трюки вроде
php8.4 artisan migrateне нужны: обычныйphp— это тот же PHP, что обслуживает сайт.
Важна не только версия, но и расширения
Проекту могут понадобиться:
- PDO-драйвер нужной базы данных;
mbstring;intl;curl;openssl;fileinfo;zip;gdили Imagick;bcmath;redis— если кэш или сессии проекта настроены на Redis;- другие расширения, указанные пакетами проекта.
Универсального списка для всех PHP-фреймворков нет. Проверять требования лучше не по случайной статье из интернета, а по composer.json конкретного проекта:
composer check-platform-reqs
Если расширения нет и пользователь не может подключить его в панели, это ограничение хостинга, которое не исправляется переносом файлов или правами доступа.
И одна ловушка, о которой стоит знать заранее: наличие PHP-расширения redis ещё не означает, что на хостинге есть сам Redis-сервер. Расширение — это клиент; серверу нужно где-то работать. На виртуальном хостинге общий Redis-сервер обычно не предоставляется — вернёмся к этому в разделе про очереди.
Как это устроено на Siteko. Стандартный набор для фреймворков включён:
mbstring,intl,curl,openssl,fileinfo,zip,gd, Imagick,bcmath,sodium,pdo_mysql,pdo_pgsql,pdo_sqlite, OPcache и другие. Если проекту нужно что-то ещё — можно написать в поддержку. Расширениеredisтоже установлено, но Redis-сервера на виртуальном хостинге нет: для кэша и сессий используются драйверыfileиdatabase, а проектам, которым нужен именно Redis, подойдёт VDS.
Требование №5. Node.js нужен не PHP, а сборке интерфейса
Laravel и Symfony работают на PHP. Зачем тогда хостингу Node.js?
Потому что современные проекты обычно хранят CSS и JavaScript не в том виде, в котором они отправляются браузеру. Перед публикацией исходники проходят сборку:
- объединяются модули;
- обрабатываются стили;
- уменьшается размер файлов;
- добавляются версии к именам;
- компилируется TypeScript;
- собираются Vue-, React- или другие компоненты.
Laravel обычно использует Vite для сборки production-ресурсов. Официальная документация Laravel прямо описывает Vite как инструмент, который превращает CSS и JavaScript проекта в готовые для production файлы.
Типовой процесс выглядит так:
npm ci
npm run build
npm устанавливает зависимости, перечисленные в package.json, а затем запускает определённую проектом команду сборки. Node.js используется здесь как среда выполнения инструментов frontend-разработки.
После сборки в Laravel обычно появляется каталог:
public/build/
Именно его уже отдаёт веб-сервер посетителям. Сам Node.js при этом не обязан постоянно работать.
Когда Node.js на хостинге не нужен
Собирать frontend можно:
- на компьютере разработчика;
- в GitHub Actions или GitLab CI;
- на отдельном build-сервере;
- внутри системы автоматического деплоя.
После этого на хостинг загружаются только готовые файлы из public/build.
Поэтому Node.js на виртуальном хостинге — полезная, но не всегда обязательная функция. Она особенно важна, когда владелец хочет выполнять весь деплой непосредственно на хостинге.
Что следует проверить
Нужен не просто пункт «Node.js поддерживается», а ответы на конкретные вопросы:
- можно ли запускать
nodeиnpmчерез SSH; - доступна ли подходящая проекту версия Node.js;
- разрешена ли установка зависимостей;
- хватит ли памяти на
npm ciиnpm run build; - может ли сборка выполняться дольше стандартного лимита;
- разрешено ли создание большого количества файлов в
node_modules.
Frontend-сборка иногда потребляет больше памяти, чем само PHP-приложение. На небольшом тарифе сайт может прекрасно работать, но npm run build будет завершаться принудительно из-за лимита памяти. В таком случае сборку лучше вынести в CI, а не покупать VPS только ради одной команды.
Как это устроено на Siteko. Node.js ставится через nvm — менеджер версий, который позволяет выбрать под проект любую актуальную версию, а не одну «версию хостинга». npm идёт в комплекте, yarn и pnpm включаются командой
corepack enable. Памяти тарифов Master и Expert — 1 ГБ на процессы аккаунта — хватает на сборку Vite и Webpack. А если проекту нужен постоянно работающий Node-процесс (SSR, WebSocket-сервер) — это уже сценарий для VDS.
Требование №6. Cron нужен даже сайту, который «ничего не делает по расписанию»
У интернет-магазина регулярно возникают задачи, которые не должны запускаться посетителем:
- отправка уведомлений;
- очистка временных данных;
- обновление цен;
- обработка импорта;
- формирование отчётов;
- публикация отложенных материалов;
- повтор неудачных заданий;
- проверка статусов оплат;
- создание резервных экспортов.
Laravel объединяет такие задания в собственном планировщике. На сервере достаточно одной cron-записи, которая каждую минуту запускает scheduler приложения.
Типовая команда:
* * * * * cd /home/user/www/example.com/project && php artisan schedule:run >> /dev/null 2>&1
У Symfony, Yii, Drupal и других систем команды будут отличаться, но требование остаётся тем же: хостинг должен позволять запускать PHP CLI по расписанию.
Какие ограничения cron имеют значение
В панели может быть раздел «Планировщик», но это ещё не означает, что он подходит проекту.
Нужно проверить:
- можно ли запускать задание каждую минуту;
- разрешены ли команды с аргументами;
- можно ли выбрать нужную версию PHP;
- доступен ли рабочий каталог проекта;
- куда отправляется вывод и ошибки;
- сколько времени может работать процесс;
- блокирует ли хостинг одновременный запуск одинаковых заданий.
Особенно важен минимальный интервал. Если панель разрешает запуск только раз в 15 минут, часть функций приложения будет работать с заметной задержкой.
Как это устроено на Siteko. Планировщик в панели запускает задания с интервалом от одной минуты, команды с аргументами разрешены, а
phpв cron — та же версия, что у сайта. Стандартная строкаschedule:runдля Laravel работает без переделок.
Требование №7. Очереди — это не то же самое, что cron
Планировщик отвечает на вопрос «когда запустить задачу».
Очередь отвечает на другой вопрос: «что выполнить вне запроса пользователя».
Представим оформление заказа. После нажатия кнопки приложение должно:
- записать заказ;
- отправить письмо;
- уведомить менеджера;
- передать данные в CRM;
- создать документы;
- обновить остатки.
Если сделать всё внутри одного HTTP-запроса, покупатель будет ждать завершения всех операций. Очередь позволяет сразу показать страницу успешного заказа, а тяжёлые действия выполнить отдельно.
Для обработки очереди обычно нужен постоянно работающий PHP-процесс:
php artisan queue:work
И вот здесь проходит одна из главных границ между обычным виртуальным хостингом и VPS.
Три варианта поддержки очередей
Вариант 1. Хостинг умеет управлять фоновыми процессами.
В панели создаётся worker, который автоматически перезапускается после завершения или ошибки. Это лучший вариант.
Вариант 2. Очередь периодически обрабатывается через cron.
Например:
* * * * * cd /home/user/www/example.com/project && flock -n /tmp/example-queue.lock php artisan queue:work --stop-when-empty --max-time=50 >> /dev/null 2>&1
Раз в минуту запускается worker, обрабатывает накопившиеся задания и завершается. flock не позволяет создать второй процесс, если предыдущий ещё работает.
Для небольшого сайта этого часто достаточно. Но обработка начинается не мгновенно, а длительные задачи могут упереться в лимиты тарифа.
Вариант 3. Очередь выполняется синхронно.
Задачи запускаются прямо внутри пользовательского запроса. Проект работает, но теряет часть преимуществ очередей: посетители дольше ждут, а тяжёлые операции чаще завершаются по таймауту.
Если приложение активно использует очереди, WebSocket-соединения, Laravel Horizon или другие постоянно работающие службы, наличие SSH само по себе проблему не решит. Нужна поддержка долгоживущих процессов либо VPS.
Как это устроено на Siteko. Честный ответ: на виртуальном хостинге работает второй вариант. Cron раз в минуту запускает
php artisan queue:work --stop-when-empty, задания обрабатываются с задержкой порядка минуты — для писем, уведомлений и типовых фоновых задач этого достаточно. Постоянные worker-процессы, Supervisor и Laravel Horizon на общем сервере мы сознательно не обещаем: долгоживущие процессы упираются в лимиты, и для них нужен VDS. При заказе с опцией «окружение под фреймворк» cron-строки для планировщика и очереди добавляются автоматически.
Требование №8. Проекту нужны права на запись — но не на всё подряд
Современное PHP-приложение не должно иметь возможность бесконтрольно изменять весь собственный код.
Обычно веб-процессу требуются права только на определённые каталоги.
Для Laravel это прежде всего:
storage/
bootstrap/cache/
Laravel официально указывает, что процесс веб-сервера должен иметь возможность записывать в эти директории.
У Symfony запись обычно нужна в каталогах кэша и логов внутри var/.
Плохое универсальное решение выглядит так:
chmod -R 777 .
После него ошибка прав часто действительно исчезает. Вместе с ней исчезает и значительная часть защиты файловой системы.
Правильное решение — разобраться:
- от какого пользователя выполняются команды по SSH;
- от какого пользователя работает PHP;
- какие каталоги приложение должно изменять;
- поддерживает ли хостинг общую группу или корректную схему владельцев;
- сохраняются ли права после обновления через Git или файловый менеджер.
На управляемом виртуальном хостинге PHP и SSH часто работают от одного пользователя. Это упрощает права и избавляет от конфликтов между файлами, созданными из консоли и через сайт.
Как это устроено на Siteko. PHP и SSH работают от одного пользователя, а каждый аккаунт изолирован от соседей на уровне файловой системы. Запись в
storage/,bootstrap/cache/и runtime-каталоги работает со штатными правами —chmod 777не нужен.
Требование №9. Символические ссылки должны быть разрешены
Символическая ссылка — это указатель из одного места файловой системы в другое.
Laravel использует такую схему для публичных пользовательских файлов:
php artisan storage:link
Команда создаёт ссылку:
public/storage -> storage/app/public
Официальная структура Laravel предусматривает этот способ публикации файлов из storage.
Символические ссылки также используются при:
- атомарном деплое релизов;
- вынесении общей папки с загрузками;
- подключении
publicк стандартномуpublic_html; - разделении кода и изменяемых данных;
- быстром откате на предыдущую версию.
Некоторые хостинги запрещают symlink полностью или разрешают только ссылки внутри домашнего каталога. Второй вариант обычно достаточен, но проверить его лучше заранее.
Как это устроено на Siteko. Символические ссылки внутри аккаунта разрешены:
ln -sдоступна в консоли,php artisan storage:linkи схемы с общими каталогами между релизами работают без дополнительных настроек.
Требование №10. Секреты и настройки должны храниться отдельно от кода
У приложения есть настройки, которые различаются на компьютере разработчика и на production-сервере:
APP_ENV=production
APP_DEBUG=false
APP_URL=https://example.com
DB_HOST=localhost
DB_DATABASE=example
DB_USERNAME=example_user
DB_PASSWORD=strong-password
Обычно они хранятся в .env или задаются через переменные окружения.
Такой файл:
- не должен попадать в публичную директорию;
- не должен храниться в открытом Git-репозитории;
- не должен перезаписываться при каждом деплое;
- должен резервироваться безопасным способом;
- должен иметь ограниченные права чтения.
Опасная практика — включить подробный режим отладки на рабочем сайте. Страница ошибки может показать пути к файлам, фрагменты конфигурации, SQL-запросы и другие внутренние данные.
Для production-окружения отладка отключается:
APP_ENV=production
APP_DEBUG=false
А причину ошибки ищут в логах, а не показывают посетителю.
Требование №11. Нужны доступные логи приложения
Ошибка 500 без лога означает только одно: «что-то пошло не так».
Ошибка 500 вместе с сообщением:
SQLSTATE[HY000] [1045] Access denied for user
уже почти содержит готовое решение.
Перед покупкой хостинга полезно выяснить, доступны ли:
- error log PHP;
- журнал веб-сервера;
- собственные логи приложения;
- вывод cron-заданий;
- журнал фоновых процессов;
- история потребления ресурсов.
Разработчик должен иметь возможность прочитать лог через SSH или панель, не обращаясь в поддержку после каждой ошибки.
На Laravel лог обычно находится здесь:
storage/logs/
На Symfony:
var/log/
Но одной доступности файлов недостаточно. Нужно, чтобы приложение имело право их создавать, а хостинг не удалял журнал слишком быстро.
Требование №12. Следует смотреть не только на гигабайты
Тариф может обещать:
- 30 ГБ диска;
- неограниченное количество сайтов;
- неограниченный трафик;
- десятки баз данных.
При этом реальным ограничителем современного приложения окажется совсем другой параметр:
- память одного PHP-процесса;
- суммарное процессорное время;
- количество одновременно работающих процессов;
- время выполнения CLI-команды;
- число файлов;
- дисковые операции;
- количество соединений с базой;
- возможность запуска дочерних процессов;
- минимальный интервал cron;
- запрет фоновых workers.
Composer, frontend-сборка и само приложение создают много небольших файлов:
vendor/
node_modules/
storage/framework/
var/cache/
Поэтому лимит inode — количества файлов и каталогов — иногда заканчивается раньше дискового пространства.
Надпись «50 ГБ» ничего не говорит о том, сможет ли тариф выполнить composer install или npm run build.
Минимальный чек-лист хостинга для PHP-фреймворка
| Возможность | Зачем нужна | Что спросить у хостера |
|---|---|---|
| Выбор версии PHP | Совместимость фреймворка и пакетов | Можно ли отдельно выбрать PHP для сайта и CLI |
| PHP-расширения | Работа базы, строк, изображений и пакетов | Какие расширения доступны и можно ли их включать |
| SSH | Composer, консольные команды, диагностика | Какие команды разрешены в SSH |
| Composer | Установка PHP-зависимостей | Какая версия Composer и есть ли лимиты памяти |
| Node.js и npm | Сборка CSS и JavaScript | Какие версии доступны, можно ли выполнять npm ci |
| Настраиваемый Document Root | Безопасный доступ только к public |
Можно ли направить домен на каталог проекта public |
| Cron каждую минуту | Scheduler и регулярные задания | Какой минимальный интервал запуска |
| Фоновые процессы | Постоянная обработка очередей | Можно ли запускать workers и кто их перезапускает |
| Символические ссылки | Storage, релизы и безопасная структура | Разрешены ли symlink внутри аккаунта |
| Доступ к логам | Диагностика 500 и фоновых ошибок | Где находятся PHP-, web- и cron-логи |
| Git | Обновление проекта без FTP | Можно ли подключаться к репозиторию по SSH |
| MySQL или PostgreSQL | Хранение данных | Какие версии, лимиты соединений и размер базы |
| Redis | Кэш, сессии и некоторые очереди | Доступен ли Redis и входит ли он в тариф |
| Резервные копии | Восстановление после ошибок | Что копируется и можно ли скачать независимую копию |
| Лимиты ресурсов | Реальная производительность | RAM, CPU, процессы, inode и время CLI-команд |
Если поддержка не может ответить на эти вопросы и вместо этого сообщает только объём диска, количество сайтов и «поддержку PHP», вероятность проблем после переезда довольно высока.
Наши ответы на этот чек-лист собраны на одной странице — хостинг для PHP: PHP 5.2–8.5 с совпадением версий для сайта, консоли и cron, глобальный Composer, Git, Node.js через nvm, произвольный Document Root, MySQL 8.0 и PostgreSQL 16. Из честных «нет»: Redis-сервера и постоянных worker-процессов на виртуальном хостинге нет — это граница, за которой начинается VDS.
Как выглядит нормальное размещение проекта
Предположим, в аккаунте создана такая структура:
/home/user/
└── www/
└── example.com/
└── project/
├── app/
├── config/
├── public/
├── storage/
├── vendor/
├── .env
├── artisan
├── composer.json
├── composer.lock
├── package.json
└── package-lock.json
Домен направлен на:
/home/user/www/example.com/project/public
Затем разработчик подключается по SSH:
cd ~/www/example.com/project
Устанавливает PHP-зависимости:
composer install \
--no-dev \
--prefer-dist \
--optimize-autoloader \
--no-interaction
Если frontend собирается на сервере:
npm ci
npm run build
Создаёт production-конфигурацию и проверяет соединение с базой.
Для Laravel выполняет:
php artisan key:generate
php artisan migrate --force
php artisan storage:link
php artisan optimize
Для Symfony последовательность будет другой, но логика та же: установка vendor-зависимостей, миграции, очистка и прогрев кэша входят в типовой процесс деплоя.
Затем добавляется scheduler:
* * * * * cd /home/user/www/example.com/project && php artisan schedule:run >> /dev/null 2>&1
И проверяются права на изменяемые директории:
test -w storage && echo "storage writable"
test -w bootstrap/cache && echo "cache writable"
После этого сайт не просто «открывается». Он развёрнут в структуре, которую ожидает фреймворк.
Как это устроено на Siteko. Именно такой сценарий поддерживается из коробки. Проект попадает на хостинг через
git clone—gitдоступен в консоли, приватный репозиторий подключается по deploy-ключу, а для GitHub в панели есть модуль «Импорт из GitHub». На тарифах Master и Expert при заказе можно включить опцию «Подготовить окружение под фреймворк»: совпадающие версии PHP для сайта и консоли, корневая папка наpublic, база данных и заготовка.envбудут настроены ещё до первого входа по SSH.
Почему копирование vendor и node_modules по FTP — плохой план
Технически можно выполнить Composer и npm на своём компьютере, а затем загрузить результат на хостинг.
Иногда это единственный доступный вариант. Но у него есть несколько слабых мест.
Тысячи мелких файлов. Передача большого числа файлов через FTP медленная и чаще прерывается, чем загрузка одного архива.
Разные окружения. Компьютер разработчика может работать на Windows или macOS, а сервер — на Linux. Некоторые зависимости содержат платформенные компоненты или выполняют установочные скрипты.
Неполное обновление. Часть нового vendor уже загрузилась, часть осталась от старой версии, а сайт в это время продолжает принимать посетителей.
Невоспроизводимый результат. Через несколько месяцев сложно понять, какие команды выполнялись перед загрузкой и почему на сервере лежит именно такой набор файлов.
Сложный откат. Вернуть предыдущую версию большого дерева каталогов через FTP значительно труднее, чем переключить подготовленный релиз.
FTP остаётся полезным для единичных файлов. Но использовать его как основной инструмент деплоя современного приложения — всё равно что обновлять программу вручную, копируя отдельные DLL из архива.
Этой теме будет посвящена следующая статья серии: соберём простой и безопасный деплой через Git, Composer и команды фреймворка без сложной серверной инфраструктуры.
Когда виртуального хостинга действительно достаточно
Хорошо оснащённый виртуальный хостинг подходит, когда:
- приложение обслуживает умеренный трафик;
- не нужны собственные системные пакеты;
- используются стандартные PHP-расширения;
- frontend можно собрать на хостинге или в CI;
- scheduler запускается через cron;
- очередь либо небольшая, либо поддерживается панелью;
- нет постоянно работающих WebSocket-сервисов;
- проект укладывается в лимиты памяти и процессов;
- серверную часть обслуживает сам хостер.
В такой ситуации VPS может не дать заметного преимущества. Напротив, вместе с ним появятся дополнительные обязанности:
- обновление операционной системы;
- настройка веб-сервера;
- конфигурация PHP-FPM;
- защита SSH;
- резервное копирование;
- мониторинг;
- восстановление после аварий.
Виртуальный хостинг снимает эти задачи, но при этом может предоставлять разработчику все необходимые инструменты внутри аккаунта.
Когда пора смотреть в сторону VPS
VPS становится оправданным, если проекту нужны:
- постоянно работающие очереди с несколькими workers;
- Laravel Horizon;
- WebSocket-сервер;
- собственные демоны;
- нестандартные системные библиотеки;
- отдельные настройки nginx или PHP-FPM;
- Meilisearch, Elasticsearch или другие сервисы;
- много памяти для фоновых задач;
- специальная конфигурация базы данных;
- Docker;
- высокая и предсказуемая нагрузка;
- полный контроль над сетью и процессами.
Но важно различать две причины переезда.
«На текущем тарифе нет SSH и нельзя выбрать public» — это не обязательно причина покупать VPS. Возможно, достаточно выбрать современный виртуальный хостинг.
«Приложению нужны четыре постоянных worker-процесса, Redis, WebSocket и собственный поисковый сервис» — уже архитектурная причина для отдельного сервера.
Грабли современного PHP-хостинга
| Грабля | Симптом | Решение |
|---|---|---|
Весь проект лежит в public_html |
Риск доступа к .env, логам и исходникам |
Направить домен только на public |
| В панели выбрана одна версия PHP, в SSH работает другая | Composer проходит, сайт падает — или наоборот | Использовать одинаковую версию PHP для web и CLI |
На production выполнен composer update |
Неожиданно обновились пакеты | Коммитить composer.lock и выполнять composer install |
Загружен код без каталога vendor |
Ошибка загрузки vendor/autoload.php |
Выполнить Composer на сервере или загрузить готовый артефакт |
| Не выполнена frontend-сборка | Сайт открывается без CSS и JavaScript | npm ci && npm run build либо сборка в CI |
Корень домена указывает не на public |
403, список файлов или неправильный index.php |
Настроить Document Root |
| Не настроен cron | Письма и задания выполняются только при ручном запуске | Добавить scheduler с нужной версией PHP |
| Cron заменяет полноценный worker | Очереди обрабатываются с задержкой | Использовать менеджер процессов или VPS |
На весь проект установлен chmod 777 |
Ошибка исчезла, безопасность тоже | Дать запись только нужным каталогам |
| Нет symlink | Не открываются файлы из storage | Разрешить ссылки или выбрать поддерживаемую схему |
| Включён production-debug | Страница ошибки показывает внутренние данные | Отключить debug и читать логи |
| Тариф выбран только по объёму диска | Composer или npm завершается по лимиту | Проверить RAM, CPU, процессы, inode и CLI-ограничения |
Что в итоге
Хостинг для Laravel, Symfony, Yii или другого PHP-фреймворка — это не отдельный магический тип сервера. Это набор конкретных возможностей.
Нужна консоль, чтобы запускать команды проекта. Нужен Composer, чтобы устанавливать зафиксированные PHP-зависимости. Node.js нужен для сборки интерфейса, если она не выполняется заранее. Cron запускает планировщик. Фоновые процессы обрабатывают очереди. Символические ссылки связывают публичные и служебные каталоги. А Document Root, направленный на public, не даёт интернету увидеть код и секреты приложения.
Главный вывод можно свести к одному правилу:
Современный виртуальный хостинг должен поддерживать не только выполнение PHP-файлов, но и полный жизненный цикл приложения: установку, настройку, сборку, запуск заданий, диагностику и безопасное обновление.
Если все эти инструменты доступны, большинство обычных сайтов на Laravel и других PHP-фреймворках могут нормально работать без собственного VPS.
На Siteko под такие проекты рассчитаны тарифы Master и Expert — с SSH, Composer, Git, Node.js и опцией готового окружения под фреймворк. Подробности и ответы на вопросы из чек-листа — на странице хостинга для PHP.
Но разместить проект — только половина задачи. Его ещё нужно обновлять. В следующей части откажемся от ручной загрузки файлов и соберём воспроизводимый деплой на виртуальном хостинге: Git, Composer, миграции, сборка frontend, очистка кэшей и безопасный откат.
Была статья полезной:
