# authentik: Python pinned to 3.14 exactly, and three separate licence files > authentik is a self-hostable identity provider speaking SAML, OAuth2 and OIDC, LDAP and RADIUS. What the README does not tell you is in the repository: the Python requirement is an exact version match rather than a floor, the dependency lists are pinned to the patch, the release line is calendar-versioned and the tree is already three months past the newest tag, and the project ships three different licence files. **goauthentik/authentik** — GitHub describes it as The authentication glue you need.. The repository metadata lists Python as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README. - Repository: https://github.com/goauthentik/authentik - Website: https://goauthentik.io - Stars: 25,805 · Forks: 2,055 - Language: Python - License: NOASSERTION - Published: 2026-08-13 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/goauthentik-authentik ## The Python requirement is an exact match, not a lower bound Almost every project states a floor for its interpreter. This one states an equality: ```toml requires-python = "==3.14.*" ``` That is not the same promise. A floor says 3.12 and later will do; an equality with a wildcard says the project is built and tested against one minor series of 3.14 and nothing else. A machine on 3.13 is not supported, and neither is 3.15 when it arrives. The dependency list follows the same discipline, with every entry pinned to an exact version rather than a range. Django and the REST framework, the PostgreSQL driver, the cryptography library, the password hashing binding, the JSON web token and JOSE libraries, the WebAuthn library, the LDAP client, the Kubernetes client, the task queue, the Prometheus integration, the OpenTelemetry packages, the web server. Every one of them carries a version with no operator, which means a transitive upgrade cannot happen without a deliberate manifest change. That is a strong reproducibility position for an identity provider, where a surprise dependency bump in a security path is exactly what you do not want. The cost is that you are carrying security updates yourself: nothing arrives on its own, and a release with a patched cryptography version is something you have to notice and apply. ## The licence is split three ways, and the README links all three The License section of the README is four lines long and contains three separate licence links. One for the root of the repository, one inside the website directory, and one inside the enterprise directory. That is an unusual arrangement and it is stated plainly rather than buried. The three files cover the open-source core, the documentation site, and the code under the enterprise directory respectively, and they are not the same document. So the answer to whether authentik is free has layers. The core identity provider is open source, the documentation is under its own terms, and the enterprise components are licensed separately. The README also describes a commercial enterprise offering for organisations that want to replace an existing identity provider, naming several commercial products as the kind of deployment it targets, and points at a pricing page. The repository metadata for this project reports no recognised licence identifier, so automated tooling will not tell you which terms apply. If you are reading the code to understand it, modifying it, or vendoring part of it, open the specific file that covers the directory you are touching rather than assuming the root one governs everything. For most self-hosting users none of this matters. It matters the moment you look at a file under the enterprise path. ## The outpost is a separate Go binary with its own CI workflow authentik is not one web application, and the CI configuration is where that becomes visible. There are three workflows: one for the main project, one for the web interface, and one named for the outpost. The Go module is where the outpost's dependencies live, and the list is revealing. Alongside the usual HTTP, routing, logging and command-line libraries, there are two LDAP packages and two RADIUS packages, and two of them are not the obvious upstream ones. One LDAP library and one RADIUS library are published under the project's own namespace, plus another RADIUS library under a different domain. That pattern is what you get when a project needs behaviour the standard libraries do not provide. Two other entries are worth naming because they are unusual for an application module. A software bill of materials generator is a dependency, which means the project can produce an inventory of what it ships. And a continuous profiling client is a dependency, which means performance can be measured in production rather than inferred. The Go module declares a recent language version, and the module path is the project's own domain rather than a repository path, which is what you would expect for a component published for others to consume. So an authentik deployment is a Python service, a Go component and a frontend, each with its own build and its own test workflow. Plan monitoring and upgrades on that basis. ## The Rust workspace is explicitly not for publication The repository also contains a Rust workspace, and one line in its configuration answers the question you would otherwise have to guess at: ```toml publish = false ``` The workspace has four members, three of which look like runtime components and one of which is a documentation script under the website directory. The fact that documentation tooling sits in the same workspace as library code is a small choice, and it means a documentation change and a runtime change are versioned together. Two of the crypto and server dependencies carry feature flags that tell you what the project is optimising for. A cryptography backend is pulled in with its FIPS feature enabled, which is a compliance-oriented choice rather than a performance one. And the server crate is configured to use the TLS stack without a bundled crypto provider, which is how you keep that decision in one place rather than having two providers compiled in. The consequence for an adopter is that the Rust parts are internal. You cannot add them to your project from a package registry, so you are depending on authentik the product, not on authentik the library. That is fine for self-hosting and would be a problem if you were hoping to embed a piece of it. Note also that the workspace declares a recent language edition, and pins its own dependencies to exact versions with an equality operator, matching the Python side's approach. ## Versions are calendar-based, and the tree is past the last release The version scheme explains more about this project than any feature list. The Python manifest, the JavaScript manifest and the Rust workspace all carry the same version string, and it is a year and month followed by a sequence and a pre-release marker. The newest tagged release is a patch in the 2026.8 series, published in September 2026. The manifests on the main branch are already at the 2026.11 series, marked as a release candidate. So two things are true at once. The project versions by calendar month, which means releases are predictable and you can reason about when the next one is due. And the main branch is roughly three months ahead of the newest tag, because a release candidate for a later month is being prepared in parallel with the current stable line. The practical consequence is that the version string in a manifest is not a statement about what is released. If you are pinning for a deployment, pin a release tag, not the version you find in a file on the main branch. The last push to the main branch was on 2026-10-01, and the two most recent tags in the 2026.8 line were both published on 2026-09-09, with a further patch in that line following on 2026-09-17. Patch releases inside a month are normal here. ## Blueprints and schemas suggest configuration is meant to be code Two things in the repository layout point at a declarative approach to configuration, and neither is explained in the README. There is a blueprints directory at the top level, and there are two schema files, one of them at the root and another in a schemas directory. A schema file next to a template-oriented directory is the shape of a project that validates configuration before applying it. This is the kind of arrangement that decides whether an identity provider is pleasant or painful to run twice. If the state of the system, its applications, its providers and its policies can be expressed as files, then a lab and a production instance can be built from the same source, and an upgrade is a diff rather than a migration performed by hand. The README does not describe the blueprint mechanism, so if this matters to your decision, the documentation rather than the repository is where you will find it. What the repository shows is that the mechanism exists and is a first-class part of the project rather than an afterthought. The same layout also carries a lifecycle directory and a locale directory, which are container startup and translation concerns respectively. Several of the project's own scripts, including a spell checker with its own configuration file, are also part of the tree. ## A contribution has to clear seven checks, and the repo has an AI policy The JavaScript manifest documents what a change has to pass, and the check script is a sequence of seven steps run one after another: lint check, format check, build types, a runtime lint, a catalog lint, a spell check, and then the check for every workspace in the repository. Two details set the tone. The lint check passes a maximum warnings setting of zero, so warnings are failures. And the spell check runs a dedicated checker against the whole repository using a configuration file, so a typo in a comment is a build failure. There are also two custom lint scripts with names that suggest they check things a general linter cannot. One lints runtime behaviour and one lints catalogs, and catalogs here refers to a package manager feature: several dependencies are declared against a named version catalog rather than a fixed version, which is how a monorepo keeps one version of a shared tool across every workspace. The repository also carries an agent instruction file, a Claude file, and a written policy on artificial intelligence use, alongside a codeowners file and a code of conduct. For a project of this size, that is a reasonable amount of process. The one thing a contributor should know from the start is that the full sequence runs in order, so a formatting failure stops the later steps from telling you anything about your code. ## Conclusion authentik suits an organisation that wants to run its own single sign-on across many applications and needs LDAP or RADIUS sources alongside the usual browser protocols, and that will maintain a database and keep up with calendar-versioned releases. It is a poor fit if you need a stable long-lived version, since the tags move on a year-month scheme, and a poor fit if you want the Rust or Go pieces as libraries, since the Rust workspace is marked as not for publication. Before deploying, check three things: which of the three licence files covers the part you intend to read or modify, whether the Python and PostgreSQL versions match what your platform provides, and what the four installation paths assume about your existing infrastructure. ## FAQ ### What is authentik used for? authentik is an open-source identity provider for single sign-on, and it is used to centralise authentication for the applications an organisation runs. It supports SAML, OAuth2 and OIDC, LDAP and RADIUS, and is designed to be self-hosted from small labs through to large production clusters. The README also describes a commercial enterprise offering for organisations replacing an existing identity provider. ### Is authentik free? The core identity provider is open source, and the README links three separate licence files: one at the repository root, one in the website directory, and one in the enterprise directory, so the terms differ by part of the tree. There is additionally a commercial enterprise offering with its own pricing. Because the terms are split, check the licence file that covers the specific directory rather than assuming the root one applies everywhere. ### how to install authentik Four routes are documented: Docker Compose, recommended for small and test setups; a Kubernetes Helm chart, recommended for larger setups, with the chart kept in a separate repository; AWS CloudFormation using official templates; and one-click deployment through the DigitalOcean Marketplace. Each has its own documentation page, and the Compose and Helm routes are the two the project actually recommends, for small and large setups respectively. ### how to install authentik docker compose Docker Compose is the route the README recommends for small and test setups, and the documentation has a dedicated page for it. The project also offers a Kubernetes Helm chart for larger deployments, kept in a separate chart repository, plus CloudFormation templates for AWS and a Marketplace app for DigitalOcean, so a Compose install is the shortest path but not the only one. ### Is authentik better than keycloak? The README makes no comparison to Keycloak. What it does state is which commercial identity providers its enterprise offering is positioned to replace, naming Okta, Auth0, Entra ID and Ping Identity, and that the open-source project supports SAML, OAuth2 and OIDC, LDAP and RADIUS for self-hosting from small labs to large clusters. Any direct comparison would have to be made outside this documentation. ## Sources - [Official documentation](https://goauthentik.io) - [Official README](https://github.com/goauthentik/authentik#readme) - [Project repository](https://github.com/goauthentik/authentik) - [Release notes](https://github.com/goauthentik/authentik/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/goauthentik-authentik