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

MAATRIX

Keycloak решили не ставить — слишком тяжёлый и неповоротливый для флоу-редактора и UI, который не стыдно показать сотрудникам, — и выбор пал на Authentik. Разворачивается он в три-четыре контейнера сразу (сервер, воркер, Postgres, Redis), и первый практический вопрос — сколько оперативной памяти закладывать в тариф, чтобы не словить OOM-килл в первую неделю продакшена и не переплачивать за неиспользуемый запас. Разберём архитектуру Authentik по потреблению памяти, дадим ориентировочные цифры по числу пользователей и покажем, как выставить лимиты в docker-compose и проверить реальную нагрузку на своём сервере.

Из чего состоит Authentik и почему это не одно приложение

Authentik — это не монолит, а связка минимум из четырёх сервисов, и каждый вносит свой вклад в общий расход RAM:

• server — процесс на Python (Django + Gunicorn/Uvicorn), который обслуживает веб-интерфейс, API и сам процесс аутентификации/авторизации по OAuth2, SAML, LDAP, proxy-провайдерам;
• worker — фоновый процесс на той же кодовой базе, отвечает за задачи по расписанию, отправку email, синхронизацию с внешними источниками (LDAP, SCIM), обработку flow-шагов, которые не укладываются в один HTTP-запрос;
• PostgreSQL — основное хранилище: пользователи, группы, политики, flow-конфигурации, журналы событий;
• Redis — брокер задач для worker (task queue) и кеш сессий/токенов.

Официальная документация Authentik называет минимальными требованиями 2 vCPU и 2 GB RAM — но это цифра «чтобы вообще запустилось и не упало сразу», без запаса под несколько одновременных логинов, LDAP-outpost или активные flow-политики с внешними API-вызовами. На практике под реальную команду, даже небольшую, стоит закладывать больше — ниже разберём почему.

Важный нюанс архитектуры: server и worker — это два отдельных процесса Python, каждый со своим интерпретатором, своим набором загруженных модулей Django и своим базовым потреблением памяти в состоянии покоя (idle). Именно поэтому Authentik ощутимо тяжелее по RAM, чем условный «однопроцессный» SSO-сервис — вы платите не за одно приложение, а фактически за два экземпляра одного и того же Python-стека плюс СУБД плюс брокер.

Базовое потребление в состоянии покоя (idle)

Если поднять Authentik через официальный docker-compose и не логиниться, потребление памяти распределится примерно так (ориентир, точные числа зависят от версии образа и загруженных провайдеров — сверяйте на своём сервере через docker stats):

Это база — Python-процессы Django поднимают в память весь код фреймворка, ORM-модели, шаблоны и клиенты для всех включённых провайдеров (OAuth2, SAML, LDAP, SCIM, RADIUS), даже если вы используете только один. Отключить неиспользуемые провайдеры на уровне процесса нельзя — это часть общего Django-приложения, а не отдельные плагины с ленивой загрузкой. Дальше поверх этой базы добавляется нагрузка от реальных логинов, активных сессий и flow-политик — и вот тут разброс уже зависит от размера команды.

Сколько RAM нужно под разные сценарии

Ориентировочные цифры для docker-compose установки на одном сервере (server + worker + Postgres + Redis в контейнерах). Это именно ориентир для планирования тарифа, а не гарантированный потолок — при интенсивной LDAP-синхронизации или сложных flow с внешними API-вызовами (например, проверка через сторонний antifraud-сервис на этапе логина) worker может выедать заметно больше.

Ключевой драйвер роста — не столько число пользователей само по себе, сколько частота логинов и сложность flow. Пользователь, который логинится раз в день, почти не влияет на память после первого запроса. А вот MFA на каждом шаге, обращение к внешнему LDAP на каждый вход, множество forward-auth провайдеров перед разными приложениями (каждый добавляет обработку в proxy-outpost) — это то, что реально нагружает server и worker под нагрузкой, а не в простое.

Если вы ставите Authentik как единую точку входа для десятка внутренних сервисов (Grafana, Gitea, дашборды), закладывайте средний или крупный сценарий из таблицы сразу — лучше не начинать с впритык рассчитанного 2 ГБ VPS.

Соседи по серверу: PostgreSQL и Redis тоже просят своё

Отдельная ошибка при расчёте RAM под Authentik — считать только сами контейнеры server/worker и забывать, что PostgreSQL и Redis рядом тоже растут вместе с нагрузкой:

• PostgreSQL по умолчанию использует скромный shared_buffers (обычно 128 МБ в дефолтном образе), но при активном журналировании событий Authentik (а он логирует в БД каждый вход, каждое срабатывание политики) размер базы и, соответственно, полезный кеш для быстрых выборок растёт. На команде от 100+ активных пользователей стоит поднять shared_buffers до 256–512 МБ и выделить под это отдельный запас RAM сверх таблицы выше.
• Redis используется и как брокер задач Celery (worker), и как кеш сессий — при большом числе одновременных сессий и активной очереди фоновых задач (например, массовая SCIM-синхронизация групп) потребление растёт линейно от числа объектов в памяти, но обычно остаётся на порядок меньше, чем у Postgres и самих Python-процессов.

Если у вас уже есть отдельный тюнингованный PostgreSQL для других сервисов на этом же сервере — общие принципы настройки shared_buffers, work_mem и effective_cache_size подробно разобраны в статье про тюнинг PostgreSQL на VPS, логику там можно применить и к базе Authentik.

docker-compose: как выставить лимиты памяти правильно

Официальный docker-compose Authentik по умолчанию не задаёт mem_limit — сервисы могут захватывать сколько угодно RAM, пока не упрутся в лимит хоста и не сработает OOM killer ядра, который выберет жертву не всегда предсказуемо (может убить не Authentik, а соседний контейнер). Явные лимиты — обязательная практика для прода:

services:
  server:
    image: ghcr.io/goauthentik/server:2026.6
    command: server
    deploy:
      resources:
        limits:
          memory: 1g
        reservations:
          memory: 512m
    environment:
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_REDIS__HOST: redis
    depends_on:
      - postgresql
      - redis

  worker:
    image: ghcr.io/goauthentik/server:2026.6
    command: worker
    deploy:
      resources:
        limits:
          memory: 768m
        reservations:
          memory: 384m
    depends_on:
      - postgresql
      - redis

  postgresql:
    image: postgres:16-alpine
    deploy:
      resources:
        limits:
          memory: 1g
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
    volumes:
      - database:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    deploy:
      resources:
        limits:
          memory: 256m
    command: --maxmemory 200mb --maxmemory-policy allkeys-lru

volumes:
  database:

Обратите внимание на --maxmemory у Redis: без него контейнер будет расти бесконтрольно при накоплении сессий, а allkeys-lru даёт предсказуемое поведение при упоре в лимит — вытесняются наименее используемые ключи, а не падает процесс. Для сервисов на голом docker run (без Swarm/deploy:) те же лимиты задаются флагами --memory=1g --memory-swap=1g.

Если вы ставите Authentik классическим docker-compose без Swarm-режима, ключ deploy.resources в нём игнорируется — вместо него нужен старый синтаксис mem_limit и mem_reservation на уровне сервиса. Разница и подводные камни обоих подходов разобраны в статье про лимиты CPU и памяти в Docker — стоит свериться перед тем, как копировать конфиг выше в прод.

Как измерить реальное потребление на своём сервере

Таблицы и ориентиры — это стартовая точка, а не замена измерению. После недели-двух работы под реальной нагрузкой проверьте фактическое потребление:

# Живая картина по всем контейнерам Authentik
docker stats --no-stream $(docker ps --filter "name=authentik" --format "{{.Names}}")

# Пиковое потребление worker за период (если нужен график — подключите Prometheus)
docker exec authentik-worker cat /sys/fs/cgroup/memory.peak

# Свободная память и swap на хосте целиком
free -h

# Логи OOM killer, если контейнер падал без явной причины
dmesg | grep -i "out of memory"
journalctl -k | grep -i oom

Если docker stats показывает, что server или worker стабильно упираются в лимит и получают OOM-килл (docker ps -a покажет статус Exited (137)), поднимайте mem_limit шагами по 256–512 МБ — резких скачков в разы обычно не бывает, кроме случаев массовой LDAP/SCIM синхронизации при первом запуске, когда Authentik разом обрабатывает всех существующих пользователей и группы источника.

Отдельно стоит настроить 1–2 ГБ swap как страховку от кратковременных пиков (массовый логин после релиза, когда токены протухли у всех разом), но не как основной ресурс — при постоянной работе в swap производительность аутентификации заметно просядет, и это сигнал брать тариф с большим RAM.

Экономия RAM: что реально можно отключить

Возможности урезать потребление у Authentik меньше, чем у более гибких по составу инструментов, но кое-что есть:

• Отключить неиспользуемые outposts. Каждый proxy/LDAP-outpost — это отдельный контейнер со своим базовым потреблением (обычно 30–80 МБ). Если LDAP наружу не нужен — не поднимайте ldap-outpost, экономия небольшая, но реальная.
• Не гнаться за отдельным worker-процессом на каждый тип задачи. В отличие от некоторых Celery-based систем, где заводят пул воркеров под очереди, штатная схема Authentik — один worker-контейнер, и дробить его вручную обычно не нужно и не даёт выигрыша по памяти.
• Ограничить количество логируемых событий. В System > Settings можно сузить уровень событийного журнала — меньше записей в Postgres, меньше рост базы со временем и меньше нагрузка на дисковый кеш при активных выборках.
• Не держать PostgreSQL и Redis в контейнерах, если на сервере уже есть отдельная инсталляция. Если у вас уже поднят Postgres для других проектов (шаблон настройки — в статье про установку PostgreSQL на VPS), можно завести отдельную БД authentik в нём вместо отдельного контейнера — экономит ту самую сотню-другую мегабайт на дублирующемся процессе Postgres. То же с Redis — общая инсталляция, отдельная база по номеру (REDIS_DB).

Реальный выигрыш по RAM даёт в основном вынос Postgres/Redis в общие инсталляции — сами server и worker ужать без потери функциональности почти нельзя, это фиксированная цена за Django-стек с полным набором провайдеров.

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