Кажется, что .env — это просто файл с переменными.
Ну что там можно испортить?
Поменял пару значений, залил на сервер и готово. 😄
А потом начинается самое интересное.
Одна строчка — и приложение вместо production-базы подключается к тестовой.
Или наоборот.
Случайно включился режим разработки, пользователи увидели подробные ошибки сервера, а в логах оказались данные, которые вообще никто не должен был видеть.
Или еще веселее.
Не тот API-ключ.
Не тот SMTP-сервер.
Не тот Redis.
Не тот S3.
Код при этом написан идеально.
Тесты проходят.
CI/CD счастлив.
Но сервис все равно не работает.
Потому что проблема не в коде, а в конфигурации.
Именно поэтому опытные разработчики относятся к env-файлам почти так же серьезно, как к самому приложению.
Они разделяют конфигурации для разработки и production, не хранят реальные секреты в репозитории, проверяют обязательные переменные при запуске и не выкатывают изменения без дополнительной проверки.
Потому что иногда причина большого падения выглядит совсем не драматично.
Не сложный баг.
Не утечка памяти.
Не ошибка в архитектуре.
А всего одна неправильная строка:
DB_HOST=localhost
И после этого вся команда начинает очень внимательно читать файл, который вчера казался «обычным списком переменных». 😅
👇 А вы уже работали с .env или пока только начинаете разбираться, зачем он вообще нужен?