Homelab Addiction
SecuritySelf-HostingDocker

How to Set Up Authentik for Your Homelab: A Beginner-Friendly Guide to Self-Hosted SSO and MFA

Learn how to set up Authentik on Docker for your homelab, add self-hosted SSO and MFA, and protect your first app without getting lost in identity jargon.

AU

Author

David Okonkwo

FTC disclosure: This article contains affiliate links. If you purchase through them, HomelabAddiction may earn a commission at no extra cost to you.

How to Set Up Authentik for Your Homelab: A Beginner-Friendly Guide to Self-Hosted SSO and MFA

Key Takeaways

  • Authentik gives your homelab one central identity layer, so you stop managing separate logins for every dashboard and web app.
  • It is more powerful than lighter tools because it can handle SSO, MFA, reverse-proxy auth, user directories, and more - but that also means the first setup feels bigger.
  • The easiest beginner path is to use the official Docker Compose install, finish the initial akadmin setup in the browser, and protect one app before you try to protect ten.
  • You do not need to expose every service to the internet to benefit from Authentik. It also makes internal-only apps cleaner and safer.
  • Most failed Authentik installs come down to bad secrets, DNS and HTTPS confusion, or not understanding the difference between an application, a provider, and an outpost.

If you have ever looked at your homelab and realized you now have five admin logins, three family-facing apps, two reverse proxies, and one vague promise to yourself that you will "clean up authentication later," this guide is for you.

That moment sneaks up on people. At first it is just Jellyfin. Then maybe Nextcloud. Then a dashboard, a note-taking app, a password manager, and something you exposed through a tunnel because it felt easier at the time. Before long, your homelab starts feeling like a hallway full of separate apartment keys. Nothing is impossible to manage, but everything is annoying enough that shortcuts start creeping in.

That is why Authentik matters.

Think of Authentik like the front desk in a well-run apartment building. Instead of every tenant inventing their own lock, key policy, and guest list, the building has one system for identity, access, and verification. You still decide which rooms people can enter. You just stop rebuilding the same access logic over and over.

In this guide, I will show you the simplest beginner path I recommend right now:

  1. Prepare one Docker host and one hostname
  2. Deploy Authentik with the official Docker Compose stack
  3. Finish the first-run setup in the browser
  4. Understand applications, providers, and outposts without drowning in jargon
  5. Protect one app first
  6. Turn on MFA and verify the whole flow actually works

If you already run a reverse proxy, keep these related guides handy because they pair well with this setup:

Official docs worth bookmarking as you go:

What Authentik is, in plain English

Authentik is a self-hosted identity provider.

That sounds abstract, so here is the plain version:

  • it can be your login system
  • it can add MFA
  • it can sit in front of apps that do not support modern auth on their own
  • it can act as your central place for users, groups, and access rules

If Authelia feels like a strong front gate, Authentik feels more like a full access-control system for the whole property. That extra flexibility is the reason people like it and the reason beginners get intimidated by it.

Why this matters before we touch commands:

  • You stop reusing weak per-app credentials.
  • You get one place to disable access when someone should no longer reach your services.
  • You can protect apps consistently instead of mixing built-in logins, basic auth, and hope.
  • You build toward cleaner SSO later instead of repainting the same wall every month.

What you need before you begin

For a small homelab install, Authentik does not need scary hardware, but it does want a stable host.

A few sensible hardware picks for this kind of service:

For the tutorial itself, you need:

  1. A Linux host with Docker and Docker Compose v2
  2. At least 2 CPU cores and 2 GB of RAM available for the stack
  3. One hostname you can dedicate to Authentik, such as auth.example.com
  4. A reverse proxy plan for later if you want nice public HTTPS
  5. Patience to protect one app first, not your entire homelab in a single evening

Why this matters: identity tooling is a foundation service. It does not need huge CPU power, but it does need consistency. If your DNS, time sync, or Docker host is flaky, Authentik will feel harder than it really is.

Step 1 - Verify the Docker host is ready

Run these commands first:

docker --version
docker compose version
hostname -f
free -h

You want to confirm four boring things before deployment:

  • Docker is installed
  • Compose v2 works
  • the host has a real hostname
  • you actually have enough memory free

If docker compose fails, fix that before you go further. Identity stacks are not where you want to discover that your Docker install has been half-broken for a month.

Step 2 - Create a clean working directory

I like keeping core services under /opt, but any organized path works.

sudo mkdir -p /opt/authentik
cd /opt/authentik

Why this matters:

Auth systems are exactly the kind of service you will need to revisit later for updates, backups, logs, or migration. A neat directory is not cosmetic. It is future stress reduction.

Step 3 - Download the official Compose file

Authentik already publishes a current Compose file, so use that instead of pasting random blog YAML from last year.

wget https://docs.goauthentik.io/compose.yml

Or if you prefer curl:

curl -O https://docs.goauthentik.io/compose.yml

At the time of writing, the official stack includes:

  • PostgreSQL
  • authentik server
  • authentik worker

That is one reason Authentik feels heavier than simpler tools. It is not just a single container with a config file. It is a real identity platform.

Step 4 - Generate secrets and create the .env file

Now create the environment file Authentik expects.

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" > .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
echo "AUTHENTIK_ERROR_REPORTING__ENABLED=true" >> .env

Then add the ports you want to expose. For a first local setup, I recommend keeping the default 9000 and 9443 ports instead of rushing straight to 80 and 443.

echo "COMPOSE_PORT_HTTP=9000" >> .env
echo "COMPOSE_PORT_HTTPS=9443" >> .env

Check what you wrote:

cat .env

You should see variables for PG_PASS, AUTHENTIK_SECRET_KEY, and the chosen ports.

Why this matters

This is one of the easiest places to sabotage yourself.

  • If AUTHENTIK_SECRET_KEY changes later, sessions and encrypted values break.
  • If your Postgres password is malformed, the stack never becomes healthy.
  • If you paste secrets by hand and miss a character, you get a very long evening.

The system is like a hotel master key system. If you lose the master key and silently replace it with a different one, all the locks stop matching. That is why these values matter so much.

Step 5 - Review the Compose stack before launching it

You do not need to memorize the whole file, but glance through it so you understand the basics:

sed -n '1,220p' compose.yml

The important ideas are:

  • postgresql stores Authentik's database
  • server runs the web app and API
  • worker handles background jobs and outpost-related tasks
  • the stack mounts local data/ and custom-templates/ paths
  • the default worker stack mounts /var/run/docker.sock

That last point deserves attention.

The official Compose stack mounts the Docker socket into the worker so Authentik can automatically deploy and manage outposts. That is convenient, but it also has security implications. For a beginner homelab, I think it is a reasonable trade-off if you understand it. Later, you can tighten that with a Docker socket proxy or manual outpost deployment.

Step 6 - Launch the stack

Start everything:

docker compose up -d

Then verify the services:

docker compose ps
docker compose logs --tail=50 postgresql
docker compose logs --tail=50 server
docker compose logs --tail=50 worker

If everything is healthy, you should see the containers running and Postgres passing its health check.

You can also test the web port locally:

curl -I http://127.0.0.1:9000/

A redirect or a normal HTTP response is fine. The goal is simply to confirm something useful is listening.

What could go wrong here

  • postgresql keeps restarting - usually the .env file is wrong or the volume has stale data from a bad attempt.
  • server starts before Postgres is ready - give it a moment, then check docker compose ps again.
  • port 9000 is already in use - change COMPOSE_PORT_HTTP in .env, then rerun docker compose up -d.
  • permissions issues in /opt/authentik - uncommon, but easy to spot in the logs.

Step 7 - Finish the initial setup in the browser

Now open:

http://YOUR-SERVER-IP:9000

Authentik should prompt you to set a password for the default akadmin user.

Use a long password, save it in your password manager, and finish the initial flow.

Why this matters

This first login is where a lot of people expect a magic preconfigured dashboard. Instead, Authentik hands you a serious admin surface. That can feel jarring if you are used to simpler self-hosted apps.

Do not panic. You do not need to understand everything on day one.

For now, you only need to remember three objects:

  • Application - the thing users see and launch
  • Provider - the auth method or access logic behind that app
  • Outpost - the component that actually enforces proxy, LDAP, RADIUS, or similar provider behavior

If that still feels fuzzy, use this analogy:

  • the application is the office you are trying to enter
  • the provider is the badge policy at the door
  • the outpost is the guard station that checks the badge in real time

That mental model is enough to get through the beginner phase.

Step 8 - Prepare one app to protect first

Do not try to wrap every service behind Authentik immediately. Pick one low-risk web app first.

Good candidates:

  • a dashboard
  • a personal notes app
  • a media app for testing
  • a secondary internal tool

Bad first candidates:

  • Proxmox
  • your router UI
  • your NAS admin interface
  • the only remote path you have back into your lab

Why this matters:

When beginners front-end everything at once, they create a giant troubleshooting knot. If the flow breaks, they do not know whether the problem is DNS, TLS, the reverse proxy, Authentik itself, or the protected app.

Start small. One app is a lab. Ten apps is an outage.

Step 9 - Create your first application and proxy provider

According to the official docs, the recommended workflow is to create the application and provider together.

Inside the Authentik admin UI:

  1. Go to Applications > Applications
  2. Click New Application
  3. Fill in the app details
  4. Choose Proxy Provider as the provider type
  5. Pick the provider mode

For most homelabbers with an existing reverse proxy, the easiest starting point is:

  • Forward auth (single application) if you already proxy traffic with Caddy, Nginx Proxy Manager, Traefik, or Nginx

If you want Authentik's outpost to act as the reverse proxy itself, use:

  • Proxy mode

Key values to understand:

  • External host - the real URL users visit, like https://notes.example.com
  • Internal host - the upstream app URL, like http://192.168.1.80:3000

Why this matters

This is the point where Authentik stops being "an app you installed" and becomes "an access layer you control."

The mistake I see most often is people choosing a provider mode before they understand where proxying happens. If your existing reverse proxy already handles app traffic, let it keep doing that and use forward auth. If you want the Authentik outpost to sit directly in the traffic path, use proxy mode.

Step 10 - Create an outpost

Proxy providers require an outpost. Authentik's own docs are very clear about that.

In the admin UI:

  1. Go to Applications > Outposts
  2. Click Create
  3. Choose Proxy as the outpost type
  4. Select the Docker integration if you used the official Compose stack
  5. Attach the application you just created
  6. Save it

Why this matters:

The outpost is what actually applies the provider logic outside of Authentik Core. Without it, you have a plan on paper but no one at the door checking IDs.

If the Docker socket mount remains in place from the official Compose file, Authentik can manage the outpost deployment more smoothly. If you later want a stricter setup, you can move to a Docker socket proxy or manual deployment.

Step 11 - Enable MFA before you call the job done

This is the whole point of moving to a central identity layer. Do not stop at "it logs in."

Inside Authentik, add a second factor for your admin account. TOTP is the simplest start because every phone authenticator app supports it.

Keep backup codes somewhere safe. Better yet, store them in a password manager and not on the same sticky note as your Wi-Fi password.

If you want stronger hardware-backed MFA later, this is where a YubiKey security key becomes a smart upgrade.

Why this matters

A central login without MFA is like installing a nicer front door and leaving the key under the mat. Better, yes. Good enough, no.

Step 12 - Verify the setup like you mean it

Run through this checklist before you move on:

docker compose ps
docker compose logs --tail=30 server
docker compose logs --tail=30 worker
curl -I http://127.0.0.1:9000/

Then test in the browser:

  • log out and log back in as akadmin
  • confirm MFA prompts correctly
  • open the application dashboard
  • test the first protected app
  • try an incognito window so you know the auth redirect really works

If you are exposing the app externally, test it from outside your LAN too. A setup that only works on your home Wi-Fi is not a finished remote-access design.

Common mistakes

1. Treating Authentik like a single-container toy

It is not. It is a real identity platform. Respect the database, secrets, and access model from day one.

2. Protecting everything at once

That is how you lock yourself out of three services and learn nothing useful from the experience.

3. Skipping HTTPS planning

Identity tools involve redirects, cookies, callback URLs, and trust boundaries. If your DNS and TLS setup is sloppy, Authentik will look broken when the real problem is elsewhere.

4. Confusing applications, providers, and outposts

This is normal at first. Slow down and keep the mental model straight:

  • application = what users access
  • provider = how Authentik protects it
  • outpost = the enforcement component

5. Rotating or losing AUTHENTIK_SECRET_KEY

Do not casually change it. Save it securely and back up the directory.

6. Exposing admin panels too early

Get the auth flow working locally or behind a VPN first. Public exposure is step two, not step zero.

Is Authentik better than Authelia?

For some homelabs, yes. For others, no.

Authelia is often easier if you mostly want a strong front gate for web apps. Authentik is better when you want a broader identity platform with more provider types, richer access control, and room to grow.

A good rule of thumb:

  • choose Authelia if you want simpler web-app protection fast
  • choose Authentik if you want a more complete identity platform and do not mind a steeper first setup

There is no shame in picking the smaller hammer. But if your homelab is already becoming a small private platform, Authentik starts making a lot of sense.

FAQ

Does Authentik require PostgreSQL?

For the official Docker Compose install, yes. The published stack uses PostgreSQL along with the Authentik server and worker services.

Do I need to expose Authentik itself to the internet?

No. You can keep it internal at first, especially if you reach your lab through a VPN like WireGuard. Public exposure only makes sense when your DNS, TLS, and reverse proxy design are solid.

What is an outpost in Authentik?

An outpost is the Authentik component that enforces certain provider types such as proxy, LDAP, RADIUS, or RAC. If you use a proxy provider, you need an outpost.

Can Authentik protect apps that do not support OAuth or SAML natively?

Yes. That is one of the main reasons people use the proxy provider. It can sit in front of apps that do not speak modern auth protocols on their own.

Should I use Authentik with a VPN?

Usually yes. They solve different problems. A VPN secures network access. Authentik secures identity and app access. Together, they are much stronger than either one alone.

What to learn next

Once Authentik is up and protecting one app, the next smart steps are:

  1. put your reverse proxy and HTTPS setup on solid footing
  2. clean up secrets handling in Docker Compose
  3. move remote access to WireGuard if you still rely on sloppy public exposure
  4. protect more apps one at a time instead of all at once

These guides are the best next reads from HomelabAddiction:

If you feel overwhelmed by Authentik's UI the first time you open it, that does not mean you picked the wrong tool. It just means you graduated from single-app auth to a real identity layer. Take it one service at a time, keep your first deployment small, and let the system earn your trust before you hand it the keys to the whole lab.