0c43740a4e
* [FEATURE] Add command to generate self-signed certs in authelia binary. * Apply suggestions from code review Fixes #454 Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
2.7 KiB
| layout | title | parent |
|---|---|---|
| default | Deployment - Lite | Deployment |
Lite Deployment
Authelia can be deployed as a lite setup not requiring any SQL server, Redis cluster or LDAP server. In some cases, like protecting personal projects/websites, it can be fine to use that setup but beware that this setup is non-resilient to failures so it should be used at your own risk.
The setup is called lite since it reduces the number of components in the architecture to only two: a reverse proxy such as Nginx, Traefik or HAProxy and Authelia.
Reverse Proxy
Documentation for deploying a reverse proxy collaborating with Authelia is available here.
Please note that Authelia only works for websites served over HTTPS because the session cookie can only be transmitted over secure connections. Therefore, if you need to generate a self-signed certificate for your setup, you can use the dedicated helper function provided by the authelia binary.
# Generate a certificate covering "example.com" for one year in the /tmp/certs/ directory.
$ docker run authelia/authelia authelia certificates generate --host example.com --dir /tmp/certs/
You can see all available options with the following command:
$ docker run authelia/authelia authelia certificates generate --help
Discard components
Discard SQL server
It's possible to use a SQLite file instead of a SQL server as documented here.
Discard Redis
Connection details to Redis are optional. If not provided, sessions will be stored in memory instead. This has the inconvenient of logging out users every time Authelia restarts.
The documentation about session management is available here.
Discard LDAP
Authelia can use a file backend in order to store users instead of a LDAP server or an Active Directory.
To use a file backend instead of a LDAP server, please follow the related documentation here.
FAQ
Can you give more details on why this is not suitable for production environments?
This documentation gives instructions that will make Authelia non resilient to failures and non scalable by preventing you from running multiple instances of the application. This means that Authelia won't be able to distribute the load across multiple servers and it will prevent failover in case of a crash or an hardware issue. Moreover, users will be logged out every time Authelia restarts.
Why aren't all those steps automated?
We would really be more than happy to review any contribution with an Ansible playbook, a Chef cookbook or whatever else to automate the process.