Skip to content

chore: upgrade authentik to 2026.5 BED-8628 - #3106

Merged
mistahj67 merged 1 commit into
mainfrom
BED-8628
Aug 7, 2026
Merged

chore: upgrade authentik to 2026.5 BED-8628#3106
mistahj67 merged 1 commit into
mainfrom
BED-8628

Conversation

@mistahj67

@mistahj67 mistahj67 commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Description

Bumps authentik and brings it in line with BHE

Describe your changes in detail

Motivation and Context

Resolves BED-8628

Why is this change required? What problem does it solve?

How Has This Been Tested?

Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.

Screenshots (optional):

Types of changes

  • Chore (a change that does not modify the application functionality)

Checklist:

Summary by CodeRabbit

  • Chores
    • Updated the Authentik server and worker services to version 2026.5.
    • Upgraded the bundled PostgreSQL service to version 18.
    • Updated PostgreSQL data storage configuration for compatibility with the new database image.

@mistahj67 mistahj67 self-assigned this Aug 6, 2026
@mistahj67 mistahj67 added the api A pull request containing changes affecting the API code. label Aug 6, 2026
@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 1762bbc3-49fe-4ee9-ab8c-6b3322cc3680

📥 Commits

Reviewing files that changed from the base of the PR and between 31fe120 and c52bea6.

📒 Files selected for processing (1)
  • docker-compose.dev.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • docker-compose.dev.yml

📝 Walkthrough

Walkthrough

The development Compose configuration updates Authentik server and worker images to 2026.5, upgrades PostgreSQL to 18-alpine, and changes the database volume mount target.

Changes

Authentik development stack

Layer / File(s) Summary
Authentik images and database storage
docker-compose.dev.yml
The Authentik server and worker images use tag 2026.5. The database image uses PostgreSQL 18-alpine. The volume mount target changes to /var/lib/postgresql.

Estimated code review effort: 2 (Simple) | ~5 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description includes the change, ticket, and type, but it omits detailed motivation, testing information, and completed checklist items. Add detailed motivation and testing results, then complete the checklist or explain which items do not apply.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the Authentik upgrade to version 2026.5 and includes the associated ticket.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch BED-8628

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docker-compose.dev.yml`:
- Line 283: Update the PostgreSQL image change for the existing authentik-db
volume by documenting either a pg_dumpall/restore migration from the PostgreSQL
13 data directory to PostgreSQL 18’s /var/lib/postgresql/18/docker path, or an
explicit destructive volume reset procedure. Ensure the documentation clearly
tells developers how to handle the existing volume before starting the new
image.
- Line 228: Document a safe migration procedure for the Authentik and PostgreSQL
version changes in the development compose configuration, including database
backup and required sequential Authentik upgrades from 2023.10.7, or clearly
describe removing the authentik-db volume as a development-only reset before
starting 2026.5. Reference the affected Authentik image configuration and
PostgreSQL volume mount path, and preserve the warning that existing data must
not be started directly on the new versions.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: eec61e19-e26c-4da3-ba37-42c8e3057364

📥 Commits

Reviewing files that changed from the base of the PR and between c9e4e36 and ae41396.

📒 Files selected for processing (1)
  • docker-compose.dev.yml

Comment thread docker-compose.dev.yml
- sso
- sso-only
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2023.10.7}
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.5}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

compose_file=docker-compose.dev.yml

git diff --unified=12 -- "$compose_file"
rg -n -C 6 'AUTHENTIK_TAG|authentik-worker|authentik-db' "$compose_file"

db_container="$(docker compose -f "$compose_file" ps -q authentik-db 2>/dev/null || true)"
if [[ -n "$db_container" ]]; then
  docker inspect "$db_container" \
    --format '{{range .Mounts}}{{println .Name .Source .Destination}}{{end}}'
fi

Repository: SpecterOps/BloodHound

Length of output: 2992


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- Authentik references ---'
rg -n -i -C 4 'authentik|AUTHENTIK_TAG|2023\.10\.7|2026\.5|upgrade|reset.*database|database.*reset' \
  --glob '!node_modules' --glob '!dist' --glob '!build' .

printf '%s\n' '--- Relevant compose history ---'
git log --oneline --all -- docker-compose.dev.yml | head -20

printf '%s\n' '--- File header ---'
sed -n '1,25p' docker-compose.dev.yml

printf '%s\n' '--- Current and parent Authentik image lines ---'
git show HEAD^:docker-compose.dev.yml 2>/dev/null | rg -n 'AUTHENTIK_TAG|authentik-worker' || true
git show HEAD:docker-compose.dev.yml 2>/dev/null | rg -n 'AUTHENTIK_TAG|authentik-worker' || true

Repository: SpecterOps/BloodHound

Length of output: 50379


🌐 Web query:

Authentik 2026.5 upgrade sequential major versions 2023.10.7

💡 Result:

Authentik requires a strict, sequential upgrade path for all major versions [1][2][3]. You cannot upgrade directly from version 2023.10.7 to 2026.5, as doing so will likely cause database migration failures, potential data corruption, or system instability [4][5]. To upgrade from 2023.10.7 to 2026.5, you must follow the sequential order of major releases, upgrading to the latest minor version (the latest.x release) of each intermediate major release before proceeding to the next [1][6]. The required upgrade path involves upgrading through the major versions released between 2023.10 and 2026.5. Based on the documented release history, this path generally looks like this: 1. Ensure you are on the latest 2023.10.x version [1]. 2. Upgrade to the latest 2025.12.x version [7][8]. 3. Upgrade to the latest 2026.2.x version [7]. 4. Finally, upgrade to the latest 2026.5.x version [2]. Before beginning any upgrade, you must back up your database [1]. If you encounter migration errors during the process, do not skip versions; instead, revert to your backup and ensure each step is completed fully before moving forward [6][5]. Always verify that your authentik instance and all outposts are updated to the same version simultaneously [1][2].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- Compose change ---'
git diff --unified=8 -- docker-compose.dev.yml || true

printf '%s\n' '--- Authentik lines in parent and current revisions ---'
for rev in HEAD^ HEAD; do
  printf '%s\n' "--- $rev ---"
  git show "$rev:docker-compose.dev.yml" 2>/dev/null \
    | grep -n -E 'AUTHENTIK_TAG|authentik-worker|authentik-db|authentik:' || true
done

printf '%s\n' '--- Compose header and project guidance ---'
sed -n '1,35p' docker-compose.dev.yml
printf '%s\n' '--- LICENSE.header ---'
cat LICENSE.header 2>/dev/null || true
printf '%s\n' '--- Authentik-specific documentation files ---'
git ls-files | grep -Ei 'authentik|compose|development|contribut' | head -100

Repository: SpecterOps/BloodHound

Length of output: 7467


🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from urllib.request import urlopen
from urllib.error import HTTPError, URLError

urls = [
    "https://docs.goauthentik.io/install-config/upgrade/",
    "https://docs.goauthentik.io/releases/2026.5/",
]
for url in urls:
    print(f"--- {url} ---")
    try:
        text = urlopen(url, timeout=15).read().decode("utf-8", "replace")
        lower = text.lower()
        terms = ("sequential", "major", "2023.10", "2025.12", "2026.2", "backup")
        for term in terms:
            positions = [i for i in range(len(lower)) if lower.startswith(term, i)]
            for pos in positions[:3]:
                print(text[max(0, pos-250):pos+500].replace("\n", " ")[:800])
    except (HTTPError, URLError, TimeoutError) as exc:
        print(type(exc).__name__, exc)
PY

Repository: SpecterOps/BloodHound

Length of output: 560


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- Database image and mount change ---'
for rev in HEAD^ HEAD; do
  printf '%s\n' "--- $rev ---"
  git show "$rev:docker-compose.dev.yml" 2>/dev/null \
    | sed -n '279,297p'
done

printf '%s\n' '--- Authentik upgrade text from upstream documentation ---'
python3 - <<'PY'
import ssl
from urllib.request import urlopen
urls = [
    "https://raw.githubusercontent.com/goauthentik/authentik/main/website/docs/install-config/upgrade.mdx",
    "https://raw.githubusercontent.com/goauthentik/authentik/main/website/docs/releases/2026/v2026.5.md",
]
ctx = ssl._create_unverified_context()
for url in urls:
    print(f"--- {url} ---")
    try:
        text = urlopen(url, timeout=20, context=ctx).read().decode("utf-8", "replace")
        lines = text.splitlines()
        for i, line in enumerate(lines):
            if any(term in line.lower() for term in (
                "skip", "sequential", "major", "2023.10", "2025.12",
                "2026.2", "upgrade path", "backup"
            )):
                lo, hi = max(0, i-2), min(len(lines), i+3)
                print(f"{i+1}: " + "\n".join(lines[lo:hi]))
    except Exception as exc:
        print(type(exc).__name__, exc)
PY

Repository: SpecterOps/BloodHound

Length of output: 7539


🌐 Web query:

site:docs.goauthentik.io/install-config/upgrade authentik skip versions sequential upgrade

💡 Result:

Authentik does not support skipping versions during an upgrade. Official documentation explicitly states that upgrades must follow the sequence of major releases and that you should not skip directly from an older major version to the most recent one [1]. To perform a safe upgrade, you must follow these steps: 1. Within each major.minor version, always upgrade to the latest minor version (e.g.,.x) before moving to the next major version [1]. 2. For example, if you are currently running version 2025.2.1, the upgrade path would be to upgrade to the latest 2025.2.x, then to the latest 2025.4.x, and finally to the latest 2025.6.x [1]. 3. You should review the release notes for each specific version you are upgrading to, as they may contain breaking changes or special requirements [1]. 4. The version of the authentik server and all authentik outposts must match, so ensure all outposts are upgraded at the same time as the core authentik instance [1]. Because downgrading is not supported, it is critical to back up your database before beginning the upgrade process so you can revert if an issue occurs [1].

Citations:


🌐 Web query:

site:github.com/goauthentik/authentik 2023.10.7 2026.5 database migration upgrade

💡 Result:

Upgrading from Authentik version 2023.10.7 to 2026.5 cannot be done directly [1][2][3]. Authentik strictly requires sequential upgrades by major version [1][2]. Skipping major versions often leads to failed database migrations, partial updates, or database corruption [3][4]. To upgrade from 2023.10.7 to 2026.5, you must upgrade through each intermediate major release [1][2]. You should also ensure you are on the latest minor release for each major version before moving to the next [1]. General upgrade process: 1. Always back up your PostgreSQL database before beginning [1]. 2. Upgrade to the latest minor version of each sequential major release [1]. For example: 2023.10.7 -> [2024.x] -> [2025.x] -> 2026.5 [1][2][3]. 3. For each step, update your deployment (e.g., Docker Compose file or Helm chart) to the specific version [1][2]. 4. Verify that all components (e.g., server, workers, outposts) are running the same version [2][5]. If you have already attempted a direct upgrade and encountered errors such as migration inconsistencies or "column does not exist" errors, you may need to restore your database from the backup taken before the failed upgrade attempt [1][3][4]. If no backup is available, you may be required to manually fix the database schema or revert to the previous version and perform the correct sequential upgrade path [3][6]. Consult the official Authentik upgrade documentation for the most accurate, version-specific instructions [1][3].

Citations:


Document a safe Authentik and PostgreSQL migration path.

If authentik-db contains data from 2023.10.7, setting both services to 2026.5 skips required sequential Authentik upgrades. This change also upgrades PostgreSQL from 13.2-alpine to 18-alpine and changes the volume mount path. Add backup and intermediate-version procedures, or document removal of the authentik-db volume as a development-only reset before starting 2026.5. (Authentik upgrade documentation)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docker-compose.dev.yml` at line 228, Document a safe migration procedure for
the Authentik and PostgreSQL version changes in the development compose
configuration, including database backup and required sequential Authentik
upgrades from 2023.10.7, or clearly describe removing the authentik-db volume as
a development-only reset before starting 2026.5. Reference the affected
Authentik image configuration and PostgreSQL volume mount path, and preserve the
warning that existing data must not be started directly on the new versions.

Comment thread docker-compose.dev.yml
- sso
- sso-only
image: docker.io/library/postgres:13.2-alpine
image: docker.io/library/postgres:18-alpine

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

compose_file=docker-compose.dev.yml
db_container="$(docker compose -f "$compose_file" ps -q authentik-db 2>/dev/null || true)"

if [[ -z "$db_container" ]]; then
  echo "authentik-db is not running; start the stack before inspecting the volume."
  exit 1
fi

docker inspect "$db_container" \
  --format '{{range .Mounts}}{{println .Name .Destination}}{{end}}'

docker compose -f "$compose_file" exec -T authentik-db sh -c '
  echo "PGDATA=${PGDATA:-unset}"
  find /var/lib/postgresql -maxdepth 4 -name PG_VERSION -print
'

Repository: SpecterOps/BloodHound

Length of output: 234


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '--- docker-compose.dev.yml database section ---'
sed -n '260,305p' docker-compose.dev.yml

echo '--- PostgreSQL image and volume references ---'
rg -n -C 3 'postgres:|authentik-db|/var/lib/postgresql' --glob '!node_modules' --glob '!dist' .

echo '--- repository status and recent file summary ---'
git status --short
git diff --stat -- docker-compose.dev.yml

Repository: SpecterOps/BloodHound

Length of output: 8802


🌐 Web query:

Docker Official Image postgres 18 PGDATA /var/lib/postgresql/18/docker volume mount migration old /var/lib/postgresql/data

💡 Result:

In the official PostgreSQL Docker image, starting with version 18, the default PGDATA environment variable has been changed to /var/lib/postgresql/18/docker, and the declared VOLUME has been moved to /var/lib/postgresql [1][2][3]. This change replaces the previous convention where PGDATA was located at /var/lib/postgresql/data and the VOLUME was defined at that same path [1][3]. Mounting your volume at /var/lib/postgresql/data (the old location) with PostgreSQL 18+ will result in the container ignoring your existing data, as it will look for data in the new /var/lib/postgresql/18/docker location [4]. Migration Steps: Because PostgreSQL data is not directly compatible between major versions, you cannot simply move the files and restart the container. The recommended path for migrating your data is as follows: 1. Backup: Perform a full export of your existing database using pg_dumpall while the old container (version 17 or below) is running [4][3]. 2. Update Configuration: Update your docker-compose.yml or docker run command to mount your volume at the new target directory: /var/lib/postgresql [1][4][5]. 3. Recreate Container: Remove the old container and volume, then start a new container with the postgres:18 image using the updated mount path [4][5]. 4. Restore: Import your backup (e.g., via psql -f backup.sql) into the new instance [6][4]. If you have pre-existing data that you specifically want to move to the new structure, you must adjust the folder structure on your host or within your volume to place all database files into a 18/docker subdirectory before mounting the volume to /var/lib/postgresql [1][7][3]. However, since PostgreSQL major upgrades require a version-specific upgrade process (like pg_upgrade), a backup and restore is the standard and safest approach [4]. The new structure (/var/lib/postgresql as the volume mount and /var/lib/postgresql/18/docker as PGDATA) is intended to support faster upgrades between major versions by allowing the use of pg_upgrade --link when multiple versions are mounted under the same parent directory [1][8][3].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '--- previous compose definition ---'
git show HEAD^:docker-compose.dev.yml | sed -n '275,300p'

echo '--- current compose definition ---'
sed -n '279,297p' docker-compose.dev.yml

echo '--- relevant commit summary ---'
git log -5 --oneline -- docker-compose.dev.yml

echo '--- PostgreSQL 18 entrypoint defaults and initialization logic ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/docker-entrypoint.sh |
  rg -n -C 5 'PGDATA|docker_setup_db|DATABASE_ALREADY_EXISTS|initdb'

Repository: SpecterOps/BloodHound

Length of output: 9257


🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from pathlib import Path

old_mount = Path("/var/lib/postgresql/data")
new_mount = Path("/var/lib/postgresql")
new_pgdata = new_mount / "18" / "docker"

volume = {
    old_mount.relative_to(old_mount.parent): "old PostgreSQL cluster",
}
print(f"old cluster path in the reused volume: {old_mount}")
print(f"PostgreSQL 18 cluster path in the reused volume: {new_pgdata}")
print(f"same path: {old_mount == new_pgdata}")
print(f"old cluster is outside new PGDATA: {old_mount != new_pgdata}")
PY

Repository: SpecterOps/BloodHound

Length of output: 359


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '--- PostgreSQL 18 old-data detection and failure path ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/docker-entrypoint.sh |
  sed -n '235,275p;338,366p'

echo '--- PostgreSQL 18 image PGDATA and volume declarations ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/Dockerfile |
  rg -n -C 4 'PGDATA|VOLUME'

echo '--- PostgreSQL 13 image defaults for comparison ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/13.2/alpine/Dockerfile |
  rg -n -C 4 'PGDATA|VOLUME'

Repository: SpecterOps/BloodHound

Length of output: 3890


🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
# Model the relevant paths only. This does not start containers or execute
# repository code.
old_cluster = "/var/lib/postgresql/data"
new_pgdata = "/var/lib/postgresql/18/docker"
old_database_candidates = [
    "/var/lib/postgresql",
    "/var/lib/postgresql/data",
    "/var/lib/postgresql/*/docker",
]

print("old cluster matches PostgreSQL 18 legacy candidate:",
      old_cluster in old_database_candidates)
print("old cluster equals PostgreSQL 18 PGDATA:",
      old_cluster == new_pgdata)
print("PostgreSQL 18 requires a major-version migration:",
      "13" != "18")
PY

Repository: SpecterOps/BloodHound

Length of output: 318


🏁 Script executed:

#!/bin/bash
set -euo pipefail

entrypoint_url=https://raw.githubusercontent.com/docker-library/postgres/18/alpine/docker-entrypoint.sh

echo '--- PostgreSQL 18 Alpine old-data error ---'
curl -fsSL "$entrypoint_url" |
  rg -n -C 8 'docker_error_old_databases|OLD_DATABASES|unused mount/volume'

echo '--- PostgreSQL 18 Alpine defaults ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/18/alpine/Dockerfile |
  rg -n -C 3 'PGDATA|VOLUME'

Repository: SpecterOps/BloodHound

Length of output: 252


Migrate the existing authentik-db volume before switching to PostgreSQL 18.

The previous configuration stored the PostgreSQL 13 cluster at /var/lib/postgresql/data. PostgreSQL 18 expects /var/lib/postgresql/18/docker and does not perform a major-version migration. Add a documented pg_dumpall/restore procedure or an explicit destructive volume reset.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docker-compose.dev.yml` at line 283, Update the PostgreSQL image change for
the existing authentik-db volume by documenting either a pg_dumpall/restore
migration from the PostgreSQL 13 data directory to PostgreSQL 18’s
/var/lib/postgresql/18/docker path, or an explicit destructive volume reset
procedure. Ensure the documentation clearly tells developers how to handle the
existing volume before starting the new image.

Comment thread docker-compose.dev.yml
profiles:
- sso
- sso-only
image: docker.io/library/postgres:13.2-alpine

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀

@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

@mistahj67
mistahj67 merged commit 5505c62 into main Aug 7, 2026
13 checks passed
@mistahj67
mistahj67 deleted the BED-8628 branch August 7, 2026 17:50
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 7, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

api A pull request containing changes affecting the API code.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants