Where it runs

One core, several front ends. Which one you install decides what you can do without touching anything else, so the choice is worth a table before a download.

The surfaces

The desktop app ships as one build. vike-desktop declares no cargo features at all: it holds no trading core, mounts no venue, links no DataFusion and takes vike-data with default features — the HistStore trait and nothing behind it. What it draws comes from a node and a data service over the wire, which is why it needs one running.

It drives the Studio remote-only, against the resolved datahub address — the explicit config.datahub_addr, else a connected backend's own advertisement — and shows a "Studio: no data store" label naming both fixes when neither answers. Observe mode covers the modes; the sizes are on Requirements.

vike-tradehub is the headless daemon: a strategy named in a TOML profile, mounted on the production live core over the paper exchange by default, with zero real-money, credential or geo risk and no live feed. The opt-in live variant mounts the same strategy on the real multi-venue core with per-venue credential-gated execution and the venue's own feed, behind the tradehub_live flag, the credential store, each venue's own second gate, the daemon's venue allow-list (LIVE_WIRED_VENUES) and a venue-plus-symbol check against the core's wired-markets table. Its observe/control server starts only when an address is configured — config.tradehub_addr or VIKE_TRADEHUB_ADDR, unset by default, with the commented 127.0.0.1:7879 in the shipped examples as the loopback address to use — and is authenticated with scoped HMAC node keys. The Linux unit is deploy/vike-tradehub.service; the container is the same binary under docker run. No daemon asset is published for Windows.

vike-datahub is the compute-to-data backtest server: a client ships a small profile over a loopback TCP socket, the server runs the existing backtest engine next to the data and returns only the report. It listens on 127.0.0.1:7878 by default and refuses a non-loopback bind unless VIKE_DATAHUB_ALLOW_PUBLIC_BIND=1 is set and a node key is configured; with neither VIKE_DATAHUB_OBSERVE_KEY nor VIKE_DATAHUB_CONTROL_KEY in the credential store it authenticates nothing, which is why it is meant to be reached over an SSH tunnel. The release binary carries the serve-datafusion backend; a default build answers --help and reports it has no backend. It is also what the Studio's remote runs dispatch to.

backtest is the one-process path: it opens the history store itself, runs a profile, prints a report, and persists a single run under <project>/user_data/runs/<run_id>/. It also owns the three ways a fresh store gets data — --seed-demo, --fetch and --fetch-starter — because the tool that consumes history is the honest place for the command that creates some.

The two images

vikeio/vike-tradehub carries the whole headless product as one multicall binary, vike-backend, which answers to every tool name through argv[0]: vike-tradehub (the daemon the container starts by default), vike-cli, backtest, vike-datahub, vike-recorder, vike-study and tearsheet (crates/vike/src/main.rs's TOOLS — the crate directory kept its old name). Measured on the release runner, the three DataFusion-linked binaries are 128, 106 and 107 MB apiece; the multicall links that closure once. It runs one tool per process, deliberately — every tool owns process-global state that assumes it is alone.

That the image is a first-class way to install — not a convenience beside a "real" one — is a ruling rather than a slogan: it carries every headless tool because an earlier boundary keeping the image deliberately partial was lifted, which CHANGELOG.md's 0.1.17 entry records. The project folder is a bind mount that outlives the image.

vikeio/vike-thin is the observe-only GUI as a container: the binary runs against a virtual framebuffer on Mesa's lavapipe software rasteriser and is exported over VNC and noVNC, so it behaves identically on Linux, Windows and macOS hosts because nothing in it touches host hardware. The cost was measured on the same idle chart: the native binary drew about 22 fps at 10.9–12.5% CPU; the container drew about 12 fps at 79–275% CPU. It is for the case a binary cannot serve — a host with no published asset, a machine you do not control, occasional access — and it is not a replacement for the native client.

Choosing

• You want a chart and a first backtest on your own machine: the desktop app against a node, or the backend image plus backtest. Install on Windows, Install on Linux, Install with Docker.
• You want a strategy running while your laptop is closed: vike-tradehub on a Linux box, native or in the container, watched from the desktop app over an SSH tunnel.
• You want backtests to run where the history is: vike-datahub beside the store, driven by vike-cli backtest, sweep and walkforward from anywhere.