Skip to content
Reference

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.

main.py
auth = FastAuth(engine=engine, production=True)
# or set the environment variable FASTAUTH_PRODUCTION=1

With production=True, FastAuth:

  • Requires a real secret key: 32+ characters from the SECRET_KEY environment variable; it will not invent one
  • Sends cookies only over HTTPS: cookie_secure defaults to True
  • 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.

Set SECRET_KEY in your host's environment, not in a .env file you deploy. Either works, but the environment takes precedence, so a stale .env in an image cannot quietly override the key your platform provides. Signing tokens with an unexpected key logs everyone out with nothing in the logs to explain it.

Deploy checklist#

  1. Set SECRET_KEY in your host's environment
  2. Turn on production=True (or FASTAUTH_PRODUCTION=1)
  3. Serve over HTTPS (your host or reverse proxy handles the certificate)
  4. Create the superadmin with a strong, unique password
  5. Swap SQLite for a server database if you expect real traffic (any SQLModel/SQLAlchemy engine works: PostgreSQL, MySQL, and so on)
  6. Run with uv run fastapi run main.py (the production server, instead of fastapi 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.