.env.example

# Copy this file to .env and fill in real values before starting the server.

# Required. A long random string used to sign login cookies.
# Generate one with: openssl rand -hex 32
JWT_SECRET=

PORT=3000

# --- Database ---
# Set this to use Postgres (recommended). Leave blank to keep using the
# SQLite file at DB_PATH.
#
# On first boot with this set, if the SQLite database still exists and the
# Postgres database is empty, the server migrates your data across
# automatically, verifies it, and only then starts serving. Your SQLite file
# is never modified or deleted - to roll back, blank this out and restart.
#
# Either postgresql:// or postgres:// works - they are the same scheme to
# the driver. The host must not be `localhost` from inside a container - use
# the Postgres container/host's own address (e.g. its Docker Compose service
# name, or the host's LAN IP on Unraid).
DATABASE_URL=

# Where the SQLite database lives. Still used as the migration source even
# after DATABASE_URL is set, so do not remove the volume mapping.
#
# Left commented on purpose. The default is <repo>/data/rackstack.db, which
# is what you want for local development; /app/data only exists inside the
# container, where the Dockerfile sets DB_PATH itself. Setting the container
# path here would make `npm run dev` fail at startup, because the SQLite
# driver creates the parent directory and a normal user cannot mkdir /app.
# DB_PATH=/app/data/rackstack.db

# Comma-separated user ids (provider:providerId, e.g. github:37058311,
# discord:123456789012345678) that are always treated as owning every role
# (admin + event_coordinator), regardless of what's stored in the DB. This
# is the only way to reach any admin route (the balance-tuning dashboard,
# roles management, the user list) - there's no other way to bootstrap the
# first admin, so set this to your own id or nobody, including you, will
# have admin access. Log in once first if you don't know your id yet.
# Leave blank to disable admin access entirely.
SUPER_ADMIN_IDS=

# --- Authentication stack (v1.8) ---
# Which login stack runs. Leave blank unless you are actively rolling out
# SuperTokens - blank means the stack RackStack has always used.
#
#   passport     (default) Exactly as before. SuperTokens is not initialised,
#                and its SDK is not even loaded. Upgrading to v1.8 without
#                setting this changes nothing about how anyone logs in.
#   dual         Both login paths work; a session from either is accepted.
#                This is where the rollout happens. Existing login cookies
#                keep working for their full 90-day life.
#   supertokens  SuperTokens only; the old OAuth routes are switched off. The
#                client gained a SuperTokens login flow and token refresh in
#                v1.9, so this is implemented - but it has not yet been proven
#                against a real core on a real deployment, because a v1.8 bug
#                (providers registered under a key the SDK ignores) made every
#                SuperTokens login impossible until v1.9 fixed it. Reach this
#                mode through `dual`, never directly. See
#                docs/authentication-methods.md Phase 5.
#
# Rolling back is setting this back to passport (or blanking it) and
# restarting. Existing login cookies stay valid through every transition in
# both directions, so nobody is logged out by changing this.
#
# An unrecognised value stops the server on purpose rather than quietly
# falling back, so a typo can't look like a completed rollout.
# AUTH_MODE=

# Where the SuperTokens core container is reachable. Only read when AUTH_MODE
# is dual or supertokens. Two things the SuperTokens core is fussy about:
# the scheme must be postgresql:// (it rejects postgres://, unlike DATABASE_URL
# above, which accepts either), and it needs its OWN database - point it at a
# separate database on the same Postgres server, never at the rackstack one.
# SUPERTOKENS_CONNECTION_URI=http://supertokens:3567

# API key for the SuperTokens core. NOT optional for any core that is not on
# loopback: a core without one serves its whole API unauthenticated, and that
# API mints a session for ANY user id - including every value in
# SUPER_ADMIN_IDS - without a single request reaching RackStack. The server
# refuses to start in dual/supertokens mode if the core is remote and this is
# unset. Generate with `openssl rand -hex 32`, and set the same value as
# API_KEYS on the core container. Do not publish the core's port either.
# SUPERTOKENS_API_KEY=

# The public origin this server is reached at, e.g. https://rackstack.example.com
# Only needed when AUTH_MODE is dual or supertokens. Leave blank and it is
# derived from GITHUB_CALLBACK_URL / DISCORD_CALLBACK_URL below, which is
# correct for almost everyone - set it explicitly only if you sit behind a
# proxy where the public origin differs from your OAuth callback host.
# PUBLIC_ORIGIN=

# --- Discord OAuth ---
# Create an app at https://discord.com/developers/applications
# -> OAuth2 -> add a redirect matching DISCORD_CALLBACK_URL below
#
# Enabling SuperTokens later: ADD a second redirect URI,
# https://your-domain.example.com/auth/callback/discord, alongside the one
# below. Discord permits several. Keep both - passport uses the one below and
# keeps working. Leave DISCORD_CALLBACK_URL itself unchanged.
DISCORD_CLIENT_ID=
DISCORD_CLIENT_SECRET=
DISCORD_CALLBACK_URL=https://your-domain.example.com/auth/discord/callback

# --- GitHub OAuth ---
# Create an app at https://github.com/settings/developers -> New OAuth App
# -> Authorization callback URL must match GITHUB_CALLBACK_URL below
#
# Enabling SuperTokens later: WIDEN the app's registered Authorization callback
# URL to the parent path https://your-domain.example.com/auth . GitHub requires
# a redirect URL to be a subdirectory of what is registered, and SuperTokens'
# /auth/callback/github is NOT a subdirectory of /auth/github/callback - so
# without this, every SuperTokens GitHub login fails with a redirect_uri
# mismatch. Widening is additive and reversible: both paths then qualify and
# passport keeps working throughout. Do it BEFORE setting AUTH_MODE, and leave
# GITHUB_CALLBACK_URL below unchanged - it tells passport where to send people.
GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
GITHUB_CALLBACK_URL=https://your-domain.example.com/auth/github/callback

# Leave a provider's ID/SECRET blank to disable it - the login screen still
# shows both buttons, but an unconfigured provider will fail on click.