Как мы перестали пересылать пароли в Telegram и нашли идеальный менеджер секретов

Почему .env файлы — это тихий ужас

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

1. Собираете все эти данные (а часть уже устарела)
2. Пакуете в архив с паролем
3. Отправляете «безопасным» способом (читай: тем же Telegram)
4. Молитесь, что он не попадёт не в те руки

И самое страшное — когда через полгода нужно обновить какой-то ключ. Вы обновляете его у себя, но как быть с остальными членами команды? «Ребята, обновите, пожалуйста, вот этот секрет» — и начинается хаос.

Наше открытие: Infisical

После очередного инцидента «а почему у меня не работает? — а, у тебя старый .env» мы решили: хватит. Начали искать solution и нашли Infisical — self-hosted менеджер секретов с открытым исходным кодом.

Почему именно он?

• Бесплатно — Community Edition полностью покрывает наши нужды
• Self-hosted — наши секреты остаются на наших серверах
• Простота — разворачивается за 10 минут
• Мощность — все нужные фичи есть даже в бесплатной версии

Развёртывание: проще, чем кажется

Мы ожидали сложностей, но всё оказалось элементарно. Infisical состоит всего из трёх компонентов:

• Основное приложение
• Redis для кэширования
• PostgreSQL для хранения данных

Развернули через Docker Compose на нашем сервере, настроили резервное копирование базы — и готово. Важный момент: сразу заменили дефолтные ключи шифрования на свои, сгенерированные локально.

Как теперь работает наш workflow

Организация проектов стала логичной:

text

Организация (наша компания)
├── Проект "Основной бэкенд"
├── Проект "Админка"
└── Проект "Мобильное приложение"

В каждом проекте — окружения: development, staging, production. Можно добавить свои (у нас есть ещё testing и demo).

Секреты теперь не просто набор ключ-значение:

• Добавляем теги: database, api, payment, monitoring
• Используем ссылки: DATABASE_URL собирается из DB_HOST, DB_PORT, DB_NAME
• Настраиваем доступы: кто может только читать, кто — редактировать

Фичи, которые покорили нас

История изменений — когда что-то ломается, за 30 секунд находим, кто и когда менял секрет. И откатываем при необходимости.

Временное переопределение (Override) — нужно потестировать с другой БД? Нажимаем Override, подставляем тестовые данные, запускаем. Оригинальные значения остаются нетронутыми.

Проверка утечек — запускаем infisical scan, и система проверяет всю историю Git на наличие случайно закоммиченных секретов. Нашли пару старых — почистили.

Интеграция в разработку: магия одного терминала

Раньше: «Скачай .env, положи в корень, не забудь переименовать...»

Теперь:

bash

infisical login
infisical init
infisical run --env=development -- npm start

Новый разработчик в первый же день запускает проект. Без скачивания файлов, без вопросов «а где взять вот этот ключ?».

Как мы поделили доступы

Роли в Infisical:

• Viewer — видит секреты, но не может менять (для аналитиков, тестировщиков)
• Developer — читает и пишет (разработчики)
• Admin — полный доступ + управление настройками (тимлиды)

Больше никаких «кинь мне пароль от продакшн-БД». Если человеку нужен доступ — добавляем его в проект с нужной ролью.

Реальные результаты через 3 месяца

1. На 90% меньше вопросов «а почему у меня не запускается?»
2. Новый разработчик за 15 минут с нуля запускает весь стек
3. При обновлении секретов вся команда синхронизируется автоматически
4. Ни одной утечки за весь период

Наши выводы

Infisical — не просто «ещё один инструмент». Это изменение культуры работы с секретами. Мы наконец-то:

• Перестали бояться утечек
• Избавились от хаоса с обновлением переменных
• Сделали онбординг новых разработчиков приятным
• Получили контроль над тем, кто что видит и меняет

И самое главное — теперь мы можем спать спокойно, зная, что наши секреты в безопасности. А ведь всё начиналось с простого желания перестать кидать пароли в Telegram