Generated projects load environment variables through typed configuration.
Required database credentials, CORS origins, and authentication secrets are
validated before the server starts — malformed values are startup errors, not
runtime surprises.
Both generated .env.example files use blank lines to separate related
settings. Keep that grouping when adding a variable so local configuration
stays scannable; this reference remains the authoritative explanation of each
setting.
Runtime applications use the runtime/config package:
iferr:=config.LoadDotenv(".env"); err!=nil {
returnnil, err
}
cfg, err:=config.Load()
iferr!=nil {
returnnil, err
}
options:=cfg.Options() // then set UI, Database, Readiness, ...
LoadDotenv reads KEY=VALUE pairs and never overrides real environment
variables, so the environment always wins over .env. Keep .env local and
commit only .env.example. Outside development, DATABASE_URL and
CORS_ALLOWED_ORIGINS are required, and JWT_SECRET/SESSION_SECRET are
required when the feature that consumes them is enabled.
These variables are used by projects created with --auth --oauth. Set every
credential in one provider row or leave that provider entirely empty. Redirect
targets are local paths only.
Standalone projects read the same core, auth/session, and rate-limit
variables through internal/platform/config (the queue/cache/mail/storage
and WhatsApp subsystems are runtime features).
The runtime refuses unsafe production defaults, applies request timeouts
and body limits, and accepts trusted proxy CIDRs explicitly. Liveness never
depends on a database; readiness may check it with a short timeout. See
Deployment for production checklists.