Updating

What a release is, how to tell which build is running, the order to update in, image tags, the runtime tools, and what a version bump does to a write-ahead journal.

A release is a semver tag on a commit that was re-validated over the whole crate roster before anything was published; CHANGELOG.md is the curated summary and the release's own notes are the PRs merged since the previous tag. Every asset is listed in SHA256SUMS, which is the upload manifest itself — an asset cannot reach the release without a line in it — and a re-run replaces same-name assets rather than duplicating them.

Which build is this?

vike-cli --version
# vike-cli 0.1.0 (git 62ccdd8e clean, built 2026-08-09T09:41:07Z, rustc 1.96.0, x86_64-unknown-linux-gnu)

vike_buildinfo::version_line prints the package name and version, then the commit, its clean/dirty state, the build time, the compiler and the target. Every daemon logs the same line first at startup, so journalctl -u vike-tradehub | head answers it for a running unit. Read dirty and clean differently: dirty is authoritative, clean means no committed change since the crate was last built, and dirty? means the build could not ask git at all. The desktop app has no --version flag; its identity line is the first line of its log.

The order

Read config check on the new binary before you restart anything. A settings key that nothing reads is rejected by name on load, so a key a newer release adds cannot be written before the binary that reads it is installed — and a removed environment variable is refused at startup rather than ignored (vike_config::REMOVED_ENV), which is the one update step that can turn a daemon that used to start into one that does not. It is telling you something true.
Stop gracefully. sudo systemctl stop sends SIGTERM, which raises the same stop flag the interactive shutdown word raises, and the ordinary teardown runs — the strategy-state save and the terminal journal snapshot, plus the resting-order cancel sweep when flags.cancel_orders_on_shutdown is on (it is off by default, so quotes stay resting at the venue). Keep TimeoutStopSec= above the profile's shutdown_deadline_ms or SIGKILL wins the race.
Replace the binaries under <project>/bin/, verifying each against the new SHA256SUMS.
Re-run vike-cli init. Re-running is the ordinary case: a new version ships new examples, the default writes only what is absent, and an edited file is never touched. --reset restores the shipped samples and nothing else; --dry-run says what would change.
Start, and read the identity line to confirm the running commit is the one you installed.

The store does not move on an update, and the log line proves it

Every binary that resolves the history-store root logs hist store root resolved … store=<path> rung=<rung> before opening it — vike (whose line reads studio hist store root resolved), backtest, vike-datahub and the vike-backfill collectors. explicit/env mean you named it, declared-project means VIKE_SETTINGS_DIR did, dev-checkout means the source checkout that built the binary is still on this box, project means the walk found it, user-dir means no project was found, and last-resort means no per-user directory either (crates/vike-model/src/store_path.rs's StoreRootRung, whose why sentence rides the same line). A store does not merge: if that line ever changes between versions, the old store is simply no longer read and a run reports zero rows rather than failing. The binaries handed a path outright print no such line and need none: vike-recorder takes it from its profile, vike-study and tearsheet from --store; vike-tradehub resolves a tick store instead and logs tick store root resolved.

Images

Each image is tagged with the version alone — vike-tradehub:<version>, vike-thin:<version>, the same tag on GHCR and Docker Hub — so an update is a pull of the new tag, docker stop (SIGTERM, bounded by --stop-timeout), and a docker run naming the new tag against the same mounted folder. Settings, state and data are in the mount, not the image. At start the entrypoint reconciles <project>/bin against the toolset the image stages, comparing a content digest rather than the release tag; today the staged toolset is empty by policy, so it installs nothing and touches nothing, and it refuses to replace a bin/ it did not stamp unless VIKE_CONTAINER_ADOPT_BIN=1 says so.

The runtime tools

Two programs a running binary spawns but does not compile ride the release beside the binaries: the JForex sidecar jar (Dukascopy's only execution path) and the pinned LightGBM CLI with its PROVENANCE file. vike_model::state_path::PROJECT_BIN_DIR says where a binary looks — <project>/bin/<tool>/ — and a source checkout ships an installer (just fetch-tools [tag] [tool...]) that does the same job by hand: it downloads SHA256SUMS, refuses any asset the manifest does not list, verifies before installing, and lands bin/jforex/jforex-bridge.jar, bin/lightgbm/lightgbm and bin/lightgbm/PROVENANCE. Installing the LightGBM binary without its PROVENANCE produces a tool that is refused at startup, because vike_ml::cli::LightGbmCli::new checks the recorded tag against vike_ml::pins::PINNED_LIGHTGBM_TAG. JFOREX_BRIDGE_JAR and JAVA_HOME still name a jar or a JVM outright and beat the project rung.

What a version bump does to the journal

If you run with the write-ahead command journal enabled, its on-disk format carries a version. crates/vike-core/src/journal/mod.rs states the contract: this build writes VERSION (15 at the time of writing) and reads or resumes anything in MIN_READABLE_VERSION..=VERSION (from 4), so an older supported journal directory is opened and appended to in place, never rejected — an upgrade does not cost an operator their live journal. Two things are hard errors: a version below MIN_READABLE_VERSION, a shape this build can no longer parse, and any version above VERSION, written by a later build.

The rule that makes the accepted range safe is that a version step may only add a record variant or a defaulted field. Replay is unaffected: a v4 journal replayed by a v15 binary yields exactly the record sequence a v4 binary saw. Any step that renames or removes a variant must raise MIN_READABLE_VERSION to VERSION in the same commit, which turns a stale journal back into a loud cold-start error.

Downgrading is the direction that refuses

A newer build's journal is refused by an older one (journal format version mismatch), and the refusal is load-bearing: the 14 → 15 step added a defaulted route_key field an older build would parse without complaint and then misroute, folding a labelled account's balance into the default account. Roll a binary back only with the journal it wrote. The journal's home is under The journal.

Other things a release can move

The demo tape carries DEMO_TAPE_VERSION in its commit key; a bump makes the next backtest --seed-demo write the new tape alongside the old one rather than silently keeping stale bars. Program-written state files that changed location migrate on their next write — a read prefers the state directory and falls back to the legacy path, a write always lands in the state directory, and the old file is deliberately never deleted (vike_model::state_path's dual read).