Authentik vs Authelia: Measured RAM per Container

Pick Authelia when RAM is tight: it is one container, it idled at 60 MiB, and under 60 logins it peaked at 626 MiB (highest run 657 MiB) in our lab, medians of three runs. By our sizing rule that is a 1 GB plan, but only 38 MiB under the line, so we would use 2 GB if the box runs anything else. Pick authentik if you need SAML, an LDAP server or an admin web interface, and give it 2 GB: its three containers (server, worker, PostgreSQL) idled at 942 MiB (843 to 1,063) and peaked at 1,092 MiB. The two did not do the same work per login (1 request against 9), so the latency gap is not a head-to-head. The feature table is researched, not tested. The lab had one user, no TLS and no reverse proxy.

Side-by-side measured table

Source for every row: Tested, from authentik.json and authelia.json (three runs each, Oct 20, 2026), with the arithmetic in lab/notes/sso-2026-10-20.md and the script that produced it. Each figure is the median of three runs, lowest to highest in brackets. RAM is Docker’s working set (usage minus inactive file cache), sampled every 2 to 3 seconds, so a spike shorter than that is missed. CPU is in percent of one core on the lab host, so 200 means both cores busy.

Both apps ran in their own GitHub Actions job (2 vCPU, 7.8 GiB RAM, Ubuntu 24.04.5, Docker 28.0.4) on an AMD EPYC 7763 in all six runs, so the runner type and CPU model are the same. Each run was a fresh stack: start, wait for health, setup, wait for memory to settle, a 30-second idle window, a short pre-flight of a few requests (not counted), then the load. The load was one Python script playing the reverse proxy over plain HTTP: 60 password logins of one user, 4 at a time, then 3,000 authorization checks (the call a proxy makes for every request), 8 at a time, spread over the 60 sessions. All 60 logins and all 3,000 checks succeeded in all six runs, with no failed request, restart or out-of-memory kill.

How to read it.

• RAM is the headline, and it carries across hosts. Idle authentik used 15.7 times Authelia’s idle RAM (942.0 against 60.1 MiB), and its load peak was 1.7 times Authelia’s (1,092.0 against 626.3 MiB). The server container alone (563.4 MiB) is about 9.4 times Authelia’s whole stack. Latency and CPU are valid for the lab host only.
• Authelia’s idle figure is for an instance nobody had logged in to. The lab logs in only after the idle window. In two single-run development tests on another host (not published, recorded in lab/apps/authelia/test.yaml), two logins before the idle window raised Authelia’s idle from 62 to 160 MiB. Authelia’s password guide describes this: Go releases the hash memory, but “the operating system may not reclaim the memory until a later time”, which “may cause the appearance of more memory being in use than Authelia is actually actively using”. Plan for the load peak, not the idle figure, once people log in.
• authentik’s idle range is wide and comes from the server. The server idled at 563.4, 464.9 and 681.8 MiB in the three runs, each flat inside its own idle window. We did not find why.
• PostgreSQL’s 77 MiB is mostly not heap. The cgroup memory.stat at idle showed 26.8 MiB anonymous and 120.0 MiB of file-backed memory, which includes 37.5 MiB of shared memory. Of that file-backed part, 82.5 MiB was inactive page cache, which the 77 MiB working-set figure already leaves out. The server and worker were almost all anonymous (547.9 of 563.4 and 288.6 of 301.2 MiB). We did not run authentik under a memory limit.
• Startup. authentik was healthy after 103.6 s. The lab’s notes attribute that to the database migrations of a first start (we did not time them separately), and its worker applies the default flows after that (the lab’s setup step took about 36 s more). Authelia was healthy after 1.2 s. Our settle rule waits at least 120 s after setup, and both stacks settled within about 2 s of it.

Authelia’s peak: what the data shows and what we infer

• Measured: the peak is anonymous memory. At the sample that set each run’s peak, file cache was 0.3 to 0.4 MiB, under 0.1% of anonymous plus file memory (peak_memory_stat in the result file). The peak is heap, not page cache.
• Measured: the window is short. The load lasted about 7 s and docker stats took 5 samples per run, so each peak is the highest of 5 readings and the three runs spread widely (497.8, 626.3 and 657.0 MiB). Treat 657.0 MiB as the reading to size for, not as a stable figure.
• Measured: it did not always fall back. The last sample, about 2 s after the load ended, read 68.1, 588.9 and 656.8 MiB (idle before the load: 57.8, 60.1 and 60.5). We did not sample longer, so we do not know when memory comes back down.
• Inferred, not proven: four concurrent Argon2 hashes plus Go runtime headroom. Each login hashes with 64 MiB of memory, and the script held 4 logins in flight, which is 256 MiB. Peak minus idle was 440, 566 and 597 MiB, 1.7 to 2.3 times that. The extra is plausibly memory that Go has freed or not yet collected and the operating system has not taken back, which is what Authelia’s password guide describes. The data does not separate the hashes from that effect, and the memory reading (taken 0.1 s after each docker stats sample) does not match the stats sample for sample.

authentik’s login time: what the data shows and what we infer

• Measured: the stack used nearly all of both cores. During the 103 s of logins the three containers together averaged 191 to 192% of the 200% the host has (median of three runs, from docker stats samples, so approximate): PostgreSQL 103%, server 59%, worker 29%. The check phase was as busy: 185 to 186%, with the server at 91% and PostgreSQL at 84%. The load script ran on the same two vCPUs and is not in these figures.
• Measured: about 3.3 CPU-seconds per login in authentik, about 0.16 in Authelia. That is CPU percent times the length of the login phase, divided by 60 logins. For authentik it came out at 3.29 to 3.33 in the three runs: PostgreSQL about 1.8, server about 1.0, worker about 0.5. PostgreSQL used most of it, 54%. For Authelia we have only 3 samples inside the 6 s login phase per run (157 to 167%), so 0.16 is a rough figure. Per check authentik used about 0.026 CPU-seconds in total (server 0.013, PostgreSQL 0.012).
• Measured, but only arithmetic: latency matches throughput. The script keeps 4 logins in flight, so mean latency must be 4 divided by logins per second, and it was within 3% for both apps (authentik 4 / 0.58 = 6.9 s against a measured mean of 6.8 s). This follows from how the load works. It does not say what the time was spent on.
• Inferred: the CPU set the pace, so the 6.8 s includes waiting for CPU. With 96% of the host’s CPU in use while 4 logins were in flight, more concurrency could not have raised the throughput, and each login queued behind the others for part of its time. How much is queueing we did not measure. A login alone would still need about 3.3 CPU-seconds, which on two cores is at least about 1.7 s if its work spread perfectly over both (also inferred: CPU per login may differ when the host is idle). We did not time a login alone.
• Inferred: the hash is part of the cost, not all of it. PBKDF2 at 1,000,000 iterations burns CPU, but the server container’s whole share, which includes the hash if it runs there (we did not trace which process hashes), was about 1.0 CPU-second per login for 9 requests. The largest share went to PostgreSQL, which we did not profile. A candidate is that authentik moved caching, the embedded outpost’s session store and WebSocket messages into PostgreSQL in 2025.10, after moving tasks there in 2025.8, with roughly 50% more database connections (2025.10 release notes). We did not test that.

Features compared (researched)

We did not test this table. Each row is Researched from the project’s own documentation or source, read Oct 20, 2026. The lab used only the forward-auth path, with one user and a password.

Not tested in our lab: every row above, apart from the hash algorithms and the forward-auth path, which the result files record. We did not start an OIDC client, a SAML service provider, an LDAP outpost, a second factor, a recovery flow or an Enterprise license, and we did not click through either interface.

When to pick Authelia

• RAM is the limit. One container, 60.1 MiB idle and 657.0 MiB at the highest peak in any run, against 942.0 and 1,110.3 MiB for authentik. By our sizing rule that is the 1 GB tier, with 38 MiB to spare under the line. That is thin: see the sizing section before you choose 1 GB.
• A proxy asks it a yes or no for each request. In the lab a check took 2.05 ms at the median with 8 in flight, 3,290 per second, against 95.4 ms and 72.6 per second for authentik, on the same CPU model. Both calls are the forward-auth check, but the session stores differ and the script may have been Authelia’s limit (see the callout above), so read it as a lab-host result, not a ranking.
• You are happy to keep settings in files. There is no admin interface (researched), and sessions sit in memory by default; the docs “highly recommend” Redis for production (session provider docs, read Oct 20, 2026). We did not restart it to see what a restart does to sessions.
• OIDC for your apps is enough, and you accept that Authelia labels it a beta (researched).

What it cost in our runs: the load peak was 10 times its idle (626.3 against 60.1 MiB) in a 7 s window we sampled 5 times. Features it lacks, per the docs (researched, not tested): SAML, an LDAP server and an administrator interface.

When to pick authentik

• You need SAML, an LDAP server for other apps, or an admin web interface (researched, not tested). Authelia offers none of the three (docs read Oct 20, 2026).
• You have 2 GB and 2 CPU cores to give it, with a proxy and little else on the box. By our sizing rule it needs 2 GB, and its own install page asks for 2 CPU cores and 2 GB of RAM (researched).
• You want self-service flows such as recovery and enrollment built from stages (researched, not tested).
• You can accept a slower login and check path on a small box. On 2 vCPU it logged in at 0.58 per second with 4 in flight and checked at 72.6 per second with 8 in flight, with the CPU saturated in both phases. A larger host would change that, and we did not test one.

What it cost in our runs: 942.0 MiB idle, 103.6 s to become healthy on a fresh install, 498.6 MB of images to download (1,604.0 MB unpacked), and a server container whose idle RAM ranged from 464.9 to 681.8 MiB between runs. Enterprise features need a paid license, but the protocols listed in the table are in the free edition (researched).

How much RAM each needs

By our sizing rule (how we size) the figure is the highest reading of any run (load peak or startup peak), times 1.5, rounded up to 1, 2, 4, 8, 16 or 32 GB. The extra half is the rule’s allowance for the operating system, Docker, file cache and spikes our sampling missed.

• Authelia: the rule gives 1 GB, with almost no room left, so we would only use 1 GB for a box that runs little else. The 657.0 MiB is the highest of 5 samples in a 7 s burst of 4 simultaneous logins. The three runs ranged from 497.8 to 657.0 MiB, and in two of the three, memory had not come back down 2 s after the load ended. After the rule’s allowance, 38 MiB is all that is left under 1 GB for a reverse proxy and anything else on the box. Two things could move the real need either way, and we tested neither. Authelia’s password guide says freed hash memory can stay counted until the system is under memory pressure, so part of the 657 MiB may be reclaimable. Fewer simultaneous logins plausibly mean a lower peak, since each hash takes 64 MiB. The Authelia pages we read (the file backend and the password guide) do not mention a Go memory limit; Go documents GOMEMLIMIT as a soft limit that “makes no guarantees” (Go GC guide), and we did not try it. Our opinion, tied to those numbers: pick 2 GB if the same box runs a proxy and other apps. We did not test a 1 GB host or a container memory limit.
• authentik: 2 GB is the floor. Its idle median alone was 942.0 MiB and one run idled at 1,063.1 MiB, so 1 GB does not fit. The rule gives 2 GB, which is also what its install page asks for along with 2 CPU cores. Our 2-vCPU host was 96% busy during the login load, so check that a 2 GB plan has 2 vCPUs. With 383 MiB under the tier line, 2 GB suits authentik plus a proxy, not much more.
• The peak depends on how many logins land together. Authelia’s peak came from 4 hashes in flight and we did not vary that number. More simultaneous logins plausibly mean a higher peak, which we did not test.

Migration notes

Not run in our lab: we did not move users or applications between the two. The lab did find different stored password hashes (Authelia: Argon2id; authentik: PBKDF2-SHA256 with 1,000,000 iterations), so do not assume a stored hash moves across unchanged; plan for password resets or re-enrollment. A cautious pattern, our advice and not a tested procedure: run the new one beside the old on a separate host name, move one application at a time, and keep the old one until every application works.

Compose files

The two files below are the ones the lab ran, on the pinned versions. Neither has TLS or a reverse proxy, and both need one in production (below). Each reads secrets from a .env file next to it, and Compose refuses to start without them. The lab’s secrets are public, so the published .env files have those lines commented out: uncomment each and set your own value, as the comments in the file explain.

What is lab-only. For Authelia: the domain example.com (portal auth.example.com, protected site app.example.com), the single user lab-user, the one_factor rule for app.example.com, the file notifier (password-reset codes are written to a file, not emailed), the in-memory session provider (no Redis) and SQLite. The compose file publishes port 9091 on 127.0.0.1 only. For authentik: the admin email in .env, and everything the lab’s setup step did through the API, which is not in the compose file: it created a forward-auth proxy provider and an application for https://app.example.com and attached them to the embedded outpost. The compose file alone starts an empty authentik. It publishes ports 9000 (HTTP) and 9443 (HTTPS) on all interfaces, so firewall them or bind them to localhost behind your proxy; the localhost change was not run in our lab. The worker mounts the Docker socket, as the official file does; authentik’s install guide says the mount is for deploying outposts automatically, carries security risks, and can be removed if you deploy outposts by hand.

The authentik file is the official 2026.8 file with three changes: PostgreSQL pinned to 16.15-alpine, the ./data, ./certs and ./custom-templates folders turned into named volumes, and first-start values for the admin account in .env (optional, and commented out in the published file), so no browser is needed on the first start. authentik has used no Redis since 2025.10, so there is no Redis service.

authentik 2026.8.4

# Verified compose for authentik, tested 2026-10-20 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: AMD EPYC 7763 64-Core Processor, 2 vCPU, 7.8 GiB RAM, x86_64, Docker 28.0.4.
# Floating image tags below were replaced by the version resolved at test time;
# the registry digest is in the comment on each image line.
# Measurements: authentik.json (schema 3).
# Companion env file: authentik.env (save it as .env next to this file).
# Secrets are not published: the lab's values are public. In authentik.env:
#   PG_PASS is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHENTIK_SECRET_KEY is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHENTIK_BOOTSTRAP_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHENTIK_BOOTSTRAP_TOKEN is commented out. Uncomment it and set your own value (the comment above it explains how).

# authentik 2026.8.4 (identity provider and SSO): PostgreSQL, the server and the worker. No Redis.
# This is the official compose file for 2026.8 (https://docs.goauthentik.io/compose.yml, which pins 2026.8.4 as the default of
# AUTHENTIK_TAG; install guide https://docs.goauthentik.io/install-config/install/docker-compose/), with these differences, all marked below:
#   - PostgreSQL is pinned to 16.15-alpine (the official file says 16-alpine, which today is the same image);
#   - ./data, ./certs and ./custom-templates are named volumes here (the official file bind-mounts folders next to the compose file);
#   - the .env file has first-start values for the admin account (AUTHENTIK_BOOTSTRAP_*), so the first start needs no browser.
# Redis: authentik "no longer uses Redis at all" since 2025.10 (https://docs.goauthentik.io/releases/2025.10/), so there is no redis service.
# There is no TLS and no reverse proxy in this file. Put one in front before you expose it.
name: authentik

services:
  postgresql:
    env_file:
      - .env
    environment:
      POSTGRES_DB: ${PG_DB:-authentik}
      POSTGRES_PASSWORD: ${PG_PASS:?database password required}
      POSTGRES_USER: ${PG_USER:-authentik}
    healthcheck:
      interval: 30s
      retries: 5
      start_period: 20s
      test:
        - CMD-SHELL
        - pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}
      timeout: 5s
    # Official file: postgres:16-alpine (a floating tag). 16.15-alpine is the same image today (same digest), pinned so a re-test uses the same PostgreSQL.
    image: docker.io/library/postgres:16.15-alpine  # sha256:721873c34ceb9f8d8fc265984940dc982404c105f19ad51be9fdc5970a6080ea  (version 16.15, from exec)
    restart: unless-stopped
    volumes:
      - database:/var/lib/postgresql/data

  server:
    command: server
    depends_on:
      postgresql:
        condition: service_healthy
    env_file:
      - .env
    environment:
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
    image: ghcr.io/goauthentik/server:2026.8.4  # sha256:e7226ae116dac5aa0a5643803e735b010038f492c401e08e16b3bf1ac54c090c  (version 2026.8.4, from exec)
    ports:
      - ${COMPOSE_PORT_HTTP:-9000}:9000
      - ${COMPOSE_PORT_HTTPS:-9443}:9443
    restart: unless-stopped
    shm_size: 512mb
    volumes:
      # Official file: ./data:/data and ./custom-templates:/templates (folders next to the compose file).
      - data:/data
      - custom-templates:/templates

  worker:
    command: worker
    depends_on:
      postgresql:
        condition: service_healthy
    env_file:
      - .env
    environment:
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
    image: ghcr.io/goauthentik/server:2026.8.4  # sha256:e7226ae116dac5aa0a5643803e735b010038f492c401e08e16b3bf1ac54c090c  (version 2026.8.4, from exec)
    restart: unless-stopped
    shm_size: 512mb
    user: root
    volumes:
      # Lets the worker manage Docker outposts. The install guide says to remove this mount (or put a Docker socket proxy
      # in front of it) if you do not want authentik to control Docker.
      - /var/run/docker.sock:/var/run/docker.sock
      # Official file: ./data, ./certs and ./custom-templates.
      - data:/data
      - certs:/certs
      - custom-templates:/templates

volumes:
  database:
    driver: local
  data:
  certs:
  custom-templates:

# PostgreSQL password. Choose your own; the stack does not start without it (the compose file says: database password required).
# Generate one with:  openssl rand -base64 36 | tr -d '\n'   (PostgreSQL does not support passwords longer than 99 characters)
# PG_PASS=

# authentik secret key. Choose your own; the stack does not start without it. Do not change it after the first start: it signs sessions and encrypts stored values.
# A placeholder would be a known key, so the lab's value is not published and this line is commented out.
# Generate one with:  openssl rand -base64 60 | tr -d '\n'
# AUTHENTIK_SECRET_KEY=

# Optional: the password of the default admin user akadmin, read on the FIRST start only (https://docs.goauthentik.io/install-config/automated-install/).
# Leave the three AUTHENTIK_BOOTSTRAP_* lines out and authentik asks for the password in the browser instead, at http://<host>:9000/if/flow/initial-setup/.
# The lab's value is public, so this line is commented out. Choose your own if you want a non-interactive start.
# AUTHENTIK_BOOTSTRAP_PASSWORD=
# Optional: an API token for akadmin, created on the first start only. The value is the token itself, so keep it secret. Choose your own long random string.
# AUTHENTIK_BOOTSTRAP_TOKEN=
AUTHENTIK_BOOTSTRAP_EMAIL=akadmin@selfhostbench.test

Authelia 4.39.28

# Verified compose for Authelia, tested 2026-10-20 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: AMD EPYC 7763 64-Core Processor, 2 vCPU, 7.8 GiB RAM, x86_64, Docker 28.0.4.
# Floating image tags below were replaced by the version resolved at test time;
# the registry digest is in the comment on each image line.
# Measurements: authelia.json (schema 3).
# Companion env file: authelia.env (save it as .env next to this file).
# Secrets are not published: the lab's values are public. In authelia.env:
#   AUTHELIA_USER_PASSWORD_HASH is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHELIA_IDENTITY_VALIDATION_RESET_PASSWORD_JWT_SECRET is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHELIA_SESSION_SECRET is commented out. Uncomment it and set your own value (the comment above it explains how).
#   AUTHELIA_STORAGE_ENCRYPTION_KEY is commented out. Uncomment it and set your own value (the comment above it explains how).

# Authelia 4.39.28 (authentication and authorization server for a reverse proxy): ONE container, SQLite, no Redis.
# The minimal setup for a small self-hoster, from the Authelia docs:
#   - users in a YAML file (authentication_backend.file),
#   - SQLite storage (storage.local),
#   - the file notifier (notifier.filesystem: password-reset codes are written to a file instead of e-mailed),
#   - the default in-memory session provider (session.redis is not configured).
# Docs: https://www.authelia.com/configuration/first-factor/file/ , https://www.authelia.com/configuration/storage/sqlite/ ,
#       https://www.authelia.com/configuration/notifications/file/ , https://www.authelia.com/configuration/session/introduction/
# The configuration and the users file are written inline under `configs:` (Compose 2.23.1 or newer), so there is nothing to create next to this file.
# Authelia has to be served over HTTPS ("This is not optional even for testing"). It does not do TLS here: put a reverse proxy that does in front of it
# (Caddy, Traefik, nginx), and point the proxy's forward-auth at http://authelia:9091/api/authz/forward-auth. No proxy is in this file.
# Replace example.com below with your own domain. Authelia and every protected site must share it: a session cookie is set for ONE domain.
name: authelia

services:
  authelia:
    image: authelia/authelia:4.39.28  # sha256:bd97cff4fcbf715b5ff1f9ae286afbe6033afce385302520b0368122d43a6f54  (version 4.39.28, from exec)
    restart: unless-stopped
    environment:
      # Secrets come from the .env file (Authelia reads AUTHELIA_<KEY> variables). The docs' own example uses Docker secrets and *_FILE variables instead.
      AUTHELIA_IDENTITY_VALIDATION_RESET_PASSWORD_JWT_SECRET: "${AUTHELIA_IDENTITY_VALIDATION_RESET_PASSWORD_JWT_SECRET:?set it in .env}"
      AUTHELIA_SESSION_SECRET: "${AUTHELIA_SESSION_SECRET:?set it in .env}"
      AUTHELIA_STORAGE_ENCRYPTION_KEY: "${AUTHELIA_STORAGE_ENCRYPTION_KEY:?set it in .env}"
    volumes:
      # SQLite database (db.sqlite3) and the notification file. Back this up.
      - authelia-config:/config
    configs:
      - source: authelia_configuration
        target: /config/configuration.yml
      - source: authelia_users
        target: /config/users_database.yml
    ports:
      # Localhost only. The reverse proxy on the host sends traffic here.
      - "127.0.0.1:9091:9091"
    # The image defines its own healthcheck (wget on /api/health every 30 s).

configs:
  authelia_configuration:
    content: |
      # The secrets (jwt_secret, session secret, storage encryption key) are not in this file: Authelia reads them from the
      # AUTHELIA_* environment variables above.
      server:
        address: 'tcp://:9091/'
        endpoints:
          authz:
            # The endpoint your reverse proxy calls for every request. Caddy and Traefik use forward-auth; nginx uses auth-request.
            forward-auth:
              implementation: 'ForwardAuth'
      log:
        level: 'info'
      authentication_backend:
        file:
          path: '/config/users_database.yml'
          # Password hashing is the default: Argon2id, 3 iterations, 64 MiB of memory, parallelism 4 (every login uses 64 MiB briefly).
      access_control:
        default_policy: 'deny'
        rules:
          - domain: 'app.example.com'
            policy: 'one_factor'
      session:
        cookies:
          - name: 'authelia_session'
            domain: 'example.com'
            authelia_url: 'https://auth.example.com'
            default_redirection_url: 'https://app.example.com'
      storage:
        local:
          path: '/config/db.sqlite3'
      notifier:
        filesystem:
          filename: '/config/notification.txt'
  authelia_users:
    content: |
      users:
        lab-user:
          disabled: false
          displayname: 'Lab User'
          # Argon2id hash from .env (a new one: docker run --rm -it authelia/authelia:4.39.28 authelia crypto hash generate argon2).
          password: "${AUTHELIA_USER_PASSWORD_HASH:?set it in .env}"
          email: 'lab-user@example.com'
          groups: []

volumes:
  authelia-config:

# Argon2id hash of the user's password. Authelia never stores the password. A placeholder is not a valid hash and the stack would not start, so this line is commented out and the compose file stops until you set it.
# Make your own (it asks for the password twice):  docker run --rm -it authelia/authelia:4.39.28 authelia crypto hash generate argon2
# Copy the part after 'Digest: ' and keep the single quotes: the hash contains $ signs, which Compose would otherwise read as variables.
# AUTHELIA_USER_PASSWORD_HASH=

# Three random secrets; the stack does not start without them. The lab's values are public, and Authelia would accept a placeholder as a real (known) secret,
# so these lines are commented out. Generate each with:  docker run --rm authelia/authelia:4.39.28 authelia crypto rand --length 64 --charset alphanumeric
# Signs the password-reset links.
# AUTHELIA_IDENTITY_VALIDATION_RESET_PASSWORD_JWT_SECRET=
# Encrypts the session data. It is only used when the session is stored in Redis, but Authelia refuses to start without it. Generate your own (see above).
# AUTHELIA_SESSION_SECRET=
# Encrypts the sensitive columns of the SQLite database (at least 20 characters). Do not lose it, and do not change it later without the CLI (authelia storage encryption change-key). Generate your own (see above).
# AUTHELIA_STORAGE_ENCRYPTION_KEY=

In production: a proxy with TLS

Not run in our lab. Both apps expect a reverse proxy in front. Point the proxy’s forward-auth at http://authelia:9091/api/authz/forward-auth for Authelia (the endpoint our script called) or at the embedded outpost’s /outpost.goauthentik.io/auth/traefik path for authentik. The vendors’ own pages, which we read but did not run, are Authelia with Caddy, Authelia with Traefik, authentik with Caddy and authentik with Traefik. The Compose side of putting Caddy in front of a stack, tested with Vaultwarden, is in the Vaultwarden Docker Compose guide.

What we did not test

• TLS and any reverse proxy. The script played the proxy over HTTP. Both apps need a proxy with TLS in production (Authelia’s docs say HTTPS “is not optional even for testing”), and the proxy adds RAM this page did not measure.
• OIDC and SAML clients, LDAP, RADIUS, second factors, mail, recovery flows. Each adds work; none ran.
• More than one user, and concurrency other than 4 logins and 8 checks. A single login on an idle stack was not timed. Authelia’s sessions sit in memory by default and authentik’s data sits in PostgreSQL; we did not measure either with more users, sessions or a bigger database.
• Memory limits and a 1 GB host.
• Redis or Valkey for Authelia sessions, and a database server other than SQLite. The docs highly recommend Redis in production.
• A separate authentik proxy outpost container. The forward-auth endpoint ran inside the server container, so its RAM is in the server’s figure.
• The cost of a password hash alone. We did not time the hashes outside the apps.
• Long runs. Each stack ran for a few minutes after settling. Memory growth over days is unknown.
• Other CPUs and Arm. One x86-64 runner type, AMD EPYC 7763.
• Upgrades, backups and restores of either stack.

Related

• Other comparisons measured the same way: Restic vs Borg vs Kopia and AdGuard Home vs Pi-hole v6.
• HTTPS and a reverse proxy in front of a Compose stack: the Vaultwarden Docker Compose guide and the Home Assistant Docker Compose guide.
• How the lab measures RAM, CPU and image sizes, and how it sizes: methodology. More plumbing pages: the Stack hub.