SterlingIndex Docs

Architecture Overview

Start here for the SterlingIndex system map and the documentation surfaces hosted by this app.

SterlingIndex ships as public, product, operator, and documentation surfaces plus one shared backend runtime. The current deployment shape keeps www and docs on Vercel, dashboard on Cloudflare Pages, the active admin in apps/admin-desktop as an Electron desktop control room, apps/admin-mcp as a local stdio MCP control surface for agent-driven operator work, and the API/worker/scheduler/Postgres/Redis stack on a dedicated Contabo VPS. The hosted control plane can also coordinate an optional macOS scrape node for browser-stealth and local-model work without changing the product-facing deployment shape. This portal is the engineer-onboarding view of that system: what each surface owns, how they connect, which shared package or secret path carries the contract, and which repository files prove it.

Start here when you need to answer four questions quickly:

  • which app or service owns a behavior,
  • which shared package or environment variable crosses that boundary,
  • which secret source of truth or sync path owns the runtime value,
  • which verification surface should change with the code.

System At A Glance

apps/www        -> public marketing experience on the root www host
apps/dashboard  -> customer product frontend
apps/admin-desktop     -> active Electron control-plane frontend
apps/admin-mcp         -> local stdio MCP operator adapter
apps/legacy-admin      -> legacy hosted control-plane reference
apps/docs       -> standalone documentation app with shared dashboard-login handoff
        \              |               |            |             /
         \             |               |            |            /
          -------- services/platform-api ------------------------
                     shared auth, data, jobs,
                   runtime readiness, and workers
                              |
                optional macOS scrape-local worker

Read This In Order

  1. Frontend Apps to understand the public, product, admin, and docs surfaces.
  2. Shared Packages to see the auth, contract, and client seams those frontends rely on.
  3. Platform API to trace the backend runtime that serves both product and control-plane flows.
  4. Infrastructure to map domains, env vars, Infisical ownership, and deployment assumptions across the stack.

Architecture Map

Portal Conventions

  • File paths are written as repo-safe code references such as apps/dashboard/src/App.tsx, not repo-relative Markdown links that break after publication.
  • Cross-links are organized by ownership: app surface first, shared contract second, infrastructure/deployment last.
  • The docs app lives independently at apps/docs, serves docs.sterlingindex.com, redirects the root route to /docs, and uses the same shared dashboard-login handoff contract as the other public surfaces.

On this page