ONIX Web Product Overview¶
ONIX's web product is a TypeScript/Next.js client, developed in the onix-frontend repository (its npm package is still named onix-lab, and a handful of routes and internal symbols carry that older name as an identifier, not as a description of the product). It runs as a single Next.js service — next dev --port 3117 in development, next start --port 3117 in production — and is designed to be deployed on general-purpose hosts such as DigitalOcean droplets. It ships no server-side database of its own and no execution engine of its own. Everything it shows is either read from, or relayed to, a separate backend: the onix-backend repository, which composes a locked, official NautilusTrader release into ONIX's own services.
The boundary, stated plainly¶
The repository's own instructions (AGENTS.md) draw the line this way: the backend owns instruments, market data, aggregation, catalog storage, strategies, backtests, portfolio, risk, orders, execution, runtime lifecycle, and the governed gateway/MCP contracts that describe all of it. The frontend owns presentation, interaction, workspaces, editors, browser-local state, contract validation of what the backend sends, datafeed adaptation for the charting library, and UI projections of backend documents. It is explicitly told not to add direct exchange connections, venue adapters, market-data aggregation, catalog storage, trading state, portfolio/risk logic, or an execution engine of its own — and, if a backend fact is missing, to record that as a documented gap rather than to synthesize an answer in the browser. That instruction is echoed throughout the code: the datafeed's getBars implementation, for example, explicitly declines to answer noData: true because doing so would be "a claim about the SOURCE" that "nothing this datafeed can currently see proves" (src/datafeed/gateway-datafeed.ts).
This document describes the client/presentation layer only. Where a page in this section states a fact about market data, backtesting, or execution, that fact is a claim about what the ONIX backend and NautilusTrader publish, not something the frontend computes or guarantees on its own.
The surfaces this build ships¶
At the reviewed pin, the Next.js app router serves six pages and four same-origin API routes
(src/app/**, enumerated in evidence/frontend/route-inventory.md):
/dashboard— the primary trading workspace: a modular, resizable shell (left/center/right/bottom zones) hosting the licensed Advanced Charts widget, a live watchlist, a screener, the Strategy Workbench (Strategies / Studio / Backtests), venue connections, and the official Nautilus runtime documents (account, orders, fills, positions, portfolio, performance report, and a private-operator-gated order ticket). This is the product surface described in dashboard-and-workspaces.md./workspace-v2— a second, newer workspace foundation: one gateway session, a bounded and strictly-validated layout document, and a compile-time-frozen widget catalog. At this pin its frozen catalog holds nine widget types; module comments describe the chart and the Strategy Studio as this surface's original "proof widgets," and the catalog has since grown to include the Strategy Manager, Backtests, four runtime execution-table widgets, and a development-only status widget (src/workspace-v2/registry.ts)./workspace— an older, resizable multi-pane console showing versioned Nautilus DTOs (bars, causation chain, audit rail) largely unchanged from an earlier phase of this project. The app's own navigation labels it "Panels" and treats it as a secondary tool, not the product surface (src/components/app-nav.tsx)./lab— an internal console rendering engine facts (canonical identity, closed bars, the signal causation chain, recomputed identity hashes) exactly as the backend publishes them. Labelled "Console" in navigation./admin— a console rendering the real integration topology and capability state the backend'sonix.integration_capabilitydocuments describe, grouped by kind — explicitly "not a hand-drawn diagram."/redirects to/dashboard.
app-nav.tsx's own comment is explicit about the hierarchy: /dashboard is "the primary Onix trading workspace," while /lab, /workspace, and /admin are "the pre-existing internal consoles: kept reachable, but styled as secondary tools rather than the product surface." This document treats /dashboard and /workspace-v2 as the product surfaces proper, and the other three as internal/diagnostic consoles — private-test-stage in this register's vocabulary, in the sense that they exist and are reachable but are not the surface a general user is steered toward.
How the frontend reaches the backend¶
Every backend read or write goes through a same-origin Next.js API route, /api/engine/[...path], which proxies to one of two backend gateway processes selected by server-side environment variables (ONIX_SPINE_GATEWAY_URL, ONIX_ENGINE_GATEWAY_URL) — never dialed directly from the browser, and never configurable by a client request. The proxy's own comment states its reason for existing plainly: "the gateway binds loopback only and publishes no CORS contract, so the browser cannot reach it directly." This proxy is also the trust boundary for anything that mutates backend state — see gateway-realtime.md for the deployment-mode gate that decides, per host, whether any mutation route is relayed at all.
The frontend does not invent backend facts it cannot obtain. Where a capability is absent, withheld by deployment mode, or not yet published by the backend at this pin, the UI is built to say so explicitly (UNAVAILABLE, UNPUBLISHED, NOT_PUBLISHED, or a named contract-request document) rather than to guess, retry silently forever, or render a plausible-looking placeholder.
What this is not¶
This is not a standalone trading engine. It has no direct venue connectivity, no order-matching, no portfolio accounting, and no market-data aggregation logic of its own; every one of those facts, where shown, is a projection of a document the ONIX backend (via its NautilusTrader composition) published. It is also not a multi-tenant identity system: when this pin's source was searched, no user login, session, or account-management surface was found (see gateway-realtime.md and evidence/frontend/open-questions.md for exactly what that search covered — a negative claim like this is bounded by the search performed, not exhaustively proven). The one identity-like boundary that does exist is a two-valued, server-side deployment mode — private-operator versus public-readonly — decided by the host's own configuration, not by who is looking at the page.
This page, and every page in this section, describes the development frontend pin (99f49dae6368414896bf2858cb848f5a7c7fcf98) named at the top of this document. A separately tracked production release record exists for this repository and pins an older commit; this section's pages were not diffed against it, and nothing here should be read as a claim about what a currently deployed production build ships — see evidence/frontend/contract-pin.md for the production record's commit/tree and why it was not reverified.
A small, closed browser-automation surface also exists for the chart and its own widgets, meant for locally attached development/support tooling rather than as a general product feature; see chart-mcp-bridge.md.
The remaining pages in this section describe, with citations to the code at the pinned commit, how the chart and its datafeed work, how the dashboard and workspaces are composed and persisted, what the screener surface does versus what the backend screener engine does, how strategy authoring and backtesting are presented, how the gateway/BFF layer is shaped, and how client-side state and caching are organized.
Evidence and source pins for this page
Verified. Current behaviour, confirmed in source at the pinned commit.
Verified on against the following immutable sources:
frontend@99f49dae:AGENTS.mdfrontend@99f49dae:package.jsonfrontend@99f49dae:src/app/page.tsxfrontend@99f49dae:scripts/engine-pin.mjs
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.