Deployment guide

Authentik

Overview

Authentik is an open-source identity provider and single sign-on (SSO) platform, and a self-hosted alternative to Okta, Auth0 and Keycloak. It centralises authentication for your applications and users with SAML, OAuth2/OIDC and LDAP. It also offers a flexible flow engine for login, enrollment and recovery, an outpost model for proxying and protecting applications, and a full admin interface and REST API.

This SecureAnyCloud image installs the official Authentik self-host Docker Compose stack, pinned to Authentik 2026.5.3. The server container serves the web UI, flows and REST API directly on port 80. The worker container runs migrations and background tasks, and a PostgreSQL 16 database stores your data. Every secret is rotated on the first boot of every VM: the PostgreSQL password, the Authentik secret key, and the akadmin bootstrap password and API token. A fresh akadmin superuser is seeded on a clean database, and all stateful data lives on a dedicated Azure data disk.

What you get:

The official Authentik 2026.5.3 self-host stack running under Docker (the server and worker containers plus PostgreSQL 16), pinned via AUTHENTIK_TAG so it never upgrades silently
The Authentik server publishing its web UI, flows and REST API on :80 (and HTTPS on :443), with no extra nginx layer because Authentik handles its own routing
An unauthenticated readiness endpoint (/-/health/ready/) and liveness endpoint (/-/health/live/) for load balancers and probes
A per-VM akadmin superuser generated on first boot, with a unique password and API token recorded in a root-only file, so every VM is secured independently
Docker's data-root relocated onto a dedicated 40 GiB Azure data disk at /var/lib/authentik, so the PostgreSQL volume, the Compose project, the media and the certificates survive OS changes and can be resized independently
The whole stack managed as one authentik.service systemd unit, plus docker.service, both enabled
PostgreSQL bound to the internal Docker network only, so just 22/tcp (SSH) and 80/tcp (Authentik HTTP) are exposed
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended starting size, because the multi-container Authentik stack needs the memory.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp. Authentik serves plain HTTP on port 80, so for production, put it behind your own domain and TLS.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Authentik by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:authentik-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name authentik \
  --image sac1647283583153:authentik-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name authentik --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the stack is running

The Authentik containers run under Docker as a Compose stack, managed by a single systemd unit. On first boot the stack rotates every secret, recreates itself on a fresh database and seeds the akadmin superuser. The multi-container stack can take a couple of minutes to become fully healthy after the VM is created.

systemctl is-active authentik.service

The command reports active. List the running containers with:

sudo docker compose -f /var/lib/authentik/docker-compose.yml ps

The whole stack is one systemd unit. Use sudo systemctl status authentik and sudo systemctl restart authentik to control every container together.

Step 5 - Retrieve your per-VM admin credentials

Your VM generates a unique akadmin password and API token on first boot and writes them to a root-only file. Read it with:

sudo cat /root/authentik-credentials.txt

The file contains authentik.admin.username (akadmin), authentik.admin.email (admin@sac.local), AUTHENTIK_ADMIN_PASSWORD (for the web UI) and authentik.bootstrap.token (a Bearer token for the REST API). Store these values somewhere safe.

Step 6 - Confirm the health endpoint

The Authentik server exposes an unauthenticated readiness endpoint. It answers once the database has migrated and the server is ready, which makes it ideal for load balancer probes:

curl -s -o /dev/null -w 'ready -> HTTP %{http_code}\n' http://localhost/-/health/ready/

The endpoint returns HTTP 204. The web UI is served by the same server on port 80:

curl -s -o /dev/null -w 'UI -> HTTP %{http_code}\n' http://localhost/

The UI returns HTTP 200, or a 302 redirect into the login flow.

Step 7 - Confirm the admin API round-trip

The akadmin bootstrap API token from Step 5 authenticates against the Authentik REST API. Replace <token> with the token from your credentials file. Then confirm that a valid token is accepted and a wrong one is rejected:

TOKEN=<token> curl -s -o /dev/null -w 'good -> HTTP %{http_code}\n' \
  -H "Authorization: Bearer ${TOKEN}" \
  http://localhost/api/v3/core/users/me/ curl -s -o /dev/null -w 'bad -> HTTP %{http_code}\n' \
  -H 'Authorization: Bearer wrong-token-xyz' \
  http://localhost/api/v3/core/users/me/

A valid token returns HTTP 200. A wrong token returns HTTP 403. This confirms that the per-VM akadmin superuser was seeded and that API authentication is enforced.

Step 8 - Sign in to the web UI

Browse to http://<vm-public-ip>/ and sign in with the username akadmin and the password from Step 5. Authentik presents its authentication flow: enter the username, then the password.

After you sign in, open the admin interface at http://<vm-public-ip>/if/admin/. The dashboard shows overall system status, workers, recent events and quick actions.

Under Applications, register the external applications that use Authentik as their identity provider. Under Providers, configure the protocol (SAML, OAuth2/OIDC, LDAP or Proxy) that each application uses.

Under Directory -> Users, manage user accounts, groups and tokens. The akadmin superuser is listed here.

Step 9 - Confirm data lives on the dedicated disk

Docker's data-root is relocated onto the dedicated Azure data disk. The PostgreSQL database volume, the Compose project, the media and the certificates all live there and survive OS changes:

findmnt /var/lib/authentik

The mount is backed by a separate Azure data disk that is captured into the image and re-provisioned on every VM. Confirm that Docker is using it:

sudo docker info -f '{{.DockerRootDir}}'

The command prints /var/lib/authentik/docker.

Creating your first application

Authentik connects your applications to a single identity source. In the admin interface:

Open Applications -> Providers and create a provider for your protocol, for example an OAuth2/OIDC provider for a web app or a SAML provider for an enterprise service.
Open Applications and create an application bound to that provider. Give it a name and slug.
Assign access with a policy or group binding.
Point your application's SSO configuration at Authentik's issuer/metadata URL.

See the Authentik documentation for protocol-specific setup and the full flow, stage and outpost model.

Maintenance

Admin credentials: the per-VM akadmin superuser is in /root/authentik-credentials.txt. Change the password from the user settings in the web UI after your first sign-in.
Data: the PostgreSQL volume, the Compose project and the media all live on the /var/lib/authentik data disk (Docker data-root). Snapshot or resize that disk for backups.
Stack: manage the whole stack with sudo systemctl <status|restart|stop> authentik, or manage individual containers with sudo docker compose -f /var/lib/authentik/docker-compose.yml <ps|logs|restart>.
TLS: Authentik serves plain HTTP on port 80. Front it with your own domain and TLS for production.
Security patches: unattended-upgrades stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com for help.

Deploy on Azure

Launch Authentik on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

Authentik is an open-source identity provider that offers single sign-on, multi-factor authentication, user management and access control for the applications your team already runs. It speaks SAML, OAuth2 and OpenID Connect, can act as an LDAP provider for older software, and lets you build custom login, enrolment and recovery journeys in a visual flow editor. Because it is self-hosted, your directory, credentials and audit trail stay inside your own AWS account.

This SecureAnyCloud image ships the official Authentik production container stack: the server, the background worker and a PostgreSQL 16 database, installed, wired together and managed by systemd. There is no Compose file to write and no database to provision by hand.

The appliance is secure by default. On the first boot of every instance, a fresh database password, application secret key, admin password and bootstrap API token are generated, so no shared or default credential is baked into the image. PostgreSQL publishes no host ports and is reachable only on the internal container network. Only SSH and the Authentik web ports are exposed. The whole stateful tier lives on its own EBS volume, which you can resize independently of the OS disk.

What you get:

Authentik 2026.5.3 (ghcr.io/goauthentik/server), with the server container serving the web UI, flows and REST API on host port 80 (and 443)
The Authentik background worker container, for scheduled tasks, outpost sync and notifications
PostgreSQL 16 (postgres:16-alpine) on the internal container network only, with no published host ports
authentik.service, a systemd unit that brings the whole stack up and down
authentik-firstboot.service, which rotates every per-instance secret before the stack serves
A dedicated 40 GiB EBS volume at /var/lib/authentik holding the Compose project, the database, media and certificates
An Ubuntu 24.04 LTS base with the latest patches and unattended security upgrades enabled

Prerequisites

You need an active AWS account, an EC2 key pair, and a VPC with a subnet.

The recommended instance type is m5.large. Choose a larger type if you expect many concurrent authentication flows or plan to run outposts.

Launch from the AWS Marketplace

Find Authentik on the AWS Marketplace, subscribe, and launch an instance.

In the launch wizard, attach a security group that allows inbound TCP 22 (SSH) and TCP 80 (the Authentik web interface) from your client networks only. Add TCP 443 if you plan to terminate TLS on the instance.

Launch from the AWS CLI

AMI_ID="<marketplace-ami-id>"
# from the Marketplace listing, in your region KEY_NAME="my-key" SUBNET_ID="subnet-xxxxxxxx" SG_ID="sg-xxxxxxxx"
# allows 22 + 80 from your networks only aws ec2 run-instances \
  --image-id "$AMI_ID" \
  --instance-type m5.large \
  --key-name "$KEY_NAME" \
  --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SG_ID" \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=authentik}]'

Connecting to your instance

Connect over SSH as the login user for your image's operating system. docker.service, authentik-firstboot.service and authentik.service all start automatically on first boot.

Operating system: Ubuntu 24.04 LTS
SSH login user: ubuntu
Connect with: ssh -i my-key.pem ubuntu@<instance-public-ip>

First boot pulls the container images and runs the initial database migrations. Allow two to three minutes after launch before the web interface answers.

Retrieve the per-instance credentials

First boot generates a random admin password and API token for this instance alone and writes them to a root-only file. Read it with:

sudo cat /root/authentik-credentials.txt

The file records the URL, the admin username and the generated password:

# Authentik self-host - generated on first boot by authentik-firstboot.service
# These credentials are unique to this VM. Store them somewhere safe. authentik.url=http://<instance-public-ip>/ authentik.admin.username=akadmin authentik.admin.email=admin@sac.local AUTHENTIK_ADMIN_PASSWORD=<AUTHENTIK_ADMIN_PASSWORD>

The file also carries an authentik.bootstrap.token value. This is a Bearer token for the REST API, used in Step 7.

Verify the services

Confirm that both host units report active:

systemctl is-active docker authentik

active active

Confirm that the container stack shows three services, all running:

sudo docker compose -f /var/lib/authentik/docker-compose.yml ps --format '{{.Service}}\t{{.State}}' | sort

postgresql running server running worker running

List the exact images in this deployment:

sudo docker ps --format '{{.Names}}\t{{.Image}}'

authentik-worker-1 ghcr.io/goauthentik/server:2026.5.3 authentik-server-1 ghcr.io/goauthentik/server:2026.5.3 authentik-postgresql-1 postgres:16-alpine

Check the health endpoints

Authentik exposes a readiness endpoint and serves the login flow. Check both:

curl -s -o /dev/null -w "health ready: HTTP %{http_code}\n" http://127.0.0.1/-/health/ready/
curl -s -o /dev/null -w "login flow: HTTP %{http_code}\n" http://127.0.0.1/if/flow/default-authentication-flow/

health ready: HTTP 200 login flow: HTTP 200

Use the readiness endpoint as the target for a load balancer or Auto Scaling health check.

Confirm the database is not network reachable

PostgreSQL runs on the internal container network and publishes no host ports, so it cannot be reached from outside the instance. Confirm that nothing listens on the database ports:

sudo ss -tlnp | grep -E ':5432|:6379' || echo "nothing on 5432 - internal container network only"

nothing on 5432 - internal container network only

Only the Authentik web ports are bound to the host. Confirm this with:

sudo ss -tlnp | grep -E ':80 |:443 ' | sed 's/users:.*//'

LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* LISTEN 0 4096 0.0.0.0:443 0.0.0.0:*

Verify the API round trip

The credentials file carries a Bearer token for the REST API. Confirm that the valid token is accepted and a wrong one is rejected. This is a real authentication round trip, not just a liveness check:

TOKEN=$(sudo grep '^authentik.bootstrap.token=' /root/authentik-credentials.txt | cut -d= -f2-)
echo "good token -> $(curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer ${TOKEN}" http://127.0.0.1/api/v3/core/users/me/)"
echo "wrong token -> $(curl -s -o /dev/null -w '%{http_code}' -H 'Authorization: Bearer wrong-token-xyz' http://127.0.0.1/api/v3/core/users/me/)"

good token -> 200 wrong token -> 403

Confirm the dedicated data volume

The Compose project, the database, media and certificates all live on their own EBS volume. The volume is mounted by filesystem UUID, so the layout survives reboots and relaunches:

df -h /var/lib/authentik

Filesystem Size Used Avail Use% Mounted on /dev/nvme1n1 40G 83M 37G 1% /var/lib/authentik

To grow the volume, resize it in the EC2 console and extend the filesystem with resize2fs. The OS disk is not affected.

Sign in

Open http://<instance-public-ip>/ in your browser. Sign in as akadmin with the password from Step 3.

Explore the flow engine

Authentik models every user journey (authentication, authorisation, enrolment and recovery) as a flow, which is an ordered chain of stages. In the admin interface, go to Flows and Stages > Flows to see the defaults that ship with the image and to build your own.

Check the background worker

The worker container runs scheduled and long-running jobs. Open Dashboards > System Tasks to see their status. This is the quickest way to confirm that the worker is healthy.

Add your first application

To put SSO in front of an application, create a provider (the protocol side) and an application (what users see):

In the admin interface, go to Applications > Providers and create a provider. Use OAuth2/OpenID for modern apps, SAML for enterprise software, or LDAP for tools that only speak LDAP.
Note the endpoints that Authentik generates for that provider.
Go to Applications > Applications, create an application and bind it to the provider.
Configure your application to use those endpoints as its identity provider.
Optionally, bind a policy to the application to restrict which users or groups may access it.

Enforce multi-factor authentication

Add an MFA stage to the authentication flow, and users are prompted to enrol:

Go to Flows and Stages > Stages and add an Authenticator Validation stage.
Choose the device classes you want to accept, such as TOTP applications or WebAuthn security keys.
Bind that stage into default-authentication-flow at the position where you want it enforced.
Add an Authenticator TOTP Setup or WebAuthn Setup stage to an enrolment flow so that users can register a device.

Manage the stack

The whole stack is wrapped in one systemd unit:

sudo systemctl status authentik --no-pager sudo systemctl restart authentik

Read container logs through Docker Compose:

sudo docker compose -f /var/lib/authentik/docker-compose.yml logs --tail 30 server

Back up and restore

The database is the data to protect. Take a logical dump directly from the container:

sudo docker compose -f /var/lib/authentik/docker-compose.yml exec -T postgresql pg_dump -U authentik authentik > /root/authentik-backup.sql

All state lives on the dedicated volume, so an EBS snapshot of /var/lib/authentik is also a complete point-in-time backup. Take snapshots on a schedule that matches your recovery objectives.

Add TLS (optional)

Authentik serves plain HTTP on port 80 by default. For production, put your own domain and a TLS certificate in front of it. Either terminate TLS at an AWS Application Load Balancer and forward to port 80, or supply your own certificate to Authentik and use port 443.

Either way, set the external URL in System > Brands so that generated links and redirects are correct.

Security notes

Restrict TCP 80, 443 and 22 in your security group to known client networks only. Never leave them open to the whole internet.
Change the generated akadmin password to one that your team manages, and create individual named admin accounts rather than sharing akadmin.
Enforce MFA on the authentication flow (Step 13) before you expose the instance beyond a trusted network.
Put TLS in front of the UI for production (Step 16).
Rotate the bootstrap API token once you have created your own service accounts and tokens.
Keep the OS patched. Unattended security upgrades are enabled by default.
Snapshot the Authentik data volume on a schedule.

Support and Licensing

authentik is a trademark of Authentik Security, Inc. The Authentik core is distributed under the MIT License. PostgreSQL is distributed under the PostgreSQL License. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on AWS

Find Authentik on the AWS Marketplace to launch this image in your own account.

Need Help?

SecureAnyCloud provides 24/7 technical support for this image. Support covers deployment, upgrades, provider and application configuration, LDAP and SAML integration, MFA policies, and fronting the UI with your own domain and TLS. Email sales@secureanycloud.com with your instance ID and a description of the issue.

Deploy on AWS

Launch Authentik with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS