Where Does Self-Hosted SuperTokens Store Config?
SuperTokens reads config.yaml at /usr/lib/supertokens (or env vars) with users in Postgres. File wins when both exist.
Last updated
SuperTokens centers on config.yaml with API keys, hosts, token lifetimes, hashing, and Postgres wiring. Docker mounts it at /usr/lib/supertokens/config.yaml, or env vars carry the same keys (file wins when both exist). Bare installs edit the install-dir copy found via supertokens --help. Logs default to docker logs unless paths point at volumes.
Users live in Postgres 13+ (sole supported backend now; MySQL/Mongo dropped in v11). License keys gate features and arrive via dashboard plus API call. The in-memory default has ended more than one pilot: anything beyond a smoke test needs the database line set first, with the network arranged so only Core reaches it.
Where SuperTokens stores this, by platform
/usr/lib/supertokens/config.yaml (Docker)
Keys, hosts, lifetimes, Postgres wiring. Docker path /usr/lib/supertokens/config.yaml; file beats env when both set. Bare installs edit the install-dir copy. Never persist secrets in images.
Frequently asked questions
how do i back up supertokens
Copy config.yaml (or record the env) plus a Postgres dump with the service stopped. Users, sessions, and tenants travel in the database; hosts, keys, and log paths in config. Restore both; never run production on the default in-memory db.
is the default supertokens database persistent
Only for trials. Without Postgres env the container boots an in-memory database that evaporates on recreate. Set POSTGRESQL_CONNECTION_URI (or user/host/password vars) before real users arrive; there is no upgrade path from memory to Postgres.
Notice an outdated path? Let us know.