Authelia 4.39.28

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Authelia 4.39.28 on Ubuntu 24.04 as the software version, choose your Region, and select Launch through EC2.

Choose m5.large, your key pair, and a security group as described above. The AMI already carries the 10 GiB state volume. You can make it larger on the launch page.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=authelia}]'

First boot takes a few seconds after the instance is running.

Connect over SSH as the ubuntu user, the default login user on Ubuntu 24.04.

ssh -i <your-key.pem> ubuntu@<public-ip>

Confirm that first boot has finished and that Authelia and nginx are running:

systemctl is-active authelia-firstboot authelia nginx

active active active

Only SSH, HTTP and HTTPS are public. Authelia itself listens on the loopback address only:

sudo ss -tln | grep -E ':(22|80|443|9091) '

LISTEN 0 4096 127.0.0.1:9091 0.0.0.0:* LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 4096 [::]:22 [::]:* LISTEN 0 511 [::]:80 [::]:* LISTEN 0 511 [::]:443 [::]:*

The portal answers its health check through nginx:

curl -sk --resolve auth.authelia.local:443:127.0.0.1 https://auth.authelia.local/api/health; echo

{"status":"OK"}

Read the credentials file as root:

sudo cat /root/authelia-credentials.txt

The file (root only, mode 0600) lists the portal and demo application addresses, the admin administrator user, its per-instance password (shown here as <redacted>) and the SHA-256 fingerprint of this instance's certificate:

authelia.portal_URL=https://auth.authelia.local/ authelia.demo_app_URL=https://secure.authelia.local/ authelia.admin.user=admin authelia.admin.pass=<redacted> authelia.tls.sha256_fingerprint=E1:9C:1F:51:AE:9E:BC:5A:38:A1:48:0C:DD:07:90:34:6B:14:48:DC:8C:E4:79:FF:47:B8:7D:06:06:89:1D:53

Authelia's user database stores the password only as an argon2id hash. Every instance gets its own password.

Authelia serves two names: the portal auth.<domain> and the demo application secure.<domain>. With the demo domain, add one line to your workstation's hosts file so that it can find them. The file is /etc/hosts on Linux and macOS and C:\Windows\System32\drivers\etc\hosts on Windows. Use your instance's public IP address:

<public-ip> auth.authelia.local secure.authelia.local

Requests that use any other name, including the bare IP address, are dropped by design. Skip this step once you have set your own domain (Step 9).

The certificate is self-signed and unique to your instance, so your browser warns about it. Open the certificate details in the browser and check that the SHA-256 fingerprint matches authelia.tls.sha256_fingerprint from Step 4. Continue only if it matches.

Do not add the certificate to your operating system's trust store. For production, replace it with a certificate from a certificate authority (Step 9).

Browse to https://secure.authelia.local/. The demo application is protected, so nginx asks Authelia, and Authelia sends you to the portal to sign in.

Sign in as admin with the password from Step 4.

Authelia returns you to the page you asked for, now served because the session is authorised.

The same session opens every application you protect under the same domain. Your own settings, including second-factor devices, are at https://auth.authelia.local/settings.

The image includes a check that runs the whole flow through nginx on the instance. An anonymous request is sent to the portal, the administrator signs in, the session opens the demo application, and a wrong password is refused. The check passes the password to curl in a root-only temporary file, never on a command line:

sudo /usr/local/sbin/authelia-cred-roundtrip.sh

AUTHELIA_ROUNDTRIP_OK anon=302 admin=200 app=200 wrong=401

An anonymous request to the demo application is redirected to the portal, with the page you wanted as the return address:

curl -sk -o /dev/null -w '%{http_code} %{redirect_url}\n' --resolve secure.authelia.local:443:127.0.0.1 https://secure.authelia.local/

302 https://auth.authelia.local/?rd=https%3A%2F%2Fsecure.authelia.local%2F&rm=GET

Check Authelia's version, the closed features and the default policy:

authelia --version sudo grep -E 'default_policy|disable:|authelia_url' /etc/authelia/configuration.yml

authelia version v4.39.28 disable: true default_policy: 'deny' authelia_url: 'https://auth.authelia.local'

disable: true is authentication_backend.password_reset.disable. Nobody can reset a password from the internet-facing portal. An administrator sets passwords on the instance (Step 11).

The certificate is an end-entity certificate for the two names and cannot sign other certificates:

openssl x509 -in /etc/ssl/authelia/authelia.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = auth.authelia.local, O = sac X509v3 Subject Alternative Name: DNS:auth.authelia.local, DNS:secure.authelia.local X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication

The server refuses TLS 1.0 and 1.1, and a request for a name that the instance does not serve gets no answer:

echo | openssl s_client -tls1_1 -cipher 'DEFAULT@SECLEVEL=0' -connect 127.0.0.1:443 -servername auth.authelia.local 2>&1 | grep -o 'alert protocol version' | head -1 code=$(curl -sk -o /dev/null -w '%{http_code}' --resolve evil.example:443:127.0.0.1 https://evil.example/ || true);
echo "$code"; [ "$code" = 000 ]

alert protocol version 000

The services are blocked from the instance metadata service. The first command shows the systemd rule on each service. The second command makes a metadata request from inside Authelia's own service, as its user, and gets no connection (000):

systemctl show -p IPAddressDeny authelia nginx authelia-firstboot
sudo bash -c 'cg=$(systemctl show -p ControlGroup --value authelia.service); echo $$ > /sys/fs/cgroup$cg/cgroup.procs; setpriv --reuid=authelia --regid=authelia --init-groups curl -s -m 5 -o /dev/null -w "imds from authelia: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token; true' | grep -x 'imds from authelia: 000'

IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 ::ffff:169.254.169.254/128 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 ::ffff:169.254.169.254/128 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 ::ffff:169.254.169.254/128 imds from authelia: 000

SSH accepts keys only. Confirm the effective settings:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|x11forwarding|permitemptypasswords) '

permitrootlogin no passwordauthentication no kbdinteractiveauthentication no x11forwarding no permitemptypasswords no

Choose a domain you control, for example example.com. Create DNS records for auth.example.com (the portal) and secure.example.com (the demo application) that point at the instance's public IP (or an Elastic IP). Then run:

sudo authelia-set-domain example.com

The helper sets the session cookie domain to example.com, the portal to https://auth.example.com/ and the demo application to https://secure.example.com/. It also does the following:

• Re-renders /etc/authelia/configuration.yml from the SecureAnyCloud template. Your previous file is kept as configuration.yml.prev, so run the helper before you customise the configuration, or copy your changes back afterwards.
• Updates the nginx site and the cross-site guard.
• Issues a new self-signed certificate for the new names.
• Restarts Authelia.

Check the result with:

authelia-set-domain --show

domain: authelia.local portal: https://auth.authelia.local/ demo app: https://secure.authelia.local/

The output above shows the demo domain. After the change, it names yours.

To use a certificate from a certificate authority, put the full chain and key at /etc/ssl/authelia/authelia.crt and /etc/ssl/authelia/authelia.key (key mode 0600, owner root). Then reload nginx with sudo systemctl reload nginx. Examples are AWS Certificate Manager on a load balancer in front of the instance, or Let's Encrypt with certbot on the instance.

authelia-set-domain never replaces a certificate that is not SecureAnyCloud's own.

The demo rule asks for one factor so that you can try the flow straight away. To require two factors, change the rule in /etc/authelia/configuration.yml:

access_control: default_policy: 'deny' rules: - domain: 'secure.authelia.local' policy: 'two_factor'

Then restart Authelia with sudo systemctl restart authelia.

At the next sign-in, Authelia offers to register a second factor: a one-time password app such as Google Authenticator or Microsoft Authenticator, a security key or a passkey. You confirm the registration with a one-time code that Authelia "sends" through its notifier.

The image uses the filesystem notifier, because there is no mail server until you configure one. Read the code on the instance:

sudo cat /var/lib/authelia/notification.txt 2>/dev/null || echo 'no notification has been sent yet'

To send these messages by email instead, replace the notifier: section with an smtp: block for your mail service (Amazon SES works well), as described in the Authelia notifier documentation. Then restart Authelia.

Users live in /var/lib/authelia/users_database.yml (file backend, argon2id hashes). To create a password hash, run the generator and type the password at its prompt. The password then never appears on a command line or in your shell history:

sudo -u authelia authelia crypto hash generate argon2

Add the user to the file as a new entry next to admin, with the Digest: value as its password, then restart Authelia:

users: alice: disabled: false displayname: 'Alice' password: '$argon2id$v=19$m=65536,t=3,p=4$...' email: 'alice@example.com' groups: - 'staff'

Signed-in users can change their own password from the portal's settings. To use a directory instead of a file, configure LDAP or Active Directory with authentication_backend.ldap.

Put the application behind nginx on this instance, or on another server that uses this Authelia as its forward-auth endpoint. Then add an access_control rule for its name.

On this instance, copy the demo server block in /etc/nginx/sites-available/authelia for the new name (for example grafana.example.com). Keep the location = /internal/authelia/authz block and the auth_request lines. Replace the root/try_files lines with a proxy_pass to your application. Then add a rule such as:

- domain: 'grafana.example.com' policy: 'two_factor' subject: 'group:admins'

Restart Authelia and reload nginx. The certificate must cover the new name too.

authelia-set-domain re-renders the nginx site from its template, so keep your own server blocks in a separate file under /etc/nginx/sites-enabled/.

Everything Authelia keeps is on the state volume at /var/lib/authelia. List its contents:

sudo ls -l /var/lib/authelia /var/lib/authelia/secrets df -h /var/lib/authelia | tail -1

/var/lib/authelia: total 328 -rw------- 1 authelia authelia 311296 Oct 28 19:52 db.sqlite3 drwx------ 2 root root 16384 Oct 28 19:22 lost+found drwx------ 2 authelia authelia 4096 Oct 28 19:51 secrets -rw------- 1 authelia authelia 457 Oct 28 19:51 users_database.yml /var/lib/authelia/secrets: total 8 -rw------- 1 authelia authelia 64 Oct 28 19:51 session -rw------- 1 authelia authelia 64 Oct 28 19:51 storage-encryption /dev/nvme1n1 9.8G 344K 9.3G 1% /var/lib/authelia

• users_database.yml: users and their password hashes.
• db.sqlite3: Authelia's storage (second-factor devices, preferences, consent), encrypted with the key in secrets/storage-encryption. Keep the key with the database: without it the stored second-factor devices cannot be read.
• secrets/session: signs session cookies. Changing it signs everyone out.

Back up the volume with EBS snapshots (AWS Backup or Data Lifecycle Manager), or copy the files while Authelia is stopped. Treat backups as secrets.

Component Where

Authelia 4.39.28 /usr/local/bin/authelia, unit authelia.service, user authelia, 127.0.0.1:9091

Configuration /etc/authelia/configuration.yml (no secrets), /etc/authelia/authelia.env (0600, file paths of the secrets)

State /var/lib/authelia (own EBS volume)

nginx site /etc/nginx/sites-available/authelia, certificate /etc/ssl/authelia/

Domain helper /usr/local/sbin/authelia-set-domain

First boot authelia-firstboot.service, /usr/local/sbin/authelia-firstboot.sh

Logs journalctl -u authelia, /var/log/nginx/

Ubuntu packages update automatically through unattended upgrades. Authelia is a single binary, so you update it by hand:

• Download the new authelia-v<version>-linux-amd64.tar.gz from the Authelia releases page and verify its checksum.
• Read the release notes for configuration changes.
• Stop Authelia and back up /var/lib/authelia.
• Replace /usr/local/bin/authelia (owner root, mode 0755) and start Authelia again.

Authelia migrates its storage on start.

• Restrict SSH. Keep port 22 open to your own networks only.
• Use your own domain and certificate. Set your own domain and a CA-issued certificate before real users sign in, and switch the rules you rely on to two_factor.
• Keep the deny default. Keep default_policy: 'deny' and list each application explicitly.
• Review sign-in activity. Authelia logs every sign-in attempt with the client address. Failed attempts trigger the ban in regulation.

Known advisories in the shipped release. Authelia 4.39.28 (the newest release) is built with Go 1.27.1. Go fixed the following standard-library advisories in Go 1.27.2 and 1.27.3, after that release: GO-2026-6599, GO-2026-6600 (html/template), GO-2026-6603, GO-2026-6605, GO-2026-6609, GO-2026-6610, GO-2026-6611, GO-2026-6613 (net/http), GO-2026-6607 (crypto/tls), GO-2026-6608 (net/textproto) and GO-2026-6809 (crypto/x509).

Authelia serves HTTP through fasthttp, not Go's net/http server, so the server-side items do not apply. The rest are reachable only through outbound connections that Authelia makes to services you configure: email templates sent through an SMTP notifier, LDAP and SMTP TLS connections, OpenID Connect sector-identifier, WebAuthn metadata and OCSP fetches, and the authelia debug commands. None of these is configured in the image. SecureAnyCloud tracks the next Authelia release and will publish an updated version.