Infisical на Ubuntu 24.04: пошаговая установка

MAATRIX

Секреты команды почти всегда живут не там, где должны: пароль от боевой базы в личке в Telegram, ключ от S3 в .env-файле, который кто-то по ошибке закоммитил, токен API — в переписке с фрилансером, который давно ушёл из проекта. Когда людей больше двух, а окружений больше одного (dev, staging, prod), эта схема начинает течь — вы физически не можете отследить, кто и когда видел какой секрет. Infisical закрывает эту дыру: это self-hosted платформа управления секретами с контролем доступа, версионированием и аудит-логом, которую можно поднять на своём сервере за час и не зависеть от чужого SaaS.

Что такое Infisical и когда он нужен

Infisical — open source аналог HashiCorp Vault, но с прицелом на простоту: веб-интерфейс, где секреты организованы по проектам и окружениям (dev/staging/production), а не абстрактным путям в KV-хранилище. У него есть:

• разграничение доступа по ролям (кто может читать, кто — менять и приглашать);
• версионирование секретов — можно откатить случайную правку;
• аудит-лог: кто, когда и какой секрет запросил или изменил;
• CLI и SDK для Node.js, Python, Go, Java — секреты подтягиваются в приложение при старте, а не хранятся в коде;
• интеграции с GitHub Actions, GitLab CI, Kubernetes — секреты не нужно вручную копировать в настройки CI.

Если у вас один разработчик и один сервер — скорее всего, хватит .env-файла под git-crypt или обычного менеджера паролей. Infisical оправдан, когда в команде несколько человек, несколько окружений и хотя бы один внешний CI/CD, которому нужно выдавать секреты без передачи их «на словах». Если вам ближе классический Vault с его политиками и динамическими секретами для баз данных — почитайте про HashiCorp Vault и управление секретами, это более тяжёлый, но и более гибкий инструмент.

Требования к серверу и установка Docker

Для команды до 15–20 человек и пары десятков проектов достаточно скромной VPS: 2 vCPU, 4 ГБ RAM, 20+ ГБ SSD — это ориентир, а не жёсткий минимум, реальное потребление зависит от числа проектов и глубины аудит-лога, который со временем растёт и требует ротации. Под капотом self-hosted Infisical держит PostgreSQL и Redis, поэтому диск стоит брать с запасом.

Обновите систему и заведите отдельного пользователя без root-прав:

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy

Закройте всё лишнее на файрволе, оставив только SSH, 80 и 443 порт (сам Infisical наружу торчать не должен — только через reverse proxy). Если файрвол ещё не настроен, разберитесь с этим сначала — вот пошаговая настройка UFW-файрвола на Ubuntu 24.04.

Docker и Docker Compose ставятся штатно:

curl -fsSL https://get.docker.com | sh
usermod -aG docker deploy

Полный разбор установки, включая нюансы прав и systemd, есть в отдельной статье про установку Docker на Ubuntu 24.04 с нуля. После установки проверьте, что Compose-плагин доступен:

docker compose version

Разворачиваем Infisical через Docker Compose

Клонируйте официальный репозиторий и перейдите в директорию с docker-compose файлом:

git clone https://github.com/Infisical/infisical.git
cd infisical
cp .env.example .env

Откройте .env.example внутри свежесклонированного репозитория и сверьтесь со списком переменных перед копированием — проект активно развивается, и точный набор ключей (особенно то, что касается SMTP и внешних auth-провайдеров) может немного отличаться от версии к версии. Логика везде одна: обязательные секреты для шифрования данных и подписи токенов плюс адрес, по которому будет доступен сервис.

Два поля заполнить обязательно, и сгенерировать их нужно самостоятельно, а не оставлять примеры из документации:

# ключ шифрования секретов в базе
openssl rand -hex 16

# секрет для подписи auth-токенов
openssl rand -base64 32

Вставьте результат в соответствующие переменные .env (обычно это ENCRYPTION_KEY и AUTH_SECRET — сверьтесь с названиями в вашей версии файла). Туда же пропишите SITE_URL — публичный адрес, на котором будет жить панель, например https://secrets.example.com. Если планируете приглашать людей по почте, укажите SMTP-реквизиты — без них пригласительные письма отправляться не будут, но само приложение при этом работает нормально.

Запускайте стек:

docker compose up -d

Проверьте, что все контейнеры (backend, PostgreSQL, Redis) поднялись и не рестартуют по кругу:

docker compose ps
docker compose logs -f backend

Если контейнер с backend падает сразу после старта — почти всегда причина в незаполненном обязательном поле .env или в том, что PostgreSQL ещё не успел инициализироваться на первом запуске. Дайте базе 20–30 секунд и посмотрите логи снова, прежде чем менять конфиг.

HTTPS и обратный прокси

Сам Infisical слушает локальный порт (обычно 8080) без TLS — выпускать его напрямую в интернет не стоит. Проще всего поставить Caddy: он сам получит сертификат Let's Encrypt и обновит его без вашего участия. Конфиг сводится к одному блоку:

secrets.example.com {
    reverse_proxy localhost:8080
}

Подробности установки и первого запуска Caddy — в статье про Caddy с авто-SSL на Ubuntu 24.04. После того как прокси поднят и сертификат выпущен, закройте порт приложения на файрволе, оставив снаружи только 80 и 443 — обращение к панели должно идти исключительно через домен с HTTPS.

Первый запуск: организация, проект, CLI и CI/CD

Откройте https://secrets.example.com в браузере. Первый созданный аккаунт автоматически становится администратором организации — сразу задайте ему длинный пароль и по возможности включите двухфакторную аутентификацию в настройках профиля.

Дальше структура простая:

1. Создаёте организацию (если ещё не создана автоматически при регистрации).
2. Внутри — проект под конкретный сервис или продукт.
3. Внутри проекта — окружения: dev, staging, production.
4. В каждом окружении — сами секреты в виде пар ключ-значение, с историей изменений.

Приглашайте коллег через панель — ролью можно ограничить доступ, например, только к dev-окружению для junior-разработчиков, оставив production за тимлидом.

Для локальной разработки и CI/CD секреты удобнее не копировать вручную, а подтягивать через CLI. Установка:

curl -1sLf 'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh' | sudo -E bash
apt install infisical

Авторизация и работа с проектом:

infisical login
infisical init
infisical secrets

Самое полезное — запуск процесса с секретами, подставленными в переменные окружения на лету, без файла .env на диске:

infisical run --env=production -- node server.js

Для CI/CD (GitHub Actions, GitLab CI) создайте отдельную Machine Identity или Service Token с правами только на нужный проект и окружение — не используйте для этого личный аккаунт. Если секреты нужны раннеру GitLab, посмотрите заодно настройку GitLab CI/CD на VPS — принцип подключения токена туда логично ложится поверх уже настроенного раннера.

Бэкап, обновление и типичные проблемы

Все секреты и метаданные лежат в PostgreSQL — именно её и нужно бэкапить регулярно, а не полагаться на то, что «Docker volume никуда не денется». Простой вариант — снапшот через pg_dump по крону:

docker compose exec -T postgres pg_dump -U infisical infisical > /backups/infisical-$(date +%F).sql

Храните бэкапы вне сервера — если он станет недоступен, а копии базы нет нигде кроме него самого, вы теряете все секреты организации одновременно, что хуже, чем любая утечка.

Обновление — стандартный для Compose-стека процесс:

cd infisical
git pull
docker compose pull
docker compose up -d

Перед обновлением на мажорную версию стоит свериться с changelog проекта на GitHub — self-hosted Infisical развивается быстро, и между релизами иногда меняется структура схемы базы или обязательных переменных окружения.

Из практики — на что обычно натыкаются в первую неделю: если после логина панель бесконечно грузится, почти всегда дело в неверном SITE_URL (он должен точно совпадать с адресом, по которому вы открываете сайт, включая протокол). Если письма-приглашения не приходят — проверьте SMTP-блок в .env, само приложение при этом продолжит работать, просто приглашение придётся передать ссылкой вручную. А если после обновления контейнер backend не стартует — почти наверняка не применилась миграция базы; смотрите docker compose logs backend — там обычно прямо написано, какой шаг не прошёл.

Частые вопросы