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

MAATRIX

Ставить Keycloak или Authentik ради того, чтобы просто закрыть паролем и 2FA пару внутренних дашбордов за Nginx, часто избыточно — это связка из нескольких контейнеров и сотни мегабайт RAM только на простой. Authelia решает ту же задачу как forward-auth сервис: один компактный процесс на Go, который встаёт перед уже работающим Nginx или Traefik и просто отвечает «пускать/не пускать» на каждый запрос. Разберём, сколько памяти реально нужно под такую схему, как на аппетит влияет выбор бэкенда для хранения сессий и пользователей, и как выставить безопасные лимиты в docker-compose, чтобы не словить OOM на дешёвом тарифе.

Почему Authelia лёгкая: один бинарник, а не связка сервисов

Ключевое архитектурное отличие Authelia от Keycloak (Java/JVM) и Authentik (Python, server + worker) — это один процесс, скомпилированный в нативный Go-бинарник. Нет отдельного JVM с прогревом кучи, нет второго Python-интерпретатора под воркер фоновых задач — есть один статически слинкованный исполняемый файл, который поднимает HTTP-сервер, обрабатывает аутентификацию, 2FA (TOTP/WebAuthn/Duo) и отдаёт вердикт reverse-proxy через auth_request (Nginx) или ForwardAuth middleware (Traefik).

Важно понимать модель: Authelia не проксирует трафик сама. Nginx или Traefik на каждый входящий запрос к защищённому сервису делает внутренний запрос к Authelia («этот пользователь авторизован?»), и только получив 200 OK — пропускает запрос дальше к реальному бэкенду (Grafana, Portainer, внутреннему API и так далее). Это значит, что Authelia не держит на себе весь объём проксируемого трафика — её нагрузка пропорциональна числу проверок авторизации (обычно кешируется в сессии на несколько часов), а не числу байт, которые гоняет защищённый сервис.

Второй фактор экономии — Go-рантайм в принципе тратит меньше памяти на голом старте, чем JVM или CPython: нет байткод-интерпретатора и JIT-прогрева, сборщик мусора работает поверх компактных структур без накладных расходов интерпретируемого языка. Поэтому даже без тюнинга Authelia в состоянии покоя съедает на порядок меньше, чем Keycloak или Authentik — но точную цифру определяет ещё и выбранный бэкенд хранения, о нём ниже.

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

Минимальная установка — сам процесс Authelia с бэкендом file (пользователи в YAML) и local storage provider (встроенный SQLite), без Redis и без внешней БД:

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

Если добавить LDAP как источник пользователей вместо file backend, сам процесс Authelia почти не тяжелеет — LDAP-клиент лёгкий, основная нагрузка (хранение и индексация пользователей) остаётся на стороне LDAP-сервера, который у вас, скорее всего, уже развёрнут отдельно для других сервисов.

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

Ориентир для планирования тарифа. Учитывайте, что помимо самой Authelia на том же сервере обычно уже крутится Nginx/Traefik и защищаемые сервисы — таблица только про добавку от Authelia:

Рост потребления с числом пользователей у Authelia гораздо более пологий, чем у Keycloak или Authentik: сам процесс не хранит в памяти весь каталог пользователей, а обращается к LDAP или БД по запросу и держит в оперативке в основном активные сессии (обычно это счёт на десятки-сотни, а не тысячи объектов одновременно, даже при заметном штате). Основной драйвер роста памяти — не число учётных записей, а количество одновременно активных сессий с включённым WebAuthn/TOTP состоянием и объём правил в access_control, если их сотни.

Если вы уже используете Traefik как единую точку входа для контейнеров, связка с Authelia в роли forward-auth разбирается в статье про Traefik как reverse-proxy для Docker — конфигурация middleware там пригодится один в один.

Бэкенды хранения: от SQLite до Redis — что реально добавляет вес

Сама Authelia лёгкая почти всегда — а вот выбор бэкенда для сессий и постоянного хранилища определяет, что стоит рядом с ней на сервере:

• Local (SQLite) storage provider — данные хранятся в файле на диске, отдельного процесса СУБД нет, накладные расходы по RAM минимальны. Подходит для одного инстанса Authelia без горизонтального масштабирования — это выбор по умолчанию для 90% небольших и средних инсталляций.
• PostgreSQL/MySQL storage provider — нужен, когда вы либо хотите вынести хранилище пользовательских настроек 2FA/WebAuthn за пределы файловой системы контейнера (для бэкапов и миграций), либо готовитесь к HA. Добавляет типичные для СУБД 100–300 МБ в зависимости от настроек shared_buffers/innodb_buffer_pool_size — подробный разбор тюнинга в статье про настройку PostgreSQL на VPS.
• Redis session provider — обязателен, если вы запускаете несколько инстансов Authelia за балансировщиком (HA-режим): без общего хранилища сессий пользователь, чей запрос попадёт на другой инстанс, получит повторный логин. Redis сам по себе лёгкий (обычно десятки мегабайт при разумном числе сессий), инструкция по установке — в статье про настройку Redis на VPS.

Практический вывод: если вам не нужна отказоустойчивость на несколько инстансов, не тащите Redis и внешний Postgres «на всякий случай» — файловый бэкенд с SQLite полностью официально поддерживается для одиночной установки и экономит и память, и сложность эксплуатации.

docker-compose: лимиты памяти и рабочий конфиг

Официальный образ Authelia по умолчанию не ограничен по памяти — на общем сервере с другими контейнерами стоит выставить явный лимит, чтобы редкий всплеск (например, массовая проверка сессий после релиза) не утянул память у соседних сервисов:

services:
  authelia:
    image: authelia/authelia:4.39
    container_name: authelia
    restart: unless-stopped
    mem_limit: 256m
    mem_reservation: 64m
    volumes:
      - ./config:/config
    networks:
      - proxy
    environment:
      TZ: Europe/Moscow
    expose:
      - "9091"
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rd=https://auth.example.com"
      - "traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Name,Remote-Email"

networks:
  proxy:
    external: true

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

Для варианта с Nginx вместо Traefik используется auth_request в конфиге виртуального хоста — базовая настройка reverse-proxy на Nginx описана в статье про Nginx как reverse-proxy на VPS, а сверху добавляется блок location /authelia { internal; proxy_pass http://authelia:9091/api/verify; } и auth_request /authelia; в защищаемых location-блоках.

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

Таблицы выше — ориентир для старта, а не замена измерению под вашу реальную нагрузку:

# Текущее потребление контейнера Authelia
docker stats --no-stream authelia

# Пиковое потребление за время работы контейнера (cgroup v2)
docker exec authelia cat /sys/fs/cgroup/memory.peak

# Если используете Redis для сессий — его собственное потребление
docker stats --no-stream redis

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

# Проверка на OOM-килл, если контейнер падал без явной причины
dmesg | grep -i "out of memory"
journalctl -k | grep -i oom
docker inspect authelia --format '{{.State.OOMKilled}}'

Если mem_limit выставлен слишком туго и контейнер регулярно получает OOMKilled: true, поднимайте лимит шагами по 32–64 МБ — Authelia растёт плавно, резких скачков в разы у неё не бывает вне случаев аномального числа одновременных сессий (например, после сброса всех токенов разом при смене секрета JWT). На небольшом VPS имеет смысл держать 512 МБ – 1 ГБ swap как страховку от кратковременных пиков — как его настроить, описано в статье про swap-файл на VPS.

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