Platform Architecture

System Overview

The frontend and runner are fully decoupled. The runner never calls the frontend and the frontend never calls the runner directly — they communicate only through the shared database. This means the runner can be deployed independently, scaled horizontally, or replaced without touching the frontend.

Frontend

The Next.js frontend handles everything the user sees and interacts with:

The frontend uses Next.js server components for data-fetching pages (authentication, initial project state) and client components for interactive elements (the Blockly editor, backtest charts, live log stream). Authentication is handled by Supabase Auth with server-side session management.

Execution Runner

The hornpub-runner is a standalone Node.js process — not part of the Next.js app. It runs independently and communicates with Supabase as its only external interface (apart from Binance for klines and orders).

Key responsibilities:

• Project scheduling — claims due projects via a database RPC function on a 2-second poll loop.
• Kline management — maintains an in-memory KlineCache fed by InMemoryKlineManager, which fetches and refreshes data from Binance independently of project execution.
• Strategy execution — runs compiled JS per-project, per-symbol in a vm sandbox with the full strategy API surface.
• Broker abstraction — PaperBroker (simulated fills) and LiveBroker (Binance MARKET orders) share the same interface, making mode-switching transparent to strategy code.
• Structured logging — writes TRADE_TRIGGER and TRADE_EXECUTED log pairs for every trade, with full condition rows and slippage data.

Database

Norena uses Supabase (PostgreSQL) as its primary datastore. Supabase provides the database, row-level security policies, authentication, and realtime subscriptions — all in one managed service.

Row-level security is enforced at the database level so that every query — whether from the frontend's user session or the runner's service key — respects data ownership. Users can only access their own rows; the runner always scopes queries by owner_id.

Kline Data System

Live strategy execution uses an in-memory kline cache that is populated and maintained by the InMemoryKlineManager. This cache is completely separate from Supabase — market data never touches the database.

The manager discovers which symbols and timeframes to maintain by scanning active projects for their configured symbols and their compiled JS's timeframe manifests. When a new project goes live, its required series are automatically added to the refresh schedule.

In the backtest engine (frontend), klines are fetched on-demand directly from Binance when the user clicks Run Backtest. No cache is used — every backtest starts with a fresh fetch.

Scheduling

Project scheduling is managed through the database, not a cron job or external scheduler. Each project has a next_run_at timestamp. A PostgreSQL function (claim_due_projects) atomically selects and claims projects wherenext_run_at <= now() and updates their timestamp tonow() + interval_seconds in the same transaction.

This design provides several guarantees:

• Exactly-once claiming — no two runner instances can claim the same project simultaneously.
• No external scheduler dependency — the runner and database together are sufficient; no cron or queue service is needed.
• Catchup prevention — if the runner is briefly offline, projects will be claimed once when it restarts, not for every missed interval.

Data Model Overview

The core data model is intentionally small. These are the primary tables:

There is no separate strategies table — strategy data (compiled JS, workspace JSON) lives directly on the projects row. This keeps the model simple and queries fast for the common case of reading a project to run it.