Сколько RAM нужно для Infisical

MAATRIX

Развернули Infisical на VPS впритык — 2 ГБ показались достаточными для «просто хранилища переменных» — и через пару недель, когда к серверу подключились CI-пайплайны и десяток интеграций, backend начал непредсказуемо перезапускаться под нагрузкой. Официальная документация Infisical почти не даёт цифр под самостоятельный docker-compose хостинг: либо общие фразы про «скромные требования», либо расчёты под Kubernetes с HA. Разберём по контейнерам, что реально ест память в self-hosted Infisical, какие функции толкают расход вверх без связи с числом секретов, и какой сервер брать под команду.

Короткий ответ: сколько памяти закладывать

Память Infisical почти не зависит от количества хранимых секретов — это компактные зашифрованные строки в Postgres, и тысяча секретов весит на диске меньше, чем один средний Docker-образ. Расход определяют интенсивность CI/CD, число активных интеграций и объём аудит-лога — то есть не «сколько секретов», а «как часто к ним обращаются».

Сам backend Infisical в покое — это не гигабайты, а сотни мегабайт: процесс на Node.js не тащит за собой ни JVM, ни ML-библиотек. Основной вес несут Postgres и Redis, и растёт он не линейно с числом секретов, а с активностью команды и подключённых систем.

Из чего состоит стек: три контейнера и их аппетит

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

Порядок цифр — не эталон, а ориентир: версия образа и набор включённых функций двигают их в обе стороны. Два момента обычно упускают из виду: секреты дешёвы, а аудит-лог — нет (запись на каждое действие: кто прочитал, кто изменил, из какого IP — именно эта таблица в Postgres растёт быстрее всего на активной команде); и backend с фоновыми задачами — один процесс, поэтому пик синхронизации интеграций и пик API-нагрузки конкурируют за одну и ту же память.

Как измерить своё потребление, а не полагаться на чужие цифры

Заходим в рабочий каталог и смотрим состояние сервисов и живое потребление:

cd /opt/infisical
docker compose ps --format 'table {{.Service}}\t{{.Status}}'
docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}'

На cgroup v2 docker stats показывает memory.current, куда входит и страничный кеш файловой системы — реальный расход процесса это не отражает точно. Более честная цифра — anon из memory.stat, а пик за время работы контейнера — отдельный счётчик ядра:

docker exec infisical-backend-1 grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat
CID=$(docker inspect -f '{{.Id}}' infisical-backend-1)
cat /sys/fs/cgroup/system.slice/docker-$CID.scope/memory.peak

Если backend уже падал, диагноз ставится по всем контейнерам сразу:

docker inspect -f '{{.Name}} OOMKilled={{.State.OOMKilled}} Exit={{.State.ExitCode}}' $(docker compose ps -aq)
dmesg -T | grep -i 'killed process'

На практике это не явная ошибка «нет памяти», а случайные обрывы: CLI-команда infisical run -- ... в CI отваливается по таймауту, веб-интерфейс отдаёт 502 на несколько секунд, а в docker compose logs backend — резкий обрыв лога без штатного сообщения о завершении, потому что процесс убило ядро. Общий разбор поведения системы при нехватке памяти — в статье что делать при нехватке RAM.

Что толкает память вверх без роста числа секретов

Пиковую нагрузку в Infisical создают не хранимые данные, а активность вокруг них:

• Интеграции. Каждая настроенная синхронизация — с AWS Secrets Manager или Parameter Store, GCP Secret Manager, Vercel, Netlify, Kubernetes, Terraform Cloud и подобными — периодическая или триггерная задача, которая тянет или пушит секреты через внешний API. Десяток активных интеграций означает десяток исходящих HTTP-соединений одновременно и растущую очередь в Redis, если внешний сервис отвечает медленно.
• Ротация и динамические секреты. Infisical умеет сам подключаться к внешним базам и менять учётные данные по расписанию. Каждое подключение — короткоживущий клиент внутри процесса backend; при десятках ротаций на одном таймере они выстраиваются в очередь, и в момент такого «залпа» память подскакивает.
• Machine identities и Universal Auth. У каждого CI-пайплайна и сервера с Infisical Agent — своя machine identity. Всплеск деплоев в конце рабочего дня — это всплеск обменов токенами, а каждый обмен — запрос к backend и запись в rate-limit на стороне Redis.
• Параллельная работа в веб-интерфейсе. Чем больше людей одновременно листают секреты по проектам, тем заметнее нагрузка на пул подключений к Postgres.

Логика та же, что у любого сервиса на очереди фоновых задач: ровное потребление сервер не убивает — убивают синхронные всплески, когда несколько источников нагрузки совпадают по времени.

Как снизить аппетит: тюнинг Postgres, Redis и лимиты контейнеров

Если сервер тесноват, а переезжать пока рано, работать стоит на уровне инфраструктуры, а не приложения — сам Infisical почти не даёт тонких переменных под память процесса. Ограничиваем Postgres разумными значениями под небольшой сервер и ставим жёсткие лимиты на все три контейнера:

services:
  db:
    image: postgres:14-alpine
    command: >
      postgres
      -c shared_buffers=128MB
      -c max_connections=40
      -c work_mem=4MB
      -c effective_cache_size=512MB
    mem_limit: 400m

  redis:
    image: redis:7-alpine
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}", "--maxmemory", "150mb"]
    mem_limit: 200m

  backend:
    mem_limit: 700m

Осторожно с maxmemory-policy у Redis: этот инстанс не только кеш, там же может держаться состояние rate-limiting и очередь фоновых задач. Агрессивное вытеснение ключей политикой allkeys-lru рискует выкинуть незавершённую задачу из очереди раньше, чем она обработана — безопаснее просто ограничить maxmemory без активного вытеснения и следить за docker stats.

mem_limit — предохранитель, а не способ снизить фактическое потребление: занизите его — получите Exit=137 в самый неподходящий момент, например во время ночной ротации секретов. Ставьте лимит с запасом 20–30% сверх наблюдаемого в docker stats. Общий разбор подхода к лимитам CPU и памяти в Docker — в статье про лимиты ресурсов.

Дальше — практические рычаги: ограничьте число активных интеграций тем, что реально используется (лишняя синхронизация — лишний фоновый цикл, даже если результат никто не смотрит); пересмотрите частоту ротации секретов, если она настроена «на всякий случай» чаще, чем нужно; архивируйте старые записи аудит-лога — периодическим DELETE по cutoff-дате через cron, если нет требования хранить весь трейл бессрочно (автоматическая ротация лога в self-hosted community-версии может быть ограничена лицензией, уточняйте в актуальной документации); настройте swap как страховку, а не рабочий режим — для сервиса на пути CI/CD всплеск в своп означает задержку деплоя, а не просто медленный интерфейс, подробнее в статье про подбор swap для VPS.

Какой сервер брать в MAATRIX

Честный минимум: 2 vCPU, 2 ГБ RAM, 20 ГБ NVMe. Подходит для пилота или соло-использования: один-два проекта, редкие обращения из CLI, минимум интеграций. Ограничение называю прямо: любой одновременный всплеск (пара CI-джобов разом плюс кто-то листает интерфейс) начинает конкурировать за память, swap обязателен.

Комфортный вариант: 4 vCPU, 4 ГБ RAM, 40–50 ГБ NVMe. Снимает большинство вопросов для команды до полутора-двух десятков человек с несколькими интеграциями и деплоями несколько раз в день, с запасом на всплеск ротации без деградации API. Если команда крупнее полусотни человек и интеграций — десяток и больше, закладывайте 8 ГБ и планируйте вынос Postgres и Redis на отдельные ресурсы. Диск считайте не под сами секреты (они компактны), а под постоянную запись Postgres — WAL плюс растущая таблица audit log.

Локация. Infisical не обращается к внешним AI-провайдерам и не блокируется по региону сам по себе, но интеграции синхронизируются с внешними облаками — AWS, GCP, Vercel, Kubernetes-кластерами за рубежом. Из локации в Великобритании или США эти обращения идут напрямую и стабильно; из российской локации возможны эпизодические проблемы с доступностью отдельных облачных API, что для сервиса, который должен синхронизировать секреты по расписанию без сбоев, не лучший сценарий. Если все интегрируемые системы и так находятся в России — российская локация логичнее и снимает вопросы с 152-ФЗ.

Domain с A-записью и SSL нужны в любом случае — работать с секретами по HTTP не имеет смысла. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна независимо от локации сервера. Пошаговая установка — в статье как установить и настроить Infisical на VPS, а если рассматриваете альтернативу потяжелее по функциям, но и по требованиям к памяти — сравнение подходов есть в материале про HashiCorp Vault.

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