Authelia Authentication: From Bootstrap Scripts to Secure Credentials

Authelia Setup: Securing the Admin Panel Behind the Scenes

The borisovai-admin project needed proper authentication infrastructure, and the developer faced a common DevOps challenge: how to manage credentials securely when multiple services need access to the same authentication system. The task wasn’t just about deploying Authelia—it was about understanding where passwords live in the system and ensuring they won’t cause midnight incidents.

The work started with a straightforward request: apply the changes to the installation scripts and push them to the pipeline. But before deployment, the developer needed to answer a practical question that often gets overlooked: where exactly are the credentials stored, and how do we actually use them?

First, the developer examined the Authelia installation script—specifically lines 374–418 of install-authelia.sh. This is where the bootstrap happens. The default admin account gets created with a username that’s hardcoded in every Authelia setup: admin. Simple, memorable, and apparently universal. But the password? That’s where it gets interesting.

The password isn’t just sitting in a configuration file waiting to be discovered. Instead, it’s derived from the Management UI’s own authentication store at /etc/management-ui/auth.json—a pattern that creates a useful single source of truth. Both systems use the same credential, which simplifies the operations workflow. When you need to authenticate to Authelia, you’re using the same password that secures the management interface itself.

Inside /etc/authelia/users_database.yml, the actual password gets stored as an Argon2 hash, not plaintext. This is a critical detail because Argon2 is specifically designed to be slow and memory-intensive, making brute-force attacks computationally expensive. It’s the kind of defensive measure that doesn’t seem important until you’re reviewing logs at 3 AM wondering if your authentication layer has been compromised.

The developer committed these changes in e287a26 and pushed them to the pipeline, which would automatically deploy the updated scripts to the server. No manual SSH sessions required—the infrastructure as code approach meant the deployment was reproducible and auditable.

What makes this work pattern valuable is the practical transparency it provides. By understanding exactly where credentials live and how they’re stored, the developer created documentation that future maintainers will actually use. When someone inevitably forgets the admin password six months later, they’ll know to look in /etc/management-ui/auth.json instead of starting a frantic password reset procedure.

The lesson here isn’t about Authelia specifically—it’s about building systems where the authentication story is clear and consistent. Single sources of truth for passwords, transparent storage mechanisms, and infrastructure that can be reproduced reliably. That’s how you avoid the scenario where nobody remembers which password works with which system.

😄 Why did the functional programmer get thrown out of school? Because he refused to take classes.