Docs

Admin and operations

Roles, the operations console, invite codes and what is deliberately read-only.

Who can operate

Staff access starts with environment allowlists: ADMIN_USER_IDS members are administrators, SUPPORT_USER_IDS members are read-only support. Stored roles (user, ops, admin) let you grow the team without redeploying, and environment allowlists always outrank stored values.

Effective permissions: support can read, ops can read and also block accounts, adjust credits and manage invites, while only admins can change roles. Authority is re-resolved inside every write transaction, so a blocked or demoted operator loses power immediately — not after a session expires.

The operations console

The /admin tabs cover users, subscriptions, provider-synchronized orders, invite codes, the audit trail and settings. Blocking an account requires a reason, revokes sessions and cannot target protected staff accounts; restoring is symmetric. Credit adjustments accept a positive or negative integer with a reason and create one immutable audit row each.

The audit page is append-only by database rule: reasons, request keys and detail snapshots cannot be edited or deleted, and every mutation is replay-safe under a request key so a retry after a timeout cannot double-apply.

Invite codes

Administrators and operators generate codes in the Invites tab: server-generated, human-readable, bounded by uses and an optional UTC expiry, and disablable exactly once. A logged-in customer redeems through POST /api/invite-code/redeem with a same-origin JSON request.

Redemption is attribution only: it increments the code's use counter and writes an audit row identifying the redeemer. It never grants credits — invites and money stay separate books. Disabled, expired and used-up codes fail with distinct errors, and redeeming twice returns the recorded result instead of consuming a second slot, so a network retry is safe.

Settings and verification

The settings tab is read-only by design: it reports module configuration, provider names and readiness, and the effective staff roster with each entry's source (environment or database). Secrets and provider switching stay in environment variables.

As everywhere in this starter, configuration presence is not verification. After changing providers or roles, walk the launch verification journeys again rather than trusting a green badge.