For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/admin.md (or send Accept: text/markdown).
Admin console
Platform inspection, announcements, and feature flags.
Beginner walkthrough
Prerequisites: Read the two beginner guides below, finish Web local setup, and open this monorepo at its root in your editor. Web settings belong in apps/web/.env.local; Next.js does not read the root .env. /dashboard in the default fake mode is a no-database demo; /auth needs a migrated database.
Quick terms: a workspace is one team's separate users, data, and settings. The server is the trusted backend; keep provider keys out of browser and phone code. A migration is a versioned database change that creates or updates tables. An AI model is the engine that answers; the model catalog is the server's list of available model IDs and prices. A provider is an outside service such as an AI, email, or billing service. An entitlement is a grant that lets a workspace use a feature. A webhook is a message one service sends to another service's URL.
1. Before creating a local test account, add your own address to the server-only ADMIN_EMAILS list and restart the app.
2. Sign up on the migrated test database and open /admin; inspect the available user and organization pages.
3. This grants platform admin, not workspace ownership. If access is denied, verify the exact email and server configuration; do not elevate arbitrary users or test against production.
For custom code, start with the supplied prompts/README.md and copy the closest prompt: prompts/new-app-screen.md for an app screen or prompts/new-landing-page.md for a public page. For server, database, or provider work, give your coding agent this guide's task and ask it to read AGENTS.md, .ai/PROJECT_CONTEXT.md, and matching .ai/ mirrors; inspect the exact source files named here; list files and checks before editing; preserve workspace ownership and server-only secrets; and show you the diff. Tell it the behavior you want, input and output fields, allowed roles, expected success and errors, and the test account, provider, or device. Use sample values; never paste a real secret.
Create the admin boundary
ADMIN_EMAILS is a server-only comma-separated bootstrap list. Listed users receive the platform admin role on signup. Without it, grant access through an authorized database/admin path; do not make the first arbitrary visitor an admin.
Platform admin is distinct from workspace owner/admin. /admin and its user, organization, flag, announcement and waitlist pages check the platform role.
Use the implemented controls
The default Better Auth engine provides admin user management, bans and impersonation. The app composes platform views with audit trails. Restrict impersonation to verified admin access, make its state visible and restore the original admin session on exit.
Auth.js does not automatically inherit Better Auth admin plugins. Review admin.ts, admin-actions.ts and auth-provider behavior before switching engines.
Verify privileged actions
Test non-admin denial, admin access, banned-user sessions, impersonation start/stop and the actions you enable. Keep all admin routes outside public indexing.
Setup and configuration
The /admin surface is the operator's inspection view over workspaces, members, and product state. ADMIN_EMAILS (or the admin plugin configuration in the consuming product) decides who reaches it; every admin route re-checks authorization on the server.
Feature flags (feature-flag-runtime.ts) default-off anything unconfigured — a missing flag can never silently enable a surface — and per-flag overrides live in the featureFlagOverride table.
/admin operator dashboard
announcement-actions.ts broadcast in-app notices
resolveFeatureFlags(...) bulk flag resolution for a caller contextImplementation workflow
Use admin actions for inspection and support operations (workspace lookup, member management, announcement broadcast). Keep mutations audited and authorization checked at the action boundary, not the nav.
Roll features out behind flags: ship code dark, enable per workspace or globally, and remove the flag once the surface is permanent. Platform impersonation stays frozen unless the product's PRODUCT.md explicitly authorizes it.
Verification and troubleshooting
Verify a non-admin is denied, a disabled flag hides its surface end-to-end (nav, route, action), an override resolves only for its target, and announcements reach the intended audience. Admin tests should cover the denied path first.