Learn Authelia - Pre-Requisite Skills & Environment Setup

#Introduction

Welcome to the Learn Authelia series! This series will take you from zero to ready to deploy a robust authentication & authorization server: starting from pre-requisites and environment setup, history & background, architecture & core concepts, installation, configuration file structure, authentication backends, access control rules, session management, storage backend, TOTP, WebAuthn, Duo Push, password reset & user management, reverse proxy integrations (NGINX, Traefik, Caddy, HAProxy), OpenID Connect provider, brute force protection, security headers, high availability, Kubernetes, monitoring, backup, up to a production checklist, with a total of 31 episodes.

Authelia is an open-source authentication & authorization server that stands in front of your self-hosted applications and answers the most fundamental question in security: who is allowed in, and through which door. For homelab, VPS, or NAS owners, the problem is real — every application has its own login system, its own password, and its own security policies. Authelia unifies all of them behind a single login portal with Single Sign-On (SSO) and Multi-Factor Authentication (MFA). In an era where credential leaks are the most common cause of security incidents, engineers who can secure their own service stack are no longer just a nice-to-have — it's the standard.

Episode 0 is your roadmap. Before diving deeper into Authelia, we need to make sure three things are in place: (1) the basic skills you must master, (2) the software and hardware to prepare, and (3) the lab topology used throughout this series. Don't skip ahead — Authelia is not a tool you install and then forget; it sits in the middle of your network traffic, so a shaky foundation will make the following episodes feel heavy. Let's begin.

#Basic Skills You Must Master

Authelia is not a standalone application. It works together with a reverse proxy, communicates through HTTP headers, and stores state in Redis and a database. You don't need to be a professional network administrator, but the following concepts must be truly understood — not just memorized terms.

#The Reverse Proxy Concept

A reverse proxy is a server that stands in front of your applications and forwards client requests to the right application. Think of an office building receptionist: all guests enter through one door, the receptionist checks their destination, then directs them to the correct floor — without ever letting guests walk straight into the workspace. NGINX, Traefik, Caddy, and HAProxy are popular reverse proxy examples, and Authelia is designed to sit exactly behind these proxies. This is the concept that most often confuses beginners: Authelia doesn't "become" the entrance — it becomes the guard who makes the decision, while the proxy is the door.

#Authentication vs Authorization

These two terms are often mixed up, even though the difference shapes Authelia's design:

• Authentication — proves who you are (login with username + password). The question is: "Are you really this user?"
• Authorization — decides what you're allowed to do once identity is proven. The question is: "Does this user have access to the admin dashboard?"

Authelia handles both: it authenticates through the portal, then authorizes through access control rules that define who can access which domain. The analogy: authentication is the identity check at the entrance; authorization is the rule of which floors you may enter once your ID has been checked.

#HTTP Headers

HTTP headers are the "metadata envelope" that accompanies every HTTP request and response. Authelia sends user identity to applications through dedicated headers such as Remote-User, Remote-Name, Remote-Email, and Remote-Groups — applications behind it can read who the currently authenticated user is without needing their own login system. You will also deal with the X-Forwarded-* headers (real IP and protocol information) which are important so Authelia knows the request came through a proxy. The ability to read headers is the most valuable debugging skill in this series.

#Docker and Container Basics

Authelia is distributed as an official Docker image, and almost every episode in this series deploys Authelia along with Redis and a database via Docker Compose. You must be comfortable with the basic commands docker compose up, docker compose down, docker ps, and docker logs, plus the concept of volumes for persistent data. If you're still unsure, learn the Learn Docker series first — Authelia doesn't require advanced Docker expertise, but you must understand what containers, images, and volumes are.

#YAML

All Authelia configuration — configuration.yml and users_database.yml — is written in YAML format. YAML is sensitive to spaces and indentation, so "looks the same" does not mean "is the same". The most common error isn't in the logic, but in indentation that's off by one space. Master the three basic YAML structures: key-value, lists, and nested mappings — that's enough to follow this entire series.

#Basic Networking: DNS and Ports

Authelia relies on domains. Every application you protect will have its own subdomain (for example auth.example.com for the Authelia portal, grafana.example.com for Grafana), and DNS that points those subdomains to your server's IP. You should also understand ports — Authelia listens on port 9091 by default. If you've ever managed a VPS, the concepts of DNS records (A, CNAME) and ports should already be familiar.

#Forward Authentication

This is the core concept that will run throughout the entire series. Forward authentication is a pattern where the reverse proxy asks an external service (in this case Authelia) for an authentication decision before forwarding the request to the application. If Authelia answers "OK, this user is legitimate", the proxy forwards the request along with the identity headers; if not, the user is redirected to the login portal. The proxy only forwards the decision — Authelia does the evaluation. Episode 2 will dissect this flow line by line.

#Session Management

After a successful login, Authelia doesn't ask for your password again every time you switch applications — it stores a session (login state) in a cookie and in the session store (usually Redis). The concepts you need to understand: cookie, expiration, and inactivity timeout. Think of a mall parking ticket: once you enter and exit several times in a single day, the attendant only needs to look at the stamp on the ticket, without asking you to fill out a form again.

#Software and Tools to Prepare

Prepare the following tools before continuing to episode 3:

#Minimum Hardware Specifications

Authelia is very lightweight — it's written in Go and runs as a single binary. Here are the comfortable minimum requirements for a lab:

• RAM: 1 GB minimum, 2 GB or more recommended (Redis and the database share the memory too).
• Storage: 5 GB of free space (images, volumes, and logs).
• CPU: dual-core minimum.
• OS: a Linux server (Debian, Ubuntu, Rocky) is highly recommended — exactly like a production environment.
• Network: a stable connection; a public IP is not required, subdomained domains can be pointed to a local network (for example via the hosts file or split-horizon DNS).

#The Official Authelia Image

Authelia is distributed as a Docker image on Docker Hub and GHCR. The official image is authelia/authelia — every episode that deploys Authelia will use it:

docker pull authelia/authelia

This image also contains the authelia binary inside, which we can use to generate secrets, hash passwords, and validate configurations — the docker run --rm authelia/authelia:latest authelia ... pattern will become a daily companion in episodes 4 and 5.

#Designing the Lab Topology

Before closing this episode, let's design the topology we'll build and use throughout the series. A single domain example.com (replace with your own domain) will host the following subdomains:

                        +---------------------+
Browser  ------------->  |  Reverse Proxy      |   (NGINX, port 443)
                        |  auth.example.com    |
                        +----------+----------+
                                   |
                                   v
              +-------------------/---\--------------------+
              |            Authelia (port 9091)             |
              |  verifies session, redirects to portal,     |
              |  evaluates access control rules              |
              +---+----------------+-----------------+------+
                  |                |                 |
                  v                v                 v
             +--------+      +--------+        +-----------+
             | Redis  |      |  DB    |        |  Notifier |
             |session |      |storage |        |  (SMTP)   |
             +--------+      +--------+        +-----------+
 
  Protected applications (forwarded by the proxy after passing verification):
    grafana.example.com    nextcloud.example.com    portainer.example.com

The flow in short: browser → reverse proxy → Authelia checks the session → not logged in? redirect to the auth.example.com portal → login (+ MFA) → session created → proxy forwards the request to the target application. Episode 2 will dissect this flow in detail.

#Closing

In episode 0 you've mapped out three foundations: basic skills (reverse proxy, authentication vs authorization, HTTP headers, Docker, YAML, DNS & ports, forward authentication, and session management), software & hardware (Docker Compose, reverse proxy, Redis, database, SMTP, plus minimum server specifications), and the lab topology that will accompany you throughout this series.

Key takeaways:

• Authelia sits behind the reverse proxy, it doesn't replace it.
• Authentication proves who the user is; authorization decides access rights — Authelia handles both.
• Forward authentication is the core pattern: the proxy asks Authelia, Authelia decides.
• The official Authelia image is authelia/authelia, distributed via Docker Hub and GHCR.
• The whole lab can run on a single machine — Redis, database, and proxy are all allowed to share the same host.

The Learn Authelia series consists of 31 episodes that build on one another. Episode 0 is the first brick. In the next episode, episode 1, we'll step back for a moment to answer a question that's rarely asked but decisive: history, background, and why Authelia is needed — from the problem of "many applications, many login doors" to comparing Authelia with Authentik and Keycloak. See you in episode 1, and happy preparing your authentication lab!