Пошук уроків, статей та іншого контенту
Як зберігати налаштування й секрети окремо від коду через process.env — і чому .env не комітять.
Адреса бази даних, API-ключі сторонніх сервісів, режим роботи (розробка/продакшн) — усе це відрізняється між середовищами (локальна машина розробника, staging, продакшн-сервер) і не повинно бути захардкоджене прямо в коді. Змінні середовища — стандартний спосіб операційної системи передати конфігурацію процесу ззовні, без зміни самого коду.
Node.js надає доступ до змінних середовища через глобальний об'єкт process.env — усі значення в ньому завжди рядки, навіть якщо семантично це число чи булеве значення:
const port = process.env.PORT || 3000; // рядок "3000" або "3000" за замовчуванням
const isProduction = process.env.NODE_ENV === "production"; // порівняння рядків
console.log(`Сервер запускається на порту ${port}`);Встановлювати змінні середовища вручну перед кожним запуском незручно, тому для локальної розробки використовують .env-файл із парами ключ-значення, який завантажує бібліотека (наприклад, dotenv) на самому початку запуску застосунку:
# .env
DATABASE_URL=postgresql://user:pass@localhost:5432/mydb
API_SECRET_KEY=sk_test_abc123import "dotenv/config"; // завантажує .env у process.env до решти коду
console.log(process.env.DATABASE_URL);.env-файли з реальними секретами (паролі бази даних, API-ключі) ніколи не комітять у git — їх додають у .gitignore, а в репозиторії лишають лише приклад-шаблон (зазвичай .env.example) із назвами змінних без реальних значень. Комітнутий секрет лишається в історії git назавжди, навіть якщо пізніше видалити файл — його потрібно вважати скомпрометованим і згенерувати новий.
Оскільки process.env — це просто рядки без жодної типізації чи гарантії наявності, надійні застосунки перевіряють обов'язкові змінні одразу при старті (а не в момент, коли їх бракує посеред обробки запиту) — застосунок краще одразу відмовиться запускатись з зрозумілим повідомленням, ніж впаде значно пізніше на невідомій змінній.
Комітнути .env із реальними секретами в git — навіть у приватному репозиторії це серйозний ризик, і секрет потрібно вважати скомпрометованим одразу після коміту.
Порівнювати process.env.SOME_FLAG з булевим значенням напряму (if (process.env.DEBUG)) — значення завжди рядок, тому навіть рядок "false" є truthy; потрібне явне порівняння === "true".
Не перевіряти наявність обов'язкових змінних середовища при старті застосунку — помилка проявляється значно пізніше, посеред обробки запиту, замість зрозумілого повідомлення при старті.
process.env дає доступ до змінних середовища операційної системи — стандартний спосіб тримати конфігурацію (адреси сервісів, режим роботи, секрети) окремо від коду й окремо для кожного середовища. Для локальної розробки .env-файл (завантажений через dotenv чи вбудовану підтримку) замінює ручне встановлення змінних, але ніколи не потрапляє в git разом із реальними секретами. Усі значення в process.env — рядки, і обов'язкові з них варто перевіряти одразу при старті застосунку.