Описать проблему ↗

PHP и Laravel

Laravel игнорирует изменения .env после деплоя

Изменили .env, а Laravel продолжает использовать прежние настройки. Объясняем кеш конфигурации и различия между веб-запросами и фоновыми процессами.

Редакция «починимсайт» · Обновлено · 3 мин. чтения

Что происходит и с чего начать

Файл .env — один из источников настроек, но приложение может работать с заранее собранной конфигурацией. Кроме того, долгоживущие процессы не обязаны перечитывать изменения при каждом задании. Поэтому правильное значение в файле ещё не доказывает, что оно загружено текущим обработчиком. Начните с конкретного параметра и места, где видно старое поведение: страница, очередь или расписание. Проверяйте только нужные безопасные значения; вывод всей конфигурации может раскрыть пароли и ключи интеграций.

Что можно проверить самостоятельно

  1. Запишите имя параметра и ожидаемое поведение, не раскрывая значение секрета. Уточните, где именно остаётся старая настройка и когда был запущен соответствующий процесс.
  2. Проверьте, редактируется ли файл действующей установки, а не тестовой копии или предыдущего релиза. На сервере могут одновременно существовать несколько похожих каталогов проекта.
  3. Сообщите, используется ли сборка конфигурации при публикации. Уточните порядок перезапуска очередей и других длительно работающих сервисов после изменения настроек.

Как понять результаты проверки

Разработчик проверяет источник значения и штатно пересобирает конфигурацию, затем обновляет нужные процессы. Если env читается напрямую в произвольном месте кода, поведение после кеширования может отличаться от ожидаемого: настройки должны использоваться согласованно с архитектурой приложения. Важно не очищать всё подряд без понимания, какие данные затронуты. Изменение конфигурации и удаление пользовательского кеша или сессий — разные действия. Результат должен воспроизводиться после обычной публикации, а не держаться на разовой ручной правке состояния.

Что проверяет разработчик

Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.

  1. Убедитесь, что изменён файл нужного релиза и окружения. Проверьте, не переопределяется ли значение переменными службы или контейнера.
  2. Сравните конфигурацию веба, консоли и worker. Один процесс может использовать старые настройки, пока другой уже перезапущен.
  3. Проверьте использование env вне конфигурационных файлов. При кешировании конфигурации такой код может вести себя иначе, чем локально.

На что обратить внимание

Редактирование .env не обновляет автоматически уже собранную конфигурацию и память работающих процессов. Поэтому тест почты из консоли иногда проходит, а очередь продолжает ошибаться.

Как исправляют причину

Обновите конфигурационный кеш штатной процедурой для нового релиза и перезапустите нужные долгоживущие процессы. Обращайтесь к настройкам через конфигурацию приложения, сохраняя секреты вне публичных ответов.

Как убедиться, что проблема решена

Проверьте реальное действие каждым затронутым исполнителем: веб, очередь и расписание. В диагностике достаточно названия окружения и безопасных признаков подключения, а не полного дампа настроек.

Проверьте нужный параметр в веб-запросе и фоновой задаче без вывода секретов. Затем повторите штатную процедуру публикации или перезапуска на подходящем окружении. Убедитесь, что значение не возвращается к старому. Если менялись доступы внешнего сервиса, дополнительно проверьте реальную операцию: корректно загруженная строка ещё не подтверждает, что подключение принимается другой системой и работает как ожидается.