Holobrain Portal

holobrain.inapp.holobrain.inbroker + vault boundary

Member portal first. Credentials never in the dashboard.

This scaffold assumes a public brand site on holobrain.in, a protected member dashboard on app.holobrain.in, and a separate credentialed runtime for dashboard connections, sync jobs, and sensitive processing.

Recommendation

Default stack

Portal UI: Next.js app routerPublic site, member portal, and operator views can live in one codebase with protected routes.

Identity + data: SupabaseAuth, Postgres, storage, and row-level authorization are all available without building that substrate yourself.

Secrets: Infisical first, OpenBao-ready laterInfisical is easier for client onboarding and operator UX; the broker boundary keeps the provider swappable.

Sensitive runtime: FastAPI broker + Playwright/API connectorsCredentialed work and browser automation stay outside the portal and outside the LLM.

Boundary

Hard separation rules

The browser never talks to the secrets vault directly.
Postgres stores metadata and secret references, not raw credentials.
The broker performs login, scraping, token exchange, and validation.
LLM-facing workflows consume normalized or sanitized data only.

Domains

Recommended host map

holobrain.inpublic site, docs, positioning

app.holobrain.inmember dashboard and onboarding

ops.holobrain.ininternal admin / operator surface

api.holobrain.inbroker / internal runtime endpoints

Decision

Why Infisical first

OpenBao is stronger as a long-term Vault-style secret engine. Infisical is the better v1 fit because it is easier to self-host, easier to administer, and friendlier when clients and operators need a browser UI. The broker should abstract the provider so you can swap later.