dograhai/dograh-api and dograhai/dograh-ui images work as-is; you do not need to rebuild or build from source.
The active provider is controlled by the backend
AUTH_PROVIDER variable (local by default). The frontend discovers the provider β and, for Stack, its public client config β at runtime from the backendβs /api/v1/health response, so the browser bundle never needs Stack values baked in at build time.How it works
- The backend reads
AUTH_PROVIDERand the Stack settings from its environment. - When
AUTH_PROVIDER=stack,/api/v1/healthreturns the public Stack client config (project id + publishable client key). - The UI fetches that at runtime and initializes the Stack SDK in the browser.
- The secret server key is used only server-side (by the backend and the UIβs server runtime) and is never sent to the browser.
Prerequisites
A Stack Auth project. Create one in the Stack Auth dashboard and configure the social login providers you want to offer.Step 1 β Collect your Stack credentials
From your project in the Stack Auth dashboard, gather:Step 2 β Configure the backend (api)
Set these on the api service. Add them to the environment: block of the api service in your docker-compose.yaml:
docker-compose.yaml
Step 3 β Configure the UI (ui)
The UI runs server-side code (SSR pages and the /handler/* auth routes) that calls Stack with the secret server key, so the ui service needs that one value too:
docker-compose.yaml
The
ui service does not need the project id or publishable client key β it receives those from the backend at runtime via /api/v1/health. Only the secret server key (used server-side) is set here.Step 4 β Restart and verify
Recreate the containers so they pick up the new environment:Environment variable reference
Reverting to local auth
Remove the variables above (or setAUTH_PROVIDER=local) and restart. The UI detects local from the backend at runtime and falls back to the built-in email/password flow β no rebuild required.