Going to production
Built something locally and want to ship it? One flag turns on the safety rails, and FastAuth refuses to start with unsafe settings.
With production=True, FastAuth:
- Requires a real secret key: 32+ characters from the
SECRET_KEYenvironment variable; it will not invent one - Sends cookies only over HTTPS:
cookie_securedefaults toTrue - Refuses the default admin password: creating a superadmin without an explicit, non-default password is an error
Need a key right now? Here is one, generated in your browser:
Generate a secret key
32 random bytes, hex encoded — press Generate
Generated in your browser and never sent anywhere. Put it in SECRET_KEY in your environment, not in your source code.
Deploy checklist#
- Set
SECRET_KEYin your host's environment - Turn on
production=True(orFASTAUTH_PRODUCTION=1) - Serve over HTTPS (your host or reverse proxy handles the certificate)
- Create the superadmin with a strong, unique password
- Swap SQLite for a server database if you expect real traffic (any SQLModel/SQLAlchemy engine works: PostgreSQL, MySQL, and so on)
- Run with
uv run fastapi run main.py(the production server, instead offastapi dev)
Changing your models later? SQLModel's create_all only creates missing
tables; for schema changes on a live database, add
Alembic migrations. Upgrading FastAuth
itself works the same way: v0.6.0 added the email_verified and
token_version columns, so existing databases need
ALTER TABLE user ADD COLUMN ... (or an Alembic revision); dev SQLite files
can simply be deleted.