Requirements

Operating systems

Linux, x86-64. Every headless binary and both desktop builds are published for it. The binaries are built on an Ubuntu 24.04 release runner with no --target, so they are dynamically linked against that box's glibc — measured at 2.39 — and a host with an older glibc fails at exec rather than at install (Debian bookworm's 2.36 is the named counter-example). The container image pins the same base for the same reason.

Windows, x86-64. The desktop app only: vike-desktop.exe, cross-built for x86_64-pc-windows-gnu. The resulting binary was run on a Windows box: it enumerated the real GPU through Vulkan, connected to a containerised daemon and rendered the UI with the system fonts, with no missing DLLs and no runtime to ship beside it. No daemon, CLI, runner or data-service .exe is published; the backend on Windows is the container.

macOS: no build is published. The vikeio/vike-thin container image runs on a macOS host because nothing in it touches host hardware, which makes it the one route to the GUI there, in a browser.

The desktop app

vike-desktop draws with wgpu, so a native run wants a GPU with a working Vulkan driver. Software rendering works — the thin image runs the same binary on Mesa's lavapipe — but it is a CPU doing a GPU's work: on one idle chart the native binary drew ~22 fps at 10.9–12.5% CPU where lavapipe drew ~12 fps at 79–275%, and the cost is per frame rather than per pixel (4.7× the pixels bought only ~1.3× the CPU).

On Linux the binary carries no hard dependency on libX11 or libwayland-client — winit loads them at window creation — so a missing X or Wayland library is a runtime LibraryOpenError after the app has already logged its version, not a start-up failure. The thin image's package list is the measured set: libxcursor1 libxrandr2 libxi6 libxinerama1 libxext6 libxrender1 libxfixes3 libxkbcommon-x11-0 and the libxcb-* siblings, each found by a crash. A font is required too: vike_app_core::fonts looks for Segoe UI on Windows and for DejaVu, Liberation or Noto files under /usr/share/fonts on Linux — DejaVu is the "always something" floor, the face the lists count on being installed and the last candidate in SYMBOLS, which is the one behind the title-bar controls; without any of them those controls and the chart buttons render as empty boxes.

Sizes: the release runner measures the Linux and Windows desktop assets on every run and writes them into the run log. The figures that used to sit here were of the fat and thin builds, which are not produced any more, so they are not restated as if they described the one that is.

The headless binaries

No GPU and no display. Sizes measured on the release runner in the release profile: vike-tradehub 128 MB, backtest 106 MB, vike-datahub 107 MB — each carrying its own static copy of the DataFusion/Arrow/Parquet closure — against vike-cli at 9.6 MB and tearsheet at 1.9 MB. The multicall vike binary in the container links that closure once.

Memory: the shipped units cap each process rather than state a floor — vike-tradehub at MemoryMax=2G, which the container recipe mirrors with --memory 2g; vike-datahub at 8G and vike-recorder at 4G. Each is a starvation guard for a box that may also host live trading, and each unit says to tune it to the box's headroom. Nothing in the tree states a minimum.

Disk

The project folder holds everything: settings/, user_data/, market_data/ and bin/. The history store lives at <project>/market_data/hist by default, resolved by the same walk that finds settings/ — vike_model::store_path::resolve_store_root is the precedence, and every binary that resolves one logs the root and the rung that chose it before opening. A store that records live feeds is measured in hundreds of gigabytes, which is why it is a sibling of the directories you copy rather than a child of them. A fresh install is small: the demo tape is six months of synthetic hourly bars plus one week of minutes, and the published starter dataset is about 740 KB.

Network

Venues are reached over TLS with the root certificates compiled into the binary — the container image installs no ca-certificates because nothing in the ELF reads /etc/ssl/certs. Two venues have regional constraints the tree names: Binance geoblocks whole countries at the REST layer, which is why backtest --fetch-starter exists beside --fetch; and Polymarket is geo-blocked in some regions, so its egress proxy defaults on at socks5h://127.0.0.1:1080 (crates/bridges/polymarket/src/egress.rs's proxy_url), a default you turn off or repoint through the POLY_PROXY_* knobs. The daemon's node server and the data service both bind loopback by default and are meant to be reached over an SSH tunnel; the handshake is plaintext and the tunnel supplies confidentiality.

Docker

Any host with Docker or Podman. Those two are what the release build itself drives: the image is built and smoke-run under one of them before it is published, so they are the pair the published image is known to work with. Another OCI runtime may well run it; nothing here has tried one. On a Linux host a bind mount is an ordinary mount --bind, measured directly. On Docker Desktop (Windows and macOS) keep settings/ a bind mount and put settings/state and data on named volumes: the mmap-backed journal suite took 389 s over the host passthrough against 1.23 s on a volume, and concurrent appends are correct there only because every change-journal append takes an exclusive flock. Install with Docker carries the recipes.

Three venues need more than a binary

Dukascopy executes through a Java sidecar: the release ships jforex-bridge.jar, and a JRE plus the jar must sit under <project>/bin/jre/ and <project>/bin/jforex/ (or be named outright by JAVA_HOME and JFOREX_BRIDGE_JAR) — crates/bridges/dukascopy/src/config.rs's resolve_dukascopy_tools is the ladder, and its last rung is a bare java on PATH. IBKR trades against IB's own Client Portal Gateway, which you run. FXCM needs the ForexConnect SDK linked in, which only the separate vike-tradehub-fxcm asset carries, and vike_fxcm::sdk_linked() demotes an unlinked binary to paper at the mount. The generated pages under Venues carry each venue's caveats.