ODIAN Launcher

The desktop launcher for ODIAN. It signs an operator in with their site's Keycloak account, installs ODIAN from the site (or from an ODIAN drive), forces an update before launch while the site is reachable, and runs ODIAN fully offline otherwise.

Part	Where	Stack
Hub UI	src/	Svelte 5 + Vite, bundled fonts, no network requests of its own
Backend	src-tauri/	Tauri 2 (Rust): commands and events in docs/CONTRACT.md
Installer	crates/odian-packs/	Rust port of the pack format v1 (ODIAN_MCP_Server/src/odian_packs)

Develop

npm install
npm run dev            # the hub in a normal browser, with a mock backend (?scenario=…)
npm run tauri dev      # the real launcher window
npm run check          # svelte-check
cargo test --workspace # Rust tests (needs ~/.cargo/bin on PATH)

Build the Windows setup (NSIS):

npm run tauri build

How it finds the site

On first run the launcher reads site.json next to its executable and copies it into its settings (%APPDATA%\fr.odian.launcher\settings.json). Operators can change the addresses later in Settings. See site.example.json:

{ "name": "ODIAN test site", "site_url": "http://192.168.1.41:30097", "mcp_url": "http://192.168.1.41:30091" }

• site_url: the site's update service (/v1/health, versions, packs).
• mcp_url: the site's MCP, which runs the Keycloak desktop sign-in (/auth/desktop/start, /auth/desktop/exchange).

On an operator PC

<install_dir>\                  D:\ODIAN when a D: drive exists, else C:\ODIAN
  versions\<v>\                 app, API, tile server and runtime files for one version
  data\db\<snapshot>\           database dumps restored into the local Postgres
  data\tiles\<style>\<dataset>\ tiles
  data\src\                     source files
  state\launcher.json           install id, installed version, last operator
  state\notes\<v>.md            patch notes, for offline reading

The site token lives in Windows Credential Manager under "ODIAN Launcher", one entry per site URL. The install id is generated on the PC the first time it saves its state, so a cloned drive never carries one.

The local stack

launch starts four processes, all on 127.0.0.1, in this order, each waiting for the previous one:

Process	Port	Working dir	Ready when
Postgres (versions\<v>\runtime\pgsql)	55432	state\pg	pg_ctl start -w returns
Engine API (versions\<v>\api\odian_api.exe)	18080	state\api	GET /health answers
Tile server (versions\<v>\tile_server, runtime\python)	18081	state\tiles	GET /health answers
ODIAN (versions\<v>\Odian\x64\MinGW-Release\Odian.exe)	—	state\client	still running after 3 s

• Every process starts from a clean environment (Windows basics plus the ODIAN variables set in src-tauri/src/stack.rs), without a console window, inside one Job Object, so nothing outlives the launcher.
• Odian.exe and the API read and write relative to their working directory. state\client therefore holds junctions assets and shaders into the version folder, and versions\<v>\ is never written.
• The tile server runs cache-only (ODIAN_TILE_CACHE_ONLY=1) from a generated state\tiles\datasets.json, and the client runs with ODIAN_OFFLINE=1.
• ODIAN signs in as the last operator through the local API's /auth/mint. The mint secret and the Postgres password are generated on the PC and kept in state\launcher.json.
• When Odian.exe closes, the rest stops in reverse order; Postgres stops with pg_ctl stop -m fast.