Как установить и настроить Infisical на VPS

MAATRIX

Секреты приложения — пароли от базы, API-ключи, токены сторонних сервисов — рано или поздно оседают в .env-файлах, разбросанных по репозиториям, чатам и локальным машинам разработчиков. Как только в команде больше одного человека или окружений больше одного (dev/staging/prod), это превращается в источник утечек и путаницы: кто-то закоммитил ключ в git, кто-то забыл обновить пароль после ротации на проде. Infisical закрывает эту проблему: централизованное хранилище секретов с веб-интерфейсом, ролями доступа и CLI, которое разворачивается на вашем VPS за час.

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

Infisical — открытый (open source) менеджер секретов, альтернатива HashiCorp Vault и Doppler, но заметно проще в развёртывании и администрировании. По сути это веб-приложение плюс API поверх PostgreSQL, где секреты хранятся в зашифрованном виде и организованы по проектам и окружениям.

Ключевая модель Infisical:

• Организация — верхний уровень, объединяет пользователей и проекты.
• Проект — обычно соответствует одному приложению или сервису.
• Окружения — внутри проекта: dev, staging, production и любые кастомные.
• Папки и секреты — внутри окружения можно группировать секреты по папкам (/database, /stripe, /smtp).
• Роли и машинные identity — люди получают роли (admin/member/viewer), а CI/CD и серверы получают machine identity через Universal Auth — без личных паролей.

Разворачивать это имеет смысл, если у вас несколько окружений с разными наборами переменных, команда из 3+ человек или CI/CD-пайплайны, которым нужен доступ к секретам без хардкода в конфиге. Для одиночного проекта хватит и docker secrets или .env с правильными правами доступа — Infisical оправдан, когда секретов и людей, работающих с ними, становится больше одного.

Подготовка VPS и установка Docker

Для самостоятельного хостинга Infisical хватит скромной конфигурации: 2 vCPU, 2-4 ГБ RAM, 20 ГБ диска — основная нагрузка приходится на PostgreSQL и Redis, а не на сам бэкенд. Понадобится домен (или поддомен вида secrets.example.com) с A-записью на IP сервера — без него не получить валидный SSL-сертификат, а работать с секретами по HTTP небезопасно.

Устанавливаем Docker и Docker Compose plugin на чистый Ubuntu 24.04:

apt update && apt install -y ca-certificates curl gnupg
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
  > /etc/apt/sources.list.d/docker.list
apt update && apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Проверка: docker compose version. Дальше открываем только 22 (SSH) и 443 (HTTPS) наружу, порт самого Infisical (8080) наружу светить не нужно — он будет закрыт брандмауэром и виден только через Nginx на loopback. Про настройку файрвола подробно — в статье про ufw на VPS.

Установка Infisical через Docker Compose

Официальный самостоятельный хостинг Infisical собирается вокруг трёх контейнеров: сам бэкенд (он же отдаёт и веб-интерфейс), PostgreSQL и Redis. Создаём рабочую директорию и файл docker-compose.yml:

mkdir -p /opt/infisical && cd /opt/infisical

# /opt/infisical/docker-compose.yml
services:
  db:
    image: postgres:14-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: infisical
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: infisical
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - infisical-net

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}"]
    volumes:
      - redis-data:/data
    networks:
      - infisical-net

  backend:
    image: infisical/infisical:latest-postgres
    restart: unless-stopped
    depends_on:
      - db
      - redis
    env_file: .env
    ports:
      - "127.0.0.1:8080:8080"
    networks:
      - infisical-net

networks:
  infisical-net:

volumes:
  db-data:
  redis-data:

Секретный ключ шифрования и ключи подписи токенов генерируются один раз и не должны меняться после запуска — иначе расшифровать уже сохранённые секреты не получится. Генерируем их и создаём .env:

ENCRYPTION_KEY=$(openssl rand -hex 16)
AUTH_SECRET=$(openssl rand -base64 32)
DB_PASS=$(openssl rand -hex 12)
REDIS_PASS=$(openssl rand -hex 12)

cat > /opt/infisical/.env <<EOF
ENCRYPTION_KEY=${ENCRYPTION_KEY}
AUTH_SECRET=${AUTH_SECRET}
POSTGRES_PASSWORD=${DB_PASS}
REDIS_PASSWORD=${REDIS_PASS}
DB_CONNECTION_URI=postgresql://infisical:${DB_PASS}@db:5432/infisical
REDIS_URL=redis://:${REDIS_PASS}@redis:6379
SITE_URL=https://secrets.example.com
NODE_ENV=production
TELEMETRY_ENABLED=false
EOF

chmod 600 /opt/infisical/.env

Замените secrets.example.com на реальный домен и сохраните ENCRYPTION_KEY/AUTH_SECRET в отдельном защищённом месте вне этого сервера — это единственный ключ к расшифровке всех секретов в базе. Дальше поднимаем стек:

cd /opt/infisical
docker compose up -d
docker compose logs -f backend

Дождитесь строки о старте сервера и успешном применении миграций базы данных — на первый запуск обычно уходит от 30 секунд до пары минут в зависимости от VPS.

Nginx как reverse proxy и SSL-сертификат

Бэкенд слушает только 127.0.0.1:8080, наружу его отдаёт Nginx с TLS-терминацией. Если Nginx ещё не установлен — смотрите базовую настройку в статье про Nginx как reverse proxy на VPS. Конфиг для Infisical:

# /etc/nginx/sites-available/infisical.conf
server {
    listen 80;
    server_name secrets.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        client_max_body_size 20m;
    }
}

ln -s /etc/nginx/sites-available/infisical.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Дальше выпускаем сертификат через Certbot — подробный разбор процесса и частых ошибок есть в статье про Let's Encrypt SSL на VPS:

apt install -y certbot python3-certbot-nginx
certbot --nginx -d secrets.example.com

Certbot сам допишет блок listen 443 ssl и настроит редирект с 80 на 443. После этого проверьте https://secrets.example.com в браузере — должна открыться страница регистрации первого администратора Infisical.

Первый запуск: организация, проекты, роли доступа

При первом открытии сайта Infisical предлагает создать аккаунт администратора — это единственный момент, когда регистрация открыта без приглашения, дальше по умолчанию новые пользователи попадают только по инвайту. Создайте организацию (её название видно только участникам), затем — первый проект.

Внутри проекта сразу создаются окружения Development, Staging, Production — их можно переименовать или добавить свои. Дальше заводите секреты вручную через веб-интерфейс либо импортом из существующего .env-файла (кнопка импорта принимает файл в стандартном формате KEY=value).

Роли, которые стоит различать с самого начала:

Практическое правило: разработчикам — доступ к Development, деплой-агентам и опытным инженерам — к Production, а сам ключ доступа к продакшену выдавайте не человеку, а machine identity конкретного пайплайна. Это тот же принцип, что и в Vault — минимальные права по умолчанию, расширение только под конкретную задачу.

Резервное копирование и безопасность

Infisical хранит всё состояние в PostgreSQL — значит, backup этой базы и есть backup всех ваших секретов. Не полагайтесь только на снапшоты диска у провайдера — настройте регулярный дамп:

docker compose exec -T db pg_dump -U infisical infisical | gzip > /opt/infisical-backups/dump-$(date +%F).sql.gz

Добавьте команду в cron с ротацией старых архивов и копируйте дампы за пределы сервера (в объектное хранилище или на другой VPS) — если сервер станет недоступен, а бэкап лежал только рядом с ним, толку от него не будет. Отдельно сохраните ENCRYPTION_KEY и AUTH_SECRET из .env — без них дамп базы бесполезен.

Из практических мер безопасности:

• Держите Infisical за файрволом на 443, без прямого доступа к 8080 извне.
• Включите двухфакторную аутентификацию (TOTP) для всех аккаунтов с ролью admin.
• Настройте SMTP (SMTP_HOST, SMTP_USERNAME, SMTP_PASSWORD в .env) — без него не работают приглашения и сброс пароля.
• Регулярно обновляйте образ: docker compose pull && docker compose up -d — секретные хранилища не то место, где стоит откладывать патчи безопасности.
• Ротируйте секреты после ухода сотрудника из команды — сама по себе смена роли на "нет доступа" не отзывает уже выданные значения, которые он мог скопировать раньше.

Интеграция с приложениями и CI/CD

Смысл централизованного хранилища — не только в веб-интерфейсе, а в том, чтобы приложение получало секреты в рантайме, без файла .env в репозитории. Для этого есть CLI:

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

Дальше локальный запуск приложения с подстановкой секретов из окружения dev:

infisical run --env=dev -- npm run start

Infisical подставит секреты как переменные окружения процесса — файл .env в репозитории больше не нужен вообще. Для CI/CD (GitHub Actions, GitLab CI) используется machine identity через Universal Auth: создаёте identity в проекте, привязываете к нему client ID и client secret, сохраняете их как секреты самого CI, а в пайплайне вызываете:

- name: Fetch secrets
  uses: Infisical/secrets-action@v1
  with:
    client-id: ${{ secrets.INFISICAL_CLIENT_ID }}
    client-secret: ${{ secrets.INFISICAL_CLIENT_SECRET }}
    project-slug: my-project
    env-slug: production
    export-type: env

Так production-секреты не попадают в конфиг пайплайна в открытом виде и не расшифровываются нигде, кроме памяти запущенного job. Для Kubernetes есть отдельный Infisical Operator, синхронизирующий секреты в нативные Secret-объекты кластера — тема отдельной статьи, если у вас k8s-инфраструктура.

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