Architecture
Apex is split across a hosted control plane and a user-controlled data plane, connected by a signed WebSocket relay. The split is the entire point: it lets you operate the engine from anywhere (browser, phone) while keeping the broker credentials and trade-execution surface on hardware you own.
Two halves, one product
┌───────────────────────────────┐
│ Fusion-hosted (Vercel) │
│ │
user's browser ────HTTPS───▶│ apex-cloud (Next.js) │
│ - dashboard, auth, audit UI │
│ - issues registration JWTs │
│ - reads engine state via … │
│ │
└─────────────┬─────────────────┘
│
│ HTTPS GET /v1/state/:tenant
▼
┌───────────────────────────────┐
│ Fusion-hosted (Fly) │
│ │
│ apex-relay-server │
│ - WS endpoint /v1/engine │
│ - in-memory tenant→socket │
│ - validates registration JWT │
│ - caches latest snapshot │
│ │
└─────────────▲─────────────────┘
│
│ WSS signed JWT in Hello
│ Snapshot every 10s
│ AuditEvent broadcast on
│ every recorded event
│ Command + Ack for cloud-side
│ ops: cancel_orders, flatten,
│ start/stop strategy,
│ register_gate, set_broker_creds
│
┌─────────────┴─────────────────┐
│ USER-CONTROLLED hardware │
│ (Hetzner, NUC, laptop, k8s) │
│ │
│ apex serve │
│ - holds broker credentials │
│ - executes trades │
│ - writes Cortex audit chain │
│ │
│ ──── broker over HTTPS ───▶ │
│ (Alpaca, IBKR, …) │
└───────────────────────────────┘
Why this shape
Three audiences for one codebase:
Individual trader. Wants algorithmic trading on their own broker, wants the dashboard reachable from their phone. Rents a $10-30/mo VPS, runs apex serve --register …, watches state in cloud.apex.fusion.dev.
Self-host enthusiast. Same shape with the engine on a home server or NUC. Same UI.
B2B integrator. Wants Apex as a developer API surface. Runs the engine in their own infra (Kubernetes, on-prem, whatever), uses the cloud dashboard for visibility OR builds their own UI on the same apex-api surface.
All three share the exact same codebase. The deployment shape adapts.
The security boundary
This is the load-bearing architectural commitment. The full per-resource breakdown lives in Security; the short version:
Broker credentials never leave your hardware. Fusion never sees them. Trade execution is the engine's job; the cloud can't call Broker::submit_order because it doesn't have credentials to call it with.
The Cortex audit chain (signals, gates, orders, fills) lives on your hardware. The relay sees event-level summaries; full per-decision context stays in your SQLite chain.
Tenant configuration (gate thresholds, market timezone, per-strategy params) is engine state. The cloud reads it via snapshots but doesn't own it.
Registration tokens are issued by the cloud, validated by the relay, treated as opaque by the engine. Rotate from the engine dashboard if one leaks.
Compromising the relay-server gives an attacker: snapshots (equity numbers, position counts). It does NOT give them broker credentials or the ability to submit trades. Compromising apex-cloud gives an attacker: the ability to issue new registration tokens (mitigated by short rotation policy + visibility into unexpected handshakes).
Closest analog
Tailscale. Control plane is hosted; data plane runs on user devices; Tailscale never sees the user's actual traffic. Apex's split is the same shape with different content: the control plane shows you what your engine is doing, but never sees your broker credentials and never executes a trade.
Wire-format compatibility
The engine and the relay-server speak a versioned wire format. Mismatched versions reject at handshake; the cloud UI surfaces this as "your engine is out of date; upgrade to vX.Y.Z." Additive changes (new variants, new optional fields) don't force a bump; incompatible changes do.
When you upgrade the engine, the registration token + storage volume carry forward. See Hosting § Operating tips for the upgrade flow.
Market-data feeds
The engine talks to Alpaca's market-data WebSockets. Two equity feeds + one crypto feed:
ValueURLSymbolsHoursiex (default, free)wss://stream.data.alpaca.markets/v2/iexAAPL, NVDA, etc.US market hourssip (paid Algo Trader Plus)wss://stream.data.alpaca.markets/v2/sipsamesamecrypto (automatic)wss://stream.data.alpaca.markets/v1beta3/crypto/usBTC/USD, ETH/USD, etc.24/7
Crypto symbols (slash-separated BASE/QUOTE shape) auto-route through a parallel crypto controller alongside the equity feed, so mixed equity + crypto in one session works out of the box. Set APEX_MARKET_DATA_FEED=sip if you have the paid Algo Trader Plus subscription; otherwise leave it at the default.
What this is NOT
Not full SaaS. Fusion doesn't hold broker keys, doesn't execute trades. If your use case requires that shape, Apex isn't the right tool.
Not Tauri desktop bundle. Tauri remains a planned packaging option, but the hybrid-SaaS architecture is what cloud.apex.fusion.dev serves by default. Tauri ships as a follow-up wrapper around the same apex serve binary.
Not HFT-compatible. The audit graph in the hot path caps decision latency around ~1ms even with Mode::LowLatency. True HFT (sub-100µs) requires a different product shape.