vike-cli datahub

vike-cli datahub setup mints the pair of node keys a vike-datahub server authenticates with — CSPRNG bytes, one key scoped to observe and one to control — and writes them into the project's node-key store. Run it on the datahub server's own box. There is no argv form, no stdin form, and no --from-env form: no key value ever reaches or leaves this command in any shape, and what it prints is each key's ID, not the key itself.

Usage

vike-cli datahub setup [--rotate]

setup is the only subcommand. Nothing else parses — no subcommand at all, or any spelling but setup/-h/--help/help, is a clean parse error (crates/vike-cli/src/cmd/datahub.rs's parse).

Mint a fresh pair:

vike-cli datahub setup

This refuses if either key already exists in the store. A key already written is a key some client is already signing with, so replacing it is a decision, not an idempotent re-run — the same refusal backend setup makes for its own pair (crates/vike-cli/src/cmd/datahub.rs's run_setup).

Replace keys already in the store:

vike-cli datahub setup --rotate

--rotate takes no inline value: --rotate=maybe is a parse error rather than a silently-ignored value, because dropping it quietly is how a command line whose author meant something by =maybe leaves them believing they rotated when they did not (crates/vike-cli/src/cmd/datahub.rs's parse).

A successful run prints the store's path, each key's name and ID, and the restart line:

minted into <path>:
  <key name>  id <id>
  <key name>  id <id>

restart the server so it loads them:
  sudo systemctl restart vike-datahub

It will then log AUTHENTICATION REQUIRED with both key IDs at next start — compare those against the two this command printed to confirm a client and the server hold the same pair (crates/vike-cli/src/cmd/datahub.rs's run_setup).

Why this is a separate verb, not a mode of backend

backend means a vike-tradehub node, and a datahub is not one: it speaks a different protocol, serves different verbs, and its control scope compiles client-supplied Rhai rather than placing orders. vike-datahub authenticates with the same two-key HMAC handshake vike-tradehub does, but until this verb existed nothing in the tree could generate a datahub's pair — backend setup mints the tradehub pair and validates names against a table that did not carry the datahub's, and secrets set refuses both datahub key names by design. The datahub deployed to prod2 on 2026-09-08 had its keys made with openssl at a shell, for exactly that reason (crates/vike-cli/src/cmd/datahub.rs's module doc).

What it deliberately does not write

This verb writes nothing but the key store itself. backend setup also sets config.tradehub_addr and, under --control, flags.tradehub_control — there is no equivalent pair to set here. The datahub server's bind address is not a value this command owns: it arrives as VIKE_DATAHUB_ADDR, an Environment= line deploy/vike-datahub.service sets. config.datahub_addr is a client's dial address, not the server's bind, so setting it from this command would move nothing on the datahub's own box (crates/vike-cli/src/cmd/datahub.rs's USAGE).

An absent key store is refused rather than created — this command mints keys into a store that already exists; it does not stand one up (crates/vike-cli/src/cmd/datahub.rs's module doc).

Related

• backend — the equivalent mint for a vike-tradehub node's keys; its own doc is why the two verbs stay separate.
• secrets — secrets path prints where this box's store lives; secrets set refuses both datahub key names outright.