[{"data":1,"prerenderedAt":216},["ShallowReactive",2],{"seo-verification":3,"blog-self-host-authelia-on-a-vps-mfa-and-sso-for-your-whole-stack-ma-en":6,"promo-bar-likely":215},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-self-host-authelia-on-a-vps-mfa-and-sso-for-your-whole-stack-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":35,"sections":36,"ctaTitle":149,"ctaBody":150,"ctaButton":151,"ctaUrl":152,"relatedPosts":153},162,"self-host-authelia-on-a-vps-mfa-and-sso-for-your-whole-stack",{"fr":12,"en":10,"ar":13,"es":14},"self-host-authelia-vps","استضافة-authelia-على-vps-مصادقة-ثنائية-ودخول-موحد-لمنظومتك","alojar-authelia-en-un-vps","Self-hosting Authelia on a VPS: MFA and SSO for your entire stack","Deploy Authelia on a VPS with Docker Compose: TOTP, WebAuthn\u002Fpasskey, OIDC, LLDAP migration, Prometheus monitoring, and comparison with Authentik.",10,4,false,"2026-07-04T00:00:00+00:00","2026-09-24T12:27:51+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fself-host-authelia-vps-poster.svg",{"categorySlug":27,"appSlug":34},"authelia","Authelia is an open-source authentication gateway written in Go that sits in front of your self-hosted services via your reverse proxy. In a single lightweight container (~30 MB), it centralizes authentication, enforces MFA, and can act as an OIDC provider for true SSO across your entire stack. This guide covers the full installation, group-based access rules, available MFA methods — including WebAuthn passkeys — migration to LLDAP, smooth upgrades, and monitoring.",[37,41,53,56,87,91,94,97,100,103,106,143,146],{"type":38,"title":39,"body":40},"h2","Why an authentication gateway in the reverse proxy","Without a centralized gateway, each service manages its own login: Grafana has its own user database, Nextcloud has its own, Portainer has its own. The result: different passwords everywhere, no consistent MFA, and a multiplied attack surface. Authelia solves this by intercepting the HTTP flow: your reverse proxy (Nginx, Traefik, Caddy) submits each request to it before relaying it, and Authelia decides — based on identity, group, requested path, and required MFA level — whether the request should pass. The protected application only sees an authenticated request with injected identity headers (`Remote-User`, `Remote-Groups`). It doesn't need to manage authentication itself.",{"type":42,"title":43,"items":44},"ul","What self-hosted Authelia gives you",[45,46,47,48,49,50,51,52],"Centralized authentication for all your services without modifying their code","Native MFA: TOTP (Google Authenticator, Aegis), WebAuthn\u002Fpasskey (hardware keys, Touch ID, Windows Hello), Duo","OIDC provider in production since v4.34: your OIDC-compatible apps delegate auth to Authelia","Granular access control by domain, path, user group, and authentication level","Native integration with Traefik (forwardAuth), Nginx (auth_request), Caddy (forward_auth)","LDAP\u002FActive Directory support for team management, compatible with LLDAP","Single Go binary (~30 MB), lightweight Docker image, low memory footprint","Structured JSON logs and Prometheus metrics for observability",{"type":38,"title":54,"body":55},"Prerequisites","Before deploying Authelia, verify that your environment is ready. You need a Linux VPS with Docker and Docker Compose installed, an existing reverse proxy (Traefik v2\u002Fv3 or Nginx), a domain name with a valid TLS certificate (Let's Encrypt recommended), and a Redis instance accessible by Authelia to store sessions (required in production for persistence and scalability). For user storage, you can start with a local YAML file or connect an LDAP server like LLDAP. Authelia also requires a JWT key, a session encryption key, and an OIDC secret if you enable that mode: generate them with `openssl rand -hex 32`.",{"type":57,"title":58,"steps":59},"steps","Deploy Authelia with Docker Compose",[60,63,66,69,72,75,78,81,84],{"title":61,"body":62},"Create the directory structure","Create `\u002Fopt\u002Fauthelia\u002Fconfig\u002F` for configuration files and `\u002Fopt\u002Fauthelia\u002Fdata\u002F` for SQLite storage and keys. Set appropriate permissions: `mkdir -p \u002Fopt\u002Fauthelia\u002F{config,data} && chown -R 1000:1000 \u002Fopt\u002Fauthelia`.",{"title":64,"body":65},"Write the configuration.yml file","Create `\u002Fopt\u002Fauthelia\u002Fconfig\u002Fconfiguration.yml`. Define `default_redirection_url`, `jwt_secret`, `session.secret`, `storage.encryption_key`, configure the authentication backend (file or LDAP), Redis for sessions, and the default access policy (`deny` recommended).",{"title":67,"body":68},"Create the users_database.yml file (file backend)","For a quick start, create `\u002Fopt\u002Fauthelia\u002Fconfig\u002Fusers_database.yml` with your users. Passwords must be hashed with Argon2id: `docker run --rm authelia\u002Fauthelia:latest authelia crypto hash generate argon2 --password 'YourPassword'`. Copy the generated hash into the file.",{"title":70,"body":71},"Configure Redis for sessions","Add Redis to your `docker-compose.yml`. In `configuration.yml`, set `session.redis.host: redis` and `session.redis.port: 6379`. Redis is essential for sessions to survive Authelia restarts.",{"title":73,"body":74},"Write the docker-compose.yml","Define the `authelia`, `redis` services, and if you use Traefik, add the appropriate labels. Mount `\u002Fopt\u002Fauthelia\u002Fconfig` read-only and `\u002Fopt\u002Fauthelia\u002Fdata` read-write. Expose port 9091 internally, never directly to the Internet.",{"title":76,"body":77},"Configure Traefik with forwardAuth","Create a Traefik middleware pointing to `http:\u002F\u002Fauthelia:9091\u002Fapi\u002Fauthz\u002Fforward-auth`. Apply this middleware to routers of services to protect via the label `traefik.http.routers.\u003Cservice>.middlewares: authelia@docker`. For Nginx, use `auth_request \u002Fauthelia` with the appropriate `proxy_pass` directives.",{"title":79,"body":80},"Configure the session domain","In `configuration.yml`, set `session.domain` to your root domain (e.g., `mydomain.com`) so the cookie is shared between subdomains. This is the most common cause of redirect loops: if `session.domain` doesn't match the domain of the protected service, the cookie is never sent back.",{"title":82,"body":83},"Start and validate","Start with `docker compose up -d`. Check logs: `docker compose logs -f authelia`. Access `https:\u002F\u002Fauth.mydomain.com` to see the login portal. Test by accessing a protected service: you should be redirected to the portal, then sent back to the service after authentication.",{"title":85,"body":86},"Enable the OIDC provider (optional)","Since v4.34, the OIDC provider is production-ready. Add the `identity_providers.oidc` section to your configuration with your clients (Nextcloud, Grafana, Gitea…). Each client has an `id`, a `secret` (hashed with Argon2id), and its allowed `redirect_uris`. Your OAuth2-compatible apps can then fully delegate authentication to Authelia.",{"type":88,"title":89,"body":90},"tip","Use Authelia as an OIDC provider for true SSO","OIDC provider mode turns Authelia into true SSO: the user logs in once on the Authelia portal, and all applications configured as OIDC clients retrieve the identity without asking for a password again. Nextcloud, Grafana, Gitea, Portainer, Outline… all support OIDC. Configure each client with `client_id`, `client_secret`, and point the discovery URL to `https:\u002F\u002Fauth.mydomain.com\u002F.well-known\u002Fopenid-configuration`. The `groups` scope allows transmitting Authelia groups to client applications for role management.",{"type":38,"title":92,"body":93},"Access control rules: concrete examples","The `access_control` section is the heart of Authelia's logic. Since v4.37, policies have been reworked. Here are representative examples. For public access without auth: `{domain: 'status.mydomain.com', policy: bypass}`. For strong MFA access restricted to admins: `{domain: 'portainer.mydomain.com', subject: 'group:admins', policy: two_factor}`. For an API path without auth (webhooks): `{domain: 'n8n.mydomain.com', resources: ['^\u002Fwebhook\u002F.*'], policy: bypass}`. For the rest of N8N with simple MFA: `{domain: 'n8n.mydomain.com', policy: one_factor}`. The `default_policy: deny` rule ensures that anything not explicitly listed is blocked. Rule order matters: the first matching rule applies. The `subject` field accepts `user:alice`, `group:admins`, or a combined list.",{"type":38,"title":95,"body":96},"MFA: TOTP, WebAuthn\u002Fpasskey and Duo","Authelia supports three second-factor methods, each with its advantages.\n\n**TOTP** (Time-based One-Time Password) is the most universal method: the user scans a QR code with an app like Aegis (Android), Raivo (iOS), or Bitwarden Authenticator. A 6-digit code changes every 30 seconds. Simple to deploy, compatible with all devices, but vulnerable to phishing if the code is intercepted in transit.\n\n**WebAuthn\u002Fpasskey** is the most robust method, natively supported by Authelia since v4.36. The user registers a hardware key (YubiKey, Nitrokey) or a platform authenticator (Touch ID on macOS, Windows Hello, Face ID on iOS). Public-key cryptography makes phishing impossible: the private key never leaves the device. Authelia implements the full WebAuthn Level 2 spec, which includes synchronized passkeys (via iCloud Keychain or Google Password Manager) in addition to hardware keys.\n\n**Duo** delegates the second factor to the Duo Security cloud service: mobile push, SMS, or phone call. Convenient for teams already using Duo, but introduces a dependency on a third-party service.\n\nFor most self-hosted stacks, the recommended combination is TOTP as the base method and WebAuthn as the preferred method for users who have a YubiKey or a recent Apple\u002FWindows device.",{"type":38,"title":98,"body":99},"Migrating to LLDAP: team management","The file backend (`users_database.yml`) works for one user or a small household, but becomes difficult to manage beyond 5-10 users. LLDAP (Light LDAP) is a lightweight LDAP implementation written in Rust, with a simple web interface, that integrates perfectly with Authelia.\n\nDeploy LLDAP by adding its service to your `docker-compose.yml` with the `LLDAP_JWT_SECRET` and `LLDAP_LDAP_BASE_DN` variables (e.g., `dc=mydomain,dc=com`). Create your groups in the LLDAP interface (`admins`, `users`, `devops`…), then modify your `configuration.yml` to switch from the `file` backend to the `ldap` backend: define `authentication_backend.ldap.url`, `base_dn`, `users_filter` (`(&(uid={input})(objectClass=person))`), `groups_filter`, `user` (the LLDAP service account), and `password`.\n\nNote the v4.35 breaking change: the field was called `authentification_backend` (with a typo) before v4.35 and was corrected to `authentication_backend`. Check your configuration if migrating from an earlier version.",{"type":38,"title":101,"body":102},"Updating Authelia: avoiding breaking changes","Authelia follows strict semantic versioning and documents its breaking changes per version. Here are the notable changes to know for clean migrations.\n\n**v4.34**: the OIDC provider goes to production. If you were using it in experimental mode, some options have been renamed.\n\n**v4.35**: correction of the typo `authentification_backend` → `authentication_backend`. Any configuration using the old name must be updated before upgrading to v4.35+, otherwise Authelia refuses to start with a configuration validation error.\n\n**v4.37**: rework of `access_control` policies. Rule syntax has evolved to be more explicit. Check the official changelog before upgrading from v4.36 or earlier.\n\n**v4.38.x** (current version): stabilization, no major breaking change since v4.37.\n\nRecommended update procedure: (1) read the changelog from your current version; (2) back up `\u002Fopt\u002Fauthelia\u002Fconfig\u002F` and `\u002Fopt\u002Fauthelia\u002Fdata\u002F`; (3) test the new configuration with `docker run --rm -v \u002Fopt\u002Fauthelia\u002Fconfig:\u002Fconfig authelia\u002Fauthelia:4.38.x authelia validate-config` before restarting; (4) update the tag in `docker-compose.yml` and restart. The `validate-config` command catches schema errors before deployment.",{"type":38,"title":104,"body":105},"Monitoring: logs and Prometheus metrics","Authelia exposes its Prometheus metrics on `\u002Fmetrics` (configurable port, default 9959). Enable them in `configuration.yml` with `telemetry.metrics.enabled: true` and `telemetry.metrics.address: 'tcp:\u002F\u002F0.0.0.0:9959'`. Don't expose this port publicly: only expose it to your internal monitoring stack.\n\nKey metrics to monitor: `authelia_authn_requests_total` (total authentication attempts, labeled by success\u002Ffailure), `authelia_authn_duration_seconds` (authentication latency), and underlying Redis metrics for session health.\n\nFor logs, Authelia supports structured JSON format (`log.format: json`) ideal for ingestion into Loki or a SIEM. Set `log.level: info` in production (avoid `debug` which logs full headers). Authentication logs include source IP, username, target service, and result — valuable for detecting brute-force attempts.\n\nIn Grafana, create an alert on an abnormal authentication failure rate (e.g., more than 10 failures in 5 minutes on the same user) to detect dictionary attacks before they succeed.",{"type":107,"title":108,"columns":109,"rows":113},"comparison","Authelia vs Authentik: which one to choose?",[110,111,112],"Criterion","Authelia","Authentik",[114,118,122,126,130,134,137,139],[115,116,117],"Docker footprint","~30 MB (Go binary)","~1.5 GB (Python\u002FDjango + worker)",[119,120,121],"Minimum RAM","~50 MB","~512 MB recommended",[123,124,125],"OIDC provider","Yes, since v4.34","Yes, mature and feature-rich",[127,128,129],"SAML provider","No","Yes",[131,132,133],"Admin interface","YAML configuration only","Full web interface",[135,128,136],"Application proxy","Yes (Authentik tunnels)",[138,128,129],"SCIM provisioning",[140,141,142],"Ideal use case","Lightweight stack, pure reverse proxy, config as code","Full IAM, enterprise SSO, SAML\u002FSCIM needs",{"type":38,"title":144,"body":145},"Troubleshooting common errors","**Infinite redirect loop.** The user is bounced in a loop between the service and the Authelia portal without ever logging in. Most common cause: `session.domain` doesn't match the service's domain. If your service is on `app.mydomain.com` and `session.domain` is `otherdomain.com`, the session cookie is never sent back. Also check that the forwardAuth middleware is properly applied and that `default_redirection_url` points to a valid URL.\n\n**Cookie domain mismatch.** The browser refuses to send the cookie back. Cause: `session.domain` must be the common parent domain (`mydomain.com`), not a subdomain. Verify with DevTools (Application tab > Cookies) that the `authelia_session` cookie has the correct domain.\n\n**Redis unreachable.** Authelia starts but sessions don't persist, or the log shows `Error connecting to Redis`. Verify that the Redis container is on the same Docker network as Authelia, that `host` in `configuration.yml` matches the Docker service name (not `localhost`), and that Redis isn't protected by a password not configured on the Authelia side.\n\n**Invalid configuration on startup.** Since v4.35, the configuration schema is strictly validated. Use `authelia validate-config` before any restart. Most common errors: `authentification_backend` (old typo), wrong YAML indentation, or missing OIDC field (`client_secret` must be hashed with Argon2id since v4.37).\n\n**MFA not prompted despite `two_factor` in rules.** Check that the user has registered a second factor in their profile (`https:\u002F\u002Fauth.mydomain.com`). Without a registered MFA device, Authelia may fall back to `one_factor` depending on your `default_2fa_method` configuration.",{"type":88,"title":147,"body":148},"Final advice: start simple, evolve progressively","First deploy Authelia with the file backend, a single `two_factor` rule for your most exposed services, and TOTP as the MFA method. Once stable, migrate to LLDAP for team management, enable the OIDC provider for SSO, then add WebAuthn for users who have a hardware key or a device supporting passkeys. This progression prevents you from debugging multiple new components simultaneously and lets you validate each layer independently.","Deploy Authelia on your VPS in one click","Add MFA and SSO to your entire self-hosted stack without changing a single app. ServOrbit provisions a ready-to-use Authelia instance — configuration generated, admin user created, reverse proxy integration ready.","Deploy Authelia","\u002Fvps-cloud?template=authelia",[154,173,192],{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":163,"views":164,"isPinned":19,"noindex":19,"publishedAt":165,"updatedAt":166,"category":167,"categories":168,"featuredImage":30,"bgImage":31,"posterImage":170,"relatedSolution":171},131,"self-host-your-password-manager-deploy-vaultwarden-on-vps",{"fr":158,"en":156,"ar":159,"es":160},"deploy-vaultwarden-vps","استضف-مدير-كلمات-المرور-بنفسك-انشر-vaultwarden-على-vps","desplegar-vaultwarden-en-un-vps","Deploy Vaultwarden on a VPS: self-hosted password manager","Self-host Vaultwarden on a VPS: password management, Bitwarden compatibility, team vaults and TOTP, at a fixed monthly cost and under 50 MB of RAM.",15,3,"2026-06-24T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[169],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeploy-vaultwarden-vps-poster.svg",{"categorySlug":27,"appSlug":172},"vaultwarden",{"id":174,"slug":175,"slugs":176,"title":180,"excerpt":181,"readTime":18,"views":182,"isPinned":19,"noindex":19,"publishedAt":183,"updatedAt":184,"category":185,"categories":186,"featuredImage":30,"bgImage":31,"posterImage":188,"relatedSolution":189},108,"securing-your-vps-with-crowdsec",{"fr":177,"en":175,"ar":178,"es":179},"securiser-vps-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","proteger-vps-con-crowdsec","Securing your VPS with CrowdSec","Deploy CrowdSec on your VPS to block attacks thanks to behavioral detection and a shared community blocklist.",2,"2026-03-04T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[187],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":190,"appSlug":191},"cybersecurity-bastion","crowdsec",{"id":193,"slug":194,"slugs":195,"title":199,"excerpt":200,"readTime":18,"views":201,"isPinned":19,"noindex":19,"publishedAt":202,"updatedAt":184,"category":203,"categories":209,"featuredImage":30,"bgImage":31,"posterImage":211,"relatedSolution":212},161,"how-to-self-host-dockge-on-a-vps-visual-docker-compose-manager",{"fr":196,"en":194,"ar":197,"es":198},"self-host-dockge-vps","استضافة-dockge-على-vps-مدير-مرئي-لـ-docker-compose","alojar-dockge-en-un-vps","How to Self-Host Dockge on a VPS: Visual Docker Compose Manager","Deploy Dockge on your VPS: a lightweight open-source visual manager to create, edit and monitor your Docker Compose stacks from a clean web UI, no command line.",1,"2026-07-03T00:00:00+00:00",{"id":204,"name":205,"slug":206,"color":207,"icon":208},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[210],{"id":204,"name":205,"slug":206,"color":207,"icon":208},"\u002Fblog\u002Fcovers\u002Fself-host-dockge-vps-poster.svg",{"categorySlug":213,"appSlug":214},"application-deployment-devops","dockge",true,1794270481263]