Architecture

VECTOR is a conventional three-tier web application. This page explains what runs where and how a request flows — useful if you're evaluating the system or just curious.

Components

Layer	Technology	Hosted on
Frontend	Next.js (App Router), React, TypeScript, Tailwind, Recharts	Vercel
Backend	FastAPI (Python), NumPy / pandas / SciPy for the maths	Render (Docker)
Auth & database	Supabase (Postgres + Auth)	Supabase

The frontend renders the UI and charts; the backend owns the analytical engines (equity aggregation, metrics, Monte Carlo, correlations, risk sizing); Supabase handles identity and persistent storage.

Request flow

Browser ──▶ Next.js (Vercel) ──▶ FastAPI (Render) ──▶ Session manager (in-memory)
                                       │                       │
                                       ▼                       ▼
                               Auth verification          Math engines
                              (Supabase JWT)            (NumPy/pandas/SciPy)
                                       │
                                       ▼
                                Storage (files / Postgres)

The browser calls the API with a bearer token.
The backend verifies the token and resolves your user_id.
The request is served from your in-memory session (or persisted storage).
Engines compute the result and return JSON; the frontend draws it.

No broker, no orders

There is no connection to any broker or exchange, no order routing, no live market data and no fund custody. The backend only ever processes the historical P/L you upload. See Security.

Sessions

Your working set lives in an in-memory session keyed to your user_id:

Time-to-live: 24 hours, swept periodically.
Not persisted — a backend restart (e.g. a deploy) clears live sessions.
Isolated — a session can only be read by the user who owns it.

This is why the app distinguishes the temporary session from things you explicitly save or freeze. See Core concepts.

Storage

Persistence goes through one storage abstraction with two backends:

File storage — local development; JSON and CSV under a per-user folder.
Postgres storage — production; a single user_data table keyed by (user_id, kind, name).

The kind discriminates the data: portfolios, strategies, variants, history, and the trade-level CSVs used by Risk Sizing. Either backend is strictly per-user.

Authentication (dual-mode)

The backend accepts two auth regimes so the same code runs locally and in production:

Supabase (production) — an Authorization: Bearer <jwt> header, verified by shared secret (HS256) or by Supabase's public keys (JWKS). Your user_id is the Supabase UUID.
Legacy cookie (local dev) — a backend-signed JWT cookie; the user_id is a username.

Routes are protected on both ends: the frontend guards /analysis/*, and every backend route requires a verified identity. More in Security.

Deployment

Frontend deploys to Vercel on push; the backend is a Docker image on Render; Supabase provides auth and the database. Configuration is entirely via environment variables — no secrets in the code.