Social LiveDocumentationPLATFORM DOCS

Admin Portal

The operator dashboard -what its pages do, how login works, and how it talks to the backend.

Last updated Thu Jul 16 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

TL;DR -The Admin Portal is the private web dashboard a small operator team uses to watch live rooms, search users, work the moderation queue, and tune app settings. It's a separate web app that reads everything through the backend's admin API, never the database directly.

Who this is for -Product & Business: the pages overview and what each screen is for. Operations & Support: all of it. Engineering: the auth model, proxy layer, and deployment at the bottom.

The Admin Portal is the "control room" for Social Live. When a support agent needs to look up a user, an operator wants to see how many rooms are live right now, or someone has to review a reported user, they open this dashboard. It is password-gated and only reachable by the operator team -regular app users never see it.

It is a separate website from the mobile app and from these docs. Think of it as three different buildings that happen to share a paint job: the phone app, this operator dashboard, and the public documentation you're reading now.

What each page does

The dashboard is organized into a handful of screens, each aimed at one job:

RoutePurpose
/dashboardKPIs (users, reports, withdrawals, coins) + Recharts analytics over daily series
/Live diagnostics: active rooms, participants, event logs
/usersUser search, profiles, ban/unban actions
/reportsModeration queue with per-report detail and actions
/settingsApp-level settings: media flags and the runtime gifting policy (guest split shares, settlement hold)
/loginAdmin token login

Every screen sits inside a shared frame (the "shell"). At the top is a broadcast-style status bar -ON AIR when rooms are live, STANDBY when quiet -showing the current live-room and participant counts. The sidebar has navigation with live badges (how many reports are open, how many withdrawals are pending) and a sign-out button. In code this is admin-shell.tsx, wrapping every page.

How it works

The portal is a Next.js 15 App Router application (admin/) built with React Server Components and a small client-side surface.

Authentication

The login is deliberately simple, because the operator team is small and trusted:

  1. ADMIN_ACCESS_TOKEN is set in the server environment.
  2. /login posts the token; on match the SHA-256 hash is set as the admin_session cookie.
  3. middleware.ts checks the cookie on every route (bypass only for /login and auth API routes) and redirects to /login otherwise.

In plain terms: there is one shared operator password (a token). You type it in, the server remembers a hashed version in a cookie, and every page checks that cookie before showing anything. The docs section inherits this automatically — nothing under /docs is publicly reachable from inside the admin console.

Backend access

The portal never talks to PostgreSQL itself. Instead it asks the backend, which owns all the real authority. lib/admin-fetch.ts wraps fetches to the backend's /api/admin/* endpoints with the admin credential; the generic app/api/admin/[...path] route proxies client-side actions the same way. All admin authority therefore lives in one backend module (backend/src/modules/admin/), where it is testable and auditable.

Every fetch is wrapped in try/catch with zeroed fallbacks -a backend blip degrades the dashboard to zeros instead of crashing the portal.

The documentation engine

These docs are not part of the admin console. They are a standalone, public portal -the docs-portal workspace -deployed to its own domain (DOCS_DOMAIN). It shares the admin console's visual language but carries no auth and no operational data.

  • Content: docs-portal/content/docs/**/*.md (folders = sections, numeric prefixes = order, frontmatter = title/description/updated).
  • Renderer: docs-portal/app/[[...slug]]/page.tsx reads the filesystem per-request; react-markdown + GFM + syntax highlighting; ```mermaid fences render as diagrams client-side.
  • Navigation: sidebar tree is generated from the folder structure, with client-side title search; per-page table of contents from headings; prev/next from reading order.
  • Public: never commit real secrets to a docs page -placeholders only.
  • Updating: edit Markdown → rebuild the docs container. See the docs home for the full workflow.

Deployment

The portal is built by admin/Dockerfile (Node 22 alpine, workspace install, next build), served on port 3011 behind nginx:

docker compose -f docker-compose.prod.yml --env-file .env.production up -d --build admin