Как задеплоить Laravel на production: полный гайд для 2026 года

Локально Laravel запускается за пять минут: php artisan serve, .env — и вот ты уже пишешь фичи. Прод — это другой мир. Здесь нет artisan serve, зато есть живые пользователи, деньги и данные, которые нельзя потерять. Деплой — тот самый рубеж, который отделяет «я сделал» от «мы запустили». И если перейти его неподготовленным, последствия будут ощутимыми.

Что такое production на самом деле

Production — это не сервер с кодом. Это контракт. Каждый запрос — это человек, который ждёт, что приложение ответит быстро, правильно и не сольёт его данные. У этого контракта три пункта.

• Постоянство данных. База, файлы, кэш — всё должно переживать деплои, перезагрузки и горизонтальное масштабирование. Ничего эфемерного не должно жить на файловой системе сервера без явного управления.
• Наблюдаемость. В проде нельзя сделать dd() и смотреть, что внутри. Нужны структурированные логи, трекинг ошибок и метрики производительности. Подготовить их лучше до первого реального пользователя, а не после падения.
• Воспроизводимость. Каждый деплой должен быть автоматизирован. Если ты запускаешь git pull и composer install вручную — ты уже ошибаешься. Не потому что не сработает однажды, а потому что откажет в самый неподходящий момент.

И ещё: локальное окружение должно повторять продакшен один в один — версия PHP, расширения, настройки. Если не так, ты занимаешься исследованиями, а не инженерией.

Серверные требования для Laravel 12

Laravel 12 требует PHP 8.2 или выше. Это жёсткое требование. Плюс обязательный набор расширений: BCMath, Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer, XML. На стандартном LEMP-стеке почти всё есть, но Fileinfo и cURL — те самые, которые забывают на минимальных установках.

Рекомендуемый стек для 2026 года выглядит так:

Про FrankenPHP: Laravel 12 официально включает его как альтернативу Nginx. Если у тебя высоконагруженный API или ты смотришь в сторону Octane, оно стоит оценки — там есть персистентный режим, который убирает накладные расходы на загрузку PHP. Но для обычного приложения Nginx + PHP-FPM проще и привычнее.

Nginx: куда указывать и почему это критично

Здесь ломается больше деплоев, чем где-либо ещё. Главное правило: Nginx должен указывать на каталог public/, а не на корень проекта. Внутри public лежит единственная точка входа — index.php. Если выставить корень проекта, твой .env окажется в открытом доступе. Это не теория, а самая реальная дыра, через которую угоняют приложения.

В конфигурации Nginx важны три вещи: root, который смотрит на путь до public, try_files, который перенаправляет все запросы на index.php, и fastcgi_pass, который соединяет Nginx с PHP-FPM. Плюс не забудь спрятать скрытые файлы — dot-файлы не должны быть доступны извне.

SSL ставится через Certbot: certbot --nginx, и он сам пропишет сертификаты Let’s Encrypt. В 2026 году HTTP-редирект на HTTPS и HSTS — обязательная базовая гигиена.

Деплой: Forge или свой сервер

Есть два честных пути. Выбирай исходя из своих задач.

Вариант A: Laravel Forge. Forge провижинит сервер на любом крупном облаке — AWS, DigitalOcean, Hetzner. Он сам настраивает Nginx, PHP-FPM, SSL, Redis, Supervisor и деплой-скрипты. Стоит $15–19 в месяц. Для соло-разработчика или маленькой команды это не лень, а правильное экономическое решение. Конфиги, которые Forge генерирует, уже закалены продакшеном. Ты не тратишь дни на инфраструктуру, а занимаешься кодом.

Вариант B: DIY на VPS. Свой сервер — это валидно, особенно если ты учишься или у тебя спецтребования по комплаенсу. Минимальная последовательность: обновить систему, поставить Nginx, PHP 8.3 нужной версии со всеми расширениями, Composer, Redis и Supervisor. Затем создать отдельного пользователя для приложения — никогда не запускай код под root или www-data с доступом ко всей файловой системе.

Очереди и планировщик

Любое приложение, которое шлёт письма, обрабатывает загрузку файлов или выполняет фоновые задачи, нуждается в queue worker. И без Supervisor процесс умрёт после первой же ошибки. Supervisor следит за воркером и перезапускает его, когда тот падает. Настройка сводится к конфигу процесса и запуску supervisorctl start.

С планировщиком ещё проще: в cron добавляется одна строка — php artisan schedule:run. Всё остальное Laravel сделает сам: и отложенные задачи, и периодические команды.

Zero-downtime деплой

Самый безболезненный способ — атомарный деплой через симлинк. Новая версия кода раскладывается в папку releases/123, а затем симлинк current переключается на неё. Пользователи продолжают работать, пока идёт обновление. Это умеет Deployer, а также Forge со своими деплой-скриптами. Если ты обновляешь приложение через git pull прямо в рабочей папке — готовься к минутам простоя и битым сессиям.

Мониторинг до первого пользователя

Пока ты не запустил прод, настрой наблюдение. Минимум — это логи приложения (стек Laravel пишет их в storage/logs), трекинг ошибок и метрики производительности. Отладчик в проде не работает, поэтому у тебя должен быть инструмент, который сам поймает фатальную ошибку и пришлёт тебе трейс. Иначе ты узнаешь о проблеме от пользователя — а это худший канал связи.

Типичные ошибки

• Открытый .env: корень Nginx указывает на проект, а не на public.
• APP_DEBUG=true в проде. Твои стектрейсы и переменные окружения видят все.
• Не сгенерирован ключ приложения — шифрование и сессии работают криво.
• Нет оптимизаций: php artisan config:cache, route:cache — забывают после каждого деплоя.
• Очереди не запущены: письма не уходят, задачи повисают, а ты этого не видишь.
• Права на storage и bootstrap/cache не настроены — приложение падает с «Permission denied».

Главное — помнить, что деплой это процесс, а не событие. Один раз выстроив его правильно, ты будешь выкатывать новые версии за минуты, а не за вечера. Это и есть тот уровень, когда фраза «у нас прод» звучит как достижение, а не как оправдание.