Automated authentik installs without plaintext admin passwords

Automated authentik installs without plaintext admin passwords: when teams need it

An automated authentik install still has to set the initial akadmin credential, so the real goal is to make sure that credential never sits in plaintext in a pipeline, a script, a configuration file or a process listing. Every repeatable deployment needs a bootstrap step, and that step is where a password is most likely to leak. Teams that automate installs without thinking about this usually end up passing the password as an environment variable or command argument, where it can be read from CI logs, shell history or ps output on the host.

authentik is self-managed single sign-on that issues tokens and assertions through OAuth2/OIDC, SAML, LDAP and other provider types. A deployment has a server container (core plus an embedded outpost), a worker container for background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. Because configuration lives in PostgreSQL, a fresh install needs a known administrator identity before anything else can be automated, which is why the bootstrap settings matter for rebuilds, disaster recovery and test environments that must be recreated on demand.

This topic concerns the MIT-licensed core of authentik. Code in the authentik/enterprise/ directory is covered by a separate enterprise license defined in that directory, and nothing in this section draws conclusions about which features that code provides. Before you design the pipeline, confirm the version you will deploy with the authentik releases page and check the supported versions in the security policy, because the password-handling options differ between releases.

How AUTHENTIK_BOOTSTRAP_PASSWORD_HASH changes the install

From authentik 2026.5, the initial akadmin password can be supplied as a pre-computed hash through the AUTHENTIK_BOOTSTRAP_PASSWORD_HASH setting, so the pipeline never has to hold the plaintext value. The hash is produced with the hash_password command that the same release added. The practical change is in the install flow: the CI job or configuration management run generates the hash ahead of time, stores it in the secret store your team already uses, and passes only the hash into the container environment at first start. The plaintext password should never be written into a pipeline variable, a playbook or a compose file. Before you adopt this, confirm the exact behavior of the setting, including whether it applies only on first bootstrap, against the authentik 2026.5 release notes for the version you deploy.

The same release also allows pre-hashed Django passwords to be imported through blueprints and the password-hash API. This matters if you already keep password hashes from an earlier system or want to seed other accounts during automated setup without ever generating a plaintext value in the pipeline. Treat this as a design decision, not a shortcut: decide which accounts may be created this way, who can read the hash-bearing blueprint or API payload, and whether those files are kept in version control. Confirm the accepted hash formats and the import behavior in the same release notes, and test the import against a non-production instance before relying on it. Plan a check that the imported account can sign in and that the hash is not echoed in logs or job output.

Ask your team to confirm three points before writing the pipeline: which authentik version you will pin, which secret store will hold the hash, and who is allowed to rotate the admin password after first login. A pre-computed hash removes the plaintext from the install, but it does not remove the need to change the admin credential through your normal access process. Record the version, the hash generation step and the verification result as evidence for your change record, so an auditor or a later operator can see how the initial account was created.

Which bootstrap method fits which pipeline

This table compares four ways to set the initial akadmin password during an authentik install. Read each row for the pipeline type it suits, what it exposes, and what to confirm for the version you run. The main takeaway is that the hash-based options keep plaintext out of the environment and process list, but only where your authentik version supports them.

Method	When it fits	What it exposes	What to confirm for your version
Plaintext environment variable	Throwaway test stacks on a laptop or ephemeral sandbox that is destroyed after use	The password appears in the container environment, orchestrator manifests, CI logs and shell history if set carelessly	Confirm the bootstrap variable name in the release notes for your version and rotate the akadmin password after first login
Pre-hashed AUTHENTIK_BOOTSTRAP_PASSWORD_HASH	Automated production or staging installs in CI or configuration management where the hash is generated ahead of deploy	Only the hash is in configuration, which is still sensitive offline material, so restrict who can read the pipeline variable	Available from authentik 2026.5 according to the 2026.5 release notes; confirm the variable is supported by the exact version you deploy
Hash generated with hash_password at deploy time	Pipelines that create the hash on the build runner rather than storing it, with the password supplied from a secret store	On 2026.8 and later the password comes from a hidden prompt or standard input, so it avoids the command line and process list	Requires authentik 2026.8 or later for stdin or prompt input; on 2026.5 to 2026.7 confirm how the password reaches the command before use
Manual first login	Single-operator installs where someone sets the password through the browser after the first start	No password in automation, but the initial credential window depends on who reaches the setup page first	Confirm the setup route is reachable only from a trusted network and that the first login is completed before exposing the service

What changes between authentik 2026.5 and 2026.8

Release 2026.5 added a way to set the initial akadmin password without placing the plain value in your configuration. The AUTHENTIK_BOOTSTRAP_PASSWORD_HASH variable accepts a precomputed hash, and the hash_password command produces that hash from a password you provide. The same release also allowed pre-hashed Django passwords to be imported through blueprints and the password-hash API, so one hash format covers bootstrap and later account changes. Read the 2026.5 release notes for the exact syntax before you write a pipeline step against it.

Bootstrap hash variable: AUTHENTIK_BOOTSTRAP_PASSWORD_HASH sets the initial akadmin password from a hash.
hash_password command: Generates the hash in a build or deploy step, so the job definition does not need to store the plain password.
Blueprint imports: Pre-hashed Django passwords can be imported through blueprints, which helps when accounts come from another Django-based system.
Password-hash API: Accepts pre-hashed passwords for accounts, which suits automation that manages users after the first start.

Confirm with a test deployment that the variable and command behave as the release notes describe in your chosen install method.

Release 2026.8 changed how hash_password receives its input. The command no longer accepts the password as a command-line argument. It reads from a hidden prompt when run interactively, or from standard input when the value is piped in, so the password no longer appears in shell history or in the process list. The 2026.8 release notes describe the change and should be the reference for your automation.

Argument removed: A script that passes the password as an argument will not work the same way on 2026.8, so confirm the exact failure in a test run.
Hidden prompt: Interactive use asks for the password without echoing it to the terminal.
Standard input: Automation supplies the password on stdin from a secret store or from a file the job runner manages.
Process list exposure: Arguments are visible to other users on the same host through the process list, and the stdin path avoids that exposure.

Run every hash step against a 2026.8 image before you change the image tag in production.

Scripts written for 2026.5 most often pass the password directly on the command line, which was the convenient form before the change. Migration starts with an inventory of every place the hash is generated, then moves the password to standard input and removes any logging that could expose it. Shared build agents and multi-user hosts need extra attention, because a password that appeared in an argument on those hosts should be treated as exposed.

Find call sites: Search pipelines, configuration management roles, Helm hooks and shell scripts for hash_password followed by a password value.
Switch to stdin: Pipe the value from your secret store into the command so the password never appears in an argument list.
Remove echo and trace output: Confirm the job does not print the variable or the full command line, including when shell tracing is enabled.
Rotate exposed passwords: If a password was passed as an argument on a shared host, rotate it and review who could read that host's process list.
Test failure handling: Make sure the job fails clearly when the input is missing, so a deployment does not continue with an empty hash.

After the change, review one full install from a clean state to confirm the akadmin login works with the value supplied through the new path.

How to script a hashed bootstrap step by step

This sequence takes a fresh authentik install from a pinned release to a working administrator login without the initial password appearing in a file, command line or log. Each step names the check that shows it is complete.

Pin the authentik version
The platform team sets the image tag in the Compose file or Helm values to one release from the 2026.8 line or later, because that is when hash_password began reading the password from a hidden prompt or standard input. Check the GitHub releases page for the current release, and confirm the version appears in the supported versions list in the security policy. The step is done when the rendered Compose file or manifest shows one fixed tag and no floating latest reference.
Generate the hash from standard input
Run the hash_password command from the pinned server image and supply the password through a hidden prompt or standard input, never as a command-line argument. In CI, the value usually comes from a masked secret variable piped into the command, so the password does not appear in the job definition. Confirm the exact invocation in the 2026.8 release notes before you script it. The step is done when the command returns a single hash string that can replace the plaintext value in the later steps.
Store the hash in the secret manager
Write the hash to your secret manager as its own entry, separate from the database credentials and the application secret key, and restrict read access to the deployment identity. Record the entry name and version in pipeline configuration, but never the value itself. Agree with your identity team how the first administrator changes the password after the first sign in, and document that process. The step is done when a read from the secret manager returns the hash for the deployment identity and the plaintext no longer sits in CI variables or tickets.
Inject the variable into the server container
Set AUTHENTIK_BOOTSTRAP_PASSWORD_HASH on the server container through the secret mechanism your platform already uses. The Docker Compose installation guide defines where the variable belongs in the service environment, and the Kubernetes guide covers the equivalent in Helm values or an existing secret. Confirm whether the worker container needs the variable at all. The step is done when the rendered configuration references the secret and the hash value appears only at runtime.
Start the stack and wait for readiness
Deploy the stack from the rendered configuration, then wait for the server container to report healthy and the worker to start. Read the startup output for database migration messages and for errors about bootstrap settings. Confirm the reverse proxy routes traffic to the server before you test login. The step is done when the public hostname responds and the logs show a completed startup with no configuration errors.
Verify login with the bootstrap admin
Sign in as the akadmin account through the public URL, using the password the administrator holds, and confirm the admin interface loads with the expected access. Attempt one deliberately wrong password to confirm the login is rejected, which shows the supplied hash is being checked. Use a clean browser session for the test. The step is done when the administrator signs in successfully and the wrong-password attempt fails.
Scan logs and shell history for plaintext
Search pipeline logs, container logs and the operator's shell history for both the plaintext password and the hash string. Confirm that CI log masking hid the secret in job output and that no one ran hash_password with the password as an argument. Record the search scope and result in the deployment record. The step is done when the search returns no matches for either value.

Security risks to control in automated installs

An automated install handles the admin password at several points: when it is created, when it is hashed, when it reaches the server, and after first login. Each point has its own exposure, so the controls need to cover the whole path from the secret store to the running instance and the runner that performs the hash.

Process list exposure

Any password passed as a command-line argument can appear in the process list, where other local users may read it while the command runs. From authentik 2026.8, hash_password no longer accepts the password as an argument. It reads from a hidden prompt or standard input, so pipe the value from your secret store into the command. On hosts still running earlier releases, confirm that your scripts never expand the secret into argv.

CI log leakage

CI systems echo commands and store standard output, so a password or generated hash written into a build step can persist in job logs that many people can read. Mask the variables in your CI platform, disable command tracing around the hashing step, and keep the hash command's output out of the log. Confirm how your platform masks multi-line values, because partial masking can still expose part of a secret.

Shell history

Interactive shells record the commands a person types, including any inline password. Run the hash step from a script or a CI job instead of a terminal session. For manual runs, use the hidden prompt, and turn off history for that session with HISTFILE set to an empty value. After an operator session, check the history file for any password value and remove it.

Secret rotation after first login

The bootstrap password exists for the first setup. After the admin account is in use, the value can still sit in environment files, pipeline variables, Helm values or backups. Plan a rotation step: change the admin password inside authentik, remove the bootstrap variable from the deployment configuration, and replace every stored copy. Confirm in the authentik 2026.5 release notes how the bootstrap value is handled after the first start.

Hash stored in version control

A password hash is not the plaintext, but anyone who holds it can try guesses offline, so it deserves the same protection as the password. Keep the hash in your secret store, not in Helm values, Compose files, Terraform variables or blueprints committed to Git. Deleting a file does not remove it from history, so check past commits and forks if a hash was ever committed.

Access to the hashing runner

The runner that creates the hash handles the plaintext password before it is hashed, so its access controls are the real boundary. Limit who can read job logs, workspace files and the runner host. Use ephemeral runners where possible, scope the secret to protected branches or environments, and review which accounts hold administrator rights on the CI platform.

Questions teams ask before automating authentik installs

Can our own team automate an authentik install without an outside partner?

Yes, a platform team that already runs CI and a secret store can automate an authentik install without outside help, provided it owns the pipeline and the release process. The bootstrap settings are documented in the release notes, so most of the work is engineering judgment: where the admin password hash comes from, how each environment is pinned to a version, and how the pipeline proves the instance works before anyone relies on it. A partner makes more sense when the team has no spare capacity, lacks experience with these tools, or needs an independent review of the pipeline design. Decide based on your staffing and the scope you would hand over, then compare an internal estimate with a written scope from a partner.

What drives the effort of an automated authentik install?

Effort depends on four drivers: pipeline design, secret management, version pinning and testing. Pipeline design covers how many environments exist, whether each one is built from scratch or upgraded in place, and whether the install targets Docker Compose or Kubernetes. Secret management decides where the initial admin hash, database credentials and encryption keys live and who can read them. Version pinning sets how often the pipeline changes, because supported releases follow two lines, 2026.5.x and 2026.8.x. Testing covers the checks that confirm login works after each run. Each driver grows with the number of environments and the strictness of your change control, so ask any quote to price them separately.

What does an automated authentik install need from our side?

Plan on providing access to the CI runners that will execute the install, a secret store the pipeline can read from and write to, and a test environment that matches production closely enough to catch configuration errors. You also need named owners who can approve changes to bootstrap settings and someone who receives authentik release announcements. The installer will need access to the target cloud account, data center or air-gapped network. Ask the partner to list each access requirement in the written scope, including who holds it, how it is revoked, and what happens to pipeline secrets when the engagement ends.

Is automated bootstrap included in the authentik Open Source edition?

The authentik pricing page lists an Open Source edition at no cost with community Discord support, and it does not list bootstrap configuration among the enterprise-only features. The repository is mostly MIT licensed, while the code in the enterprise directory falls under a separate license. Before you build, confirm two things: that the version you pin includes the bootstrap settings and the hash_password command you plan to use, and that your intended use falls under the license terms for the files you deploy. Enterprise features such as Google Workspace or Entra ID integrations are a separate question and should be checked on their own.

How long does validation take for an automated authentik pipeline?

The duration depends on your pipeline, so no fixed figure applies. The main inputs are the install target, whether validation runs on every commit or only on release candidates, and how much of the post-install check is automated. A Docker Compose test stack is documented as needing a host with at least 2 CPU cores and 2 GB of RAM, so your runners must have at least that capacity. Kubernetes validation adds chart rendering, ingress and database connectivity checks. Ask for a timeline in the written scope that names each validation stage, the environment it runs in, and which steps need a person to sign off.

What changes for automated installs after upgrading to authentik 2026.8?

The main change is how the hash_password command receives its input. Since 2026.8, hash_password no longer accepts the password as a command-line argument. It reads from a hidden prompt or from standard input instead. A pipeline that passes the plaintext password as an argument must be changed, because that value can appear in the process list while the command runs. Update the step to pass the secret from your secret store on standard input, then test the install on a non-production instance. Read the authentik 2026.8 release notes for other changes that apply to your version path before you move production.

Which authentik versions should an automated pipeline pin?

Pin each environment to an exact release, then move that pin through a tested change. The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines that receive security fixes, and the project announces security releases at least 24 hours in advance. The pipeline therefore needs a way to receive that notice and test a patch quickly. The GitHub releases page lists 2026.8.4, published October 14, 2026, as the latest release, so confirm the current tag before you choose one. Keep a record of the version each environment runs, and treat an unpinned latest tag as a configuration defect.

How DeployOpen scopes an automated authentik install

DeployOpen scopes an automated authentik install as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before any work starts. For this topic, the written scope names the pipeline or configuration management tool that will run the bootstrap, the secret stores that will hold the initial administrator credential, the authentik release line the install will target, and the environments the pipeline will promote through. Each of those choices changes the work, so the scope should not be left open-ended.

The scope also covers secret handling in detail. It should state where the hash for AUTHENTIK_BOOTSTRAP_PASSWORD_HASH is generated, who can read it, how it is injected into the server and worker containers, and how the pipeline avoids echoing the value into logs. Because the hash_password command changed behavior in 2026.8, the scope must name the authentik version in use and the exact invocation the pipeline will call, so the team does not rely on a command pattern that a later release no longer accepts. Clients should confirm which runner images, CI log retention settings and vault access policies apply in their own environment before the scope is signed.

Verification is written into the scope as a separate deliverable, run against the client's environment rather than a lab copy. Typical checks include confirming that the initial administrator can sign in with the intended credential, that no plaintext password appears in process listings, shell history, pipeline logs or container inspection output, and that a rebuilt environment bootstraps the same way. The written scope should also say who receives the evidence, who owns the pipeline after handover, and how changes to the authentik version will be tested before they reach production. Clients should ask for these items explicitly when requesting a quote.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For automated installs, we agree on how bootstrap secrets are generated, delivered and rotated before any pipeline is written, so the admin credential never sits in a repository, a shell history or a process list.

How we scope

We confirm the authentik version, the deployment method and the hosting target before any bootstrap code is written.
We agree in writing which secret store, CI system or configuration management tool will hold and deliver the bootstrap hash.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and quotes follow from that written scope.

How we build

We write the install automation so the password hash is injected from a managed secret, never typed on a command line or committed.
We test the hash_password step on the exact authentik release you run, since the input method changed in the 2026.8 release.
We check that the automation fails safely on reruns and that no plaintext value appears in logs, job output or process listings.

How we hand over

You receive the pipeline or playbook code, a runbook describing where each bootstrap secret lives and who can read it.
We document the steps for retiring the bootstrap credential after the first administrator account is created and verified.
We walk your platform and security teams through the install, the rotation procedure and the checks used to confirm success.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can cover the automation as authentik versions change.
We review the install code when you move to a new authentik release, including changes to bootstrap settings and secret handling.
Ask us to confirm which authentik security releases apply to your deployment and how quickly your automation must be updated.

Automated authentik installs without plaintext admin passwords