Most algorithmic-trading platforms ask you to trust three things at once: their strategy code, their data pipeline, and their custody of your money. Apex's architecture asks you to trust exactly none of them.

The cloud dashboard at cloud.apex.fusion.dev is hosted; we run it. The engine that decides whether to place an order, and the broker credentials that let it do so, run on hardware you control. The two halves connect over a signed WebSocket. Nothing about your broker, your decisions, or your capital flows through Fusion's servers.

This is unusual enough that it's worth explaining why.

What the cloud dashboard does

The hosted control plane is an operator surface. It lets you:

• See the engine's current state from any device. Positions, PnL, today's order log, equity over time.
• Hit kill switches. Cancel all orders and Flatten both dispatch over the relay; the engine confirms back with the audit-chain node id the action produced.
• Annotate trades. The Journal tab writes notes into the same provenance graph the engine reads at decision time.
• Manage strategies + the watchlist. Same shape as the engine's local HTTP surface, just reachable from your phone.

It does not hold your broker credentials. It does not execute trades. It is genuinely a viewer plus a remote control, not the machine being viewed.

What the engine does

apex serve runs on hardware you provision. A €5/mo Hetzner VPS, a NUC in your closet, a Mac mini, a laptop with Docker, a Kubernetes cluster if you're running this for an organization. The engine:

• Holds APCA_API_KEY_ID + APCA_API_SECRET_KEY (or the equivalent for whichever broker you've added) in its environment. These never appear in any HTTP request to Fusion.
• Subscribes to your broker's market-data + trade-updates WebSockets directly. The price tick that triggers a signal travels broker → your hardware, not broker → Fusion → your hardware.
• Writes every decision to a local SQLite chain. The full causal graph (which bar triggered which signal, which gate let it through, the order parameters, the fill price) lives on your disk. The cloud sees summaries plus an audit-event stream; the deep "why" investigation happens on the engine host.
• Submits orders to your broker over your authenticated session. Fusion is never in the call path.

The line, in detail

It's easier to reason about a security boundary when it's a table. Here is what crosses, and what does not.

| Resource | Lives on | Visible to Fusion? | |---|---|---| | Broker credentials | Engine host | No | | Per-decision detail (which bar, which gate, why) | Engine SQLite | No | | Tenant configuration (gate thresholds, params) | Engine SQLite | No | | 10-second snapshot summary (equity, position count) | Cached on relay | Yes | | Audit events (kill switches, gate rejections) | Streamed via relay SSE | Yes (event, not full context) | | Trade execution authority | Engine | No |

Compromising the relay-server gives an attacker: snapshots (equity numbers, position counts). It does not give them broker credentials, the ability to submit trades, or the deep audit chain. Compromising the cloud dashboard gives an attacker the ability to mint new engine-registration tokens. We mitigate that with short rotation and operator alerts; the worst case is still that they can't reach your broker.

Why hybrid instead of full SaaS

We considered the full-SaaS shape (Fusion holds the keys, Fusion executes through the broker). It would be simpler to build and simpler for users to onboard. We didn't ship it for three reasons.

Fiduciary surface. A platform that holds broker credentials and executes trades is, in regulatory terms, doing things that look a lot like the regulated functions a broker-dealer performs. We're a tools company, not a broker-dealer. Keeping that line clear means never being in the call path.

Trust asymmetry. "Trust us with your money" is a much harder ask than "trust us with the dashboard that watches your money." The hybrid shape lets users adopt Apex incrementally: paper-trade on a $5 VPS, watch from the cloud, scale into live trading on their own timeline.

Auditability. The Cortex audit chain is the substrate every strategy decision writes to. When the chain lives on your disk and you control the binary that writes to it, the audit is genuinely defensible. A hosted chain would mean trusting Fusion not to rewrite history, which is exactly the property we want the chain to obviate.

Why hybrid instead of fully local

A purely local install (your laptop runs the engine + the dashboard) would close the loop completely. It also closes the phone, the second machine, the colleague who needs to see what the engine is doing, the kill-switch button you can hit from a restaurant when something is going wrong. The hosted dashboard buys back operator UX without giving up the boundary.

The Tailscale analogy keeps coming up internally and it's the right one. Tailscale's coordination plane is hosted; the actual traffic between your devices is end-to-end, and Tailscale never sees it. Apex's coordination plane is hosted; the actual broker session is between your engine and your broker, and Fusion never sees it.

Where the architecture lives

If you want the full tour: the security boundary table in docs/apex/architecture.md spells out every resource and where it lives, the launch plan in docs/apex/launch.md documents the 16 locked decisions that shaped the split, and the self-host guide in docs/apex/self-host.md walks through standing up the engine on every deploy shape we support today.

The short version: the cloud is the operator surface, the engine is the machine, and they connect over a signed channel that never carries credentials. That is the entire architectural commitment, and everything else is just the slices that make it real.