Where Does Self-Hosted 2FAuth Store Data?
2FAuth keeps accounts in database.sqlite inside a /2fauth volume. Settings arrive via .env with APP_KEY mandatory.
Last updated
2FAuth splits into env and volume. The .env/settings file (or compose env) carries APP_KEY (mandatory, unique per install), APP_URL, and DB_CONNECTION (SQLite default, MySQL/PG optional). The /2fauth volume holds database.sqlite with every account secret, encrypted under that key. Bare installs use database.sqlite under the web root instead.
The container runs as 1000:1000, so host folders need that ownership with tight perms before first start. Updates only need an image pull plus restart, but the docs bold the precondition: back up database.sqlite first. Existing SQLite files drop in by path and get picked up automatically, which is also the migration story.
Where 2FAuth stores this, by platform
/2fauth (Docker volume)
database.sqlite with all account secrets, encrypted under APP_KEY. Mount persistently with 1000:1000 ownership, mode 700. Existing files drop in by path. Back before every image update.
Frequently asked questions
how do i back up 2fauth
Copy database.sqlite from the /2fauth volume (chown 1000:1000, chmod 700) plus your .env/settings file with the container stopped. Secrets travel in the db encrypted under APP_KEY, so the key and the file must move together.
how do i generate the 2fauth app key
Generate a unique 32-char string (Laravel key generator works) and set it before first boot; upgrades and reinstalls reuse it. Losing APP_KEY against an kept database locks every account with no recovery path.
Notice an outdated path? Let us know.