v1.30.0: rename theta-env -> theta-suite + docs rewrite + sso v1.16.1 (#126)

Rename the project to theta-suite (it is now an integrated suite of four
apps around a shared OpenBao secrets store, not a two-project env).
- theta-env -> theta-suite across the superproject: _config.yml (title +
  baseurl /theta-suite + repo URLs), README, setup.sh (incl. the
  THETA_SUITE_REEXECED self-update sentinel), docker-compose.yml,
  bootstrap.js, lint.yml, config.example/*, docs/robots.txt, all docs,
  this changelog.
- architecture.md rewritten: real 4-service + ldap-client topology, OpenBao
  secrets section, OpenBao-aware config flow; removed "two containers" /
  "three repos" / LDAP-"legacy" framing.
- index.md: integrated-suite framing + secrets/OpenBao + ldap-client.
- standalone.md + README: standalone reframed as advanced opt-in.
- sso-manager-node submodule -> v1.16.1 (401 fix on /conf and /vault).

Co-authored-by: Claude <noreply@anthropic.com>

.env.example

@@ -1,4 +1,4 @@
-# theta-env — unified SSO Manager + Proxy deployment.
+# theta-suite — unified SSO Manager + Proxy deployment.
 #
 # Copy this file to `.env` and fill in the values, then run `./setup.sh`.
 # All values are read by setup.sh / docker-compose / the bootstrap.

.github/workflows/lint.yml

@@ -1,8 +1,10 @@
 name: Lint
 
-# theta-env has no app code of its own to unit-test (it orchestrates the
+# theta-suite has no app code of its own to unit-test (it orchestrates the
 # proxy/sso-manager-node submodules) -- this checks the one thing that can
-# actually break silently: setup.sh and bootstrap.js.
+# actually break silently: setup.sh and bootstrap.js, plus a static
+# consistency check on the config bootstrap.js generates for jump-host
+# (test/check_jump_ldap_tls.js).
 on:
   pull_request:
     branches:
@@ -39,3 +41,6 @@ jobs:
 
       - name: Syntax check
         run: node --check bootstrap/bootstrap.js
+
+      - name: Jump-host LDAP config consistency
+        run: node test/check_jump_ldap_tls.js

.gitignore

@@ -5,8 +5,12 @@
 config/
 backups/
 
-# Legacy .env / proxy.env (no longer used — config is in ./config/). Still
-# ignored in case a migrated deployment hasn't deleted them yet.
+# .env: NOT app config (that's ./config/, generated by setup.sh) — this is
+# docker compose's own auto-loaded env file, which setup.sh uses only to
+# persist *_GIT_COMMIT build args so an ad-hoc rebuild of a single service
+# still bakes the right commit hash. Generated; never commit.
+# proxy.env: legacy, no longer used — still ignored in case an old
+# deployment hasn't deleted it yet.
 .env
 proxy.env
 

.gitmodules

@@ -8,3 +8,6 @@
 	path = jump-host
 	url = https://github.com/theta42/jump-host.git
 	branch = master
+[submodule "ldap-client"]
+	path = ldap-client
+	url = https://github.com/theta42/ldap-client.git

CHANGELOG.md

@@ -2,14 +2,862 @@
 
 All notable changes to this project are documented here. Format loosely
 follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions
-correspond to git tags (`vX.Y.Z`). Entries here cover theta-env's own
+correspond to git tags (`vX.Y.Z`). Entries here cover theta-suite's own
 orchestration code; see each submodule's own `CHANGELOG.md`
 ([proxy](https://github.com/theta42/proxy/blob/master/CHANGELOG.md),
 [sso-manager-node](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md))
 for what changed inside the apps it composes.
 
+## [v1.30.0] - 2026-08-01
+
+The project is renamed **theta-env → theta-suite** — it has grown from a
+docker-compose wiring two projects into an integrated suite of four
+applications around a shared OpenBao secrets store, and the name should reflect
+that. The GitHub repository is renamed `theta42/theta-env` →
+`theta42/theta-suite` (old URLs redirect), and the docs site moves to
+`https://theta42.github.io/theta-suite/`.
+
+### Changed (theta-suite orchestration)
+- **Renamed theta-env → theta-suite** across the superproject: `docs/_config.yml`
+  (`title` + `baseurl: /theta-suite` + repo URLs), `README.md`, `setup.sh`
+  (incl. the `THETA_SUITE_REEXECED` self-update sentinel), `docker-compose.yml`,
+  `bootstrap/bootstrap.js`, `.github/workflows/lint.yml`, `config.example/*`,
+  `docs/robots.txt`, all docs pages, and this changelog.
+- **Compose project name note:** docker compose derives the project name from
+  the clone directory, so named volumes follow it (`<project>_openbao-data`).
+  A fresh `git clone` of `theta-suite` uses the `theta-suite` project name; an
+  existing deployment that keeps its `theta-env` directory keeps its
+  `theta-env_*` volumes — no data migration is required, just don't mix the two.
+- **Docs site baseurl** is now `/theta-suite`, matching the renamed repo's
+  GitHub Pages URL.
+
+### Docs
+- **`architecture.md` rewritten.** Replaced the outdated "The two containers"
+  / "The three repos" framing with the actual topology — four always-on
+  services (`openbao`, `sso-manager`, `proxy`, `jump-host`) plus the
+  `ldap-client` host-enrollment tool — a real diagram, a full **Secrets
+  (OpenBao)** section (central store, scoped per-app policies/tokens, the
+  `@simpleworkjs/bao-conf` boot overlay, per-user KV, external-app minting),
+  and an OpenBao-aware "how config reaches the apps". Removed the
+  LDAP-"legacy apps" wording (direct LDAP binds are first-class: Linux hosts
+  PAM/SSSD, sudo, SSH keys).
+- **`index.md`** — integrated-suite framing; added **Central secrets (OpenBao)**
+  and **ldap-client** to "What you get" and "Related projects".
+- **`standalone.md` + `README.md`** — standalone is now framed as an advanced
+  opt-in; the integrated `./setup.sh` stack is the supported path.
+
+### Submodule bump
+- **sso-manager-node → v1.16.1** — fixes the **401 on `/conf` and `/vault`** for
+  a logged-in admin. Both view routes 401'd because this app's auth-token is a
+  header set by client JS (localStorage), not a cookie, so `req.user` is
+  undefined on a browser navigation; the routes now render the shell and gate
+  client-side (`app.auth.forceLogin`), with `/api/conf` + `/api/vault` still
+  enforcing auth + OpenBao scope server-side. See the
+  [sso v1.16.1 release](https://github.com/theta42/sso-manager-node/releases/tag/v1.16.1).
+
+## [v1.29.0] - 2026-08-01
+
+Two fixes for a fresh `./setup.sh` install, plus the SSH jump host promoted
+from an opt-in component to a core part of the stack.
+
+### Fixed (theta-suite orchestration)
+- **`setup.sh`** — fresh installs aborted silently right after `Minting
+  per-app OpenBao tokens`. The `env_get` helper's `grep | cut` pipeline returns
+  non-zero under `set -euo pipefail` when `.env` exists (it's created earlier
+  by the root-`VAULT_TOKEN` `env_upsert`) but a given app-token key is absent —
+  the normal first-run state. The unguarded `existing="$(env_get ...)"` then
+  tripped `set -e` and killed the script before any token was minted. `env_get`
+  now always returns 0 (`|| true`), so "key absent" resolves to empty and the
+  run continues through token minting, the SSO/proxy bring-up, and the jump
+  host. Reproduced + verified the fix under the exact fresh-install condition.
+- **`setup.sh`** — `JUMP_VAULT_TOKEN` is now always minted (jump host is core;
+  the mint was already unconditional, this just documents it).
+
+### Changed (theta-suite orchestration)
+- **jump host is no longer optional** — it is built + started on every run,
+  with no `CFG_JUMP_HOST_ENABLED` flag.
+  - `docker-compose.yml`: removed `profiles: ["jump-host"]` from the
+    `jump-host` service so `docker compose up` includes it unconditionally.
+    The test-only `ldap-test-host` downstream fixture keeps an opt-in profile,
+    renamed `jump-host` → `ldap-test` (`docker compose --profile ldap-test up`).
+  - `setup.sh`: `SUBMODULES` always includes `jump-host`; the build/start +
+    host-register + summary lines for the jump host are no longer wrapped in a
+    `JUMP_ENABLED` guard; the `COMPOSE_PROFILES` export is gone.
+  - `bootstrap/bootstrap.js`: jump-host provisioning (mint API token + write
+    `jump-secrets.js` + mirror into OpenBao) and its directory service record
+    now run unconditionally — no `CFG_JUMP_HOST_ENABLED` gate.
+  - `setup.env.example` / `docs/index.md` / `docs/quickstart.md`: dropped the
+    "optional / enable with `CFG_JUMP_HOST_ENABLED=true`" wording; the
+    `CFG_JUMP_HOST` hostname override + `JUMP_SSH_PORT` remain.
+
+## [v1.28.0] - 2026-08-01
+
+OpenBao becomes the central secrets store for the whole stack. Every app now
+loads its secrets from OpenBao at boot via the new
+[`@simpleworkjs/bao-conf`](https://simpleworkjs.github.io/bao-conf/) package;
+end users get personal per-user secret storage through the SSO UI; external
+apps get scoped `secret/apps/<app>/*` access. `setup.sh` mints the policies
+and scoped tokens, `bootstrap.js` writes generated creds into OpenBao, and a
+new `docs/secrets.md` documents the architecture.
+
+### Changed (theta-suite orchestration)
+- **`setup.sh`** — after the KV-v2 enable, a new idempotent block writes four
+  OpenBao policies (`sso-broker`, `sso-admin`, `proxy`, `jump-host`) via
+  heredocs, a `sso-broker` token role (`allowed_policies_glob` `user-*`/`app-*`,
+  24h period), and mints scoped `SSO_VAULT_TOKEN` / `PROXY_VAULT_TOKEN` /
+  `JUMP_VAULT_TOKEN` (orphan, renewable, reused from `setup.env` if still
+  valid). `seed_app_conf` seeds `secret/{sso-manager,proxy,jump-host}/conf`
+  from the operator-edit `/config/*-secrets.js` files on first run. The
+  bootstrap exec now passes the root `VAULT_ADDR`/`VAULT_TOKEN` for seeding.
+  The root token stays in `setup.env` for maintenance only — it is never passed
+  to a service container. `bash -n` + `shellcheck` clean.
+- **`docker-compose.yml`** — `sso-manager`/`proxy`/`jump-host` get
+  `VAULT_ADDR=http://openbao:8200` and `VAULT_TOKEN=${SSO|PROXY|JUMP}_VAULT_TOKEN:-`;
+  `proxy`/`jump-host` gain `depends_on: openbao: service_started`. compose
+  config valid.
+- **`bootstrap/bootstrap.js`** — `baoPut()` writes the generated OAuth client
+  creds to `secret/proxy/conf` and `secret/jump-host/conf` (POST replaces; the
+  full file object), so OpenBao — not the on-disk `/config/*-secrets.js` — is
+  authoritative after first boot. Fail-soft. `node --check` clean.
+- **`docs/secrets.md`** (new) — the full secrets architecture: load path,
+  policy/token table, the `sso-broker` role, seeding, end-user personal
+  secrets, external-app convention (curl + Node `bao-conf` examples), operator
+  rotation, backups. Linked from the README and the docs nav (`_config.yml`).
+- **README** — Configuration section rewritten (OpenBao authoritative, link to
+  `docs/secrets.md`); Secrets-backup section adds the `openbao-data` volume.
+
+### Submodule bumps
+- `sso-manager-node` → **v1.16.0** (was v1.15.2-era).
+- `proxy` → **v1.13.1** (was v1.12.1; passes through v1.13.0).
+- `jump-host` → **v1.14.1** (was v1.11.0-era; passes through v1.14.0).
+- `ldap-client` unchanged (v1.1.1).
+
+#### sso-manager-node — [v1.16.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.16.0)
+
+OpenBao becomes the central secrets store for the theta42 stack, and the SSO
+Manager becomes its broker. This is the SSO's half of the move: it loads its
+own secrets from OpenBao, mints scoped tokens for users and external apps,
+and exposes a fixed, role-scoped personal-secrets UI.
+
+##### Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/sso-manager/conf` over the file-loaded config
+  (replacing the old `utils/conf_manager.js`, which did a shallow-per-key
+  merge). `bin/www` runs `bao-conf.init()` after `models.initORM()` and
+  before `listen`. Fail-soft: if OpenBao is unreachable, boot continues from
+  `CONF_SECRETS`. The SSO authenticates with a scoped `VAULT_TOKEN` (policy
+  `sso-broker`), never the root token. The admin **Configuration** UI
+  (`/api/conf`) now writes through `bao-conf.set('sso-manager', …)`.
+- **`/api/vault` proxy reworked** — the old endpoint was an ungated
+  pass-through that never injected an `X-Vault-Token` (so the UI was both
+  ungated *and* broken). It is now `middleware.auth` → `scopeGuard` → a
+  token-injecting proxy. `scopeGuard` resolves a per-user (`user-<uid>`) or
+  per-admin (`sso-admin`) token via the new `utils/vault_broker.js`
+  (Redis-cached, minted through the `sso-broker` token role) and enforces a
+  path prefix as a second layer on top of the OpenBao policy. The client
+  `auth-token` is stripped; only the server-minted token reaches OpenBao.
+- **Vault UI reworked and renamed** (`views/vaultwarden.ejs` →
+  `views/vault.ejs`; the `/vault` route is now `middleware.auth`-gated).
+  Non-admin users see only their `secret/users/<uid>/` namespace; admins get
+  free-form path entry across `secret/` plus an **Apps** tab to mint scoped
+  tokens for external apps (`secret/apps/<name>/*`, shown once with copy +
+  `curl` convention).
+- Bumped package version to track the release tag.
+
+##### Removed
+- `nodejs/utils/conf_manager.js` (replaced by `@simpleworkjs/bao-conf`).
+- `nodejs/views/vaultwarden.ejs` (renamed `vault.ejs`).
+
+##### Security
+- **Committed-secrets remediation.** `config/sso-secrets.js` (LDAP bind
+  password, SMTP, `oauth.jwtSecret`) and `nodejs/test_plugins.js` (a
+  hardcoded Proxmox root API token and a UniFi password) were tracked on
+  master. They are now untracked + gitignored (`config/*-secrets.js`), and
+  `test_plugins.js` is deleted; `config/proxy-secrets.js.example` added as a
+  placeholder template. **The secrets remain in git history — rotation at
+  the providers is the real remediation and is the operator's to perform.**
+  OpenBao is now the authoritative store; the local files are seed artifacts
+  only.
+
+> Note: sso releases v1.12.0–v1.15.2 were tagged from merge PRs without
+> corresponding `CHANGELOG.md` entries or GitHub releases; v1.16.0 resumes
+> the changelog.
+
+#### proxy — [v1.13.1](https://github.com/theta42/proxy/releases/tag/v1.13.1) (via [v1.13.0](https://github.com/theta42/proxy/releases/tag/v1.13.0))
+
+##### v1.13.1 — Fixed
+- **Bumped `@simpleworkjs/bao-conf` to 1.0.1** so standalone/no-OpenBao boots
+  don't crash. bao-conf 1.0.0's `init()` threw when `VAULT_TOKEN` was unset,
+  which — combined with `bin/www`'s `.catch(() => process.exit(1))` — made the
+  proxy exit at boot in any deployment without an OpenBao sidecar (standalone
+  Docker, bare metal). 1.0.1 makes `init()` fail-soft on a missing token (warn
+  + continue from `CONF_SECRETS`), matching the documented contract. The
+  theta-suite stack is unaffected (it always sets a scoped `VAULT_TOKEN`).
+
+##### v1.13.0 — Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/proxy/conf` over the file-loaded config. The proxy
+  authenticates to OpenBao with a scoped `VAULT_TOKEN` (policy `proxy` —
+  read-only on its own path), never the root token. Because the OIDC
+  `clientSecret` is captured at require time inside `createOidcClient` (during
+  `require('../models')`, which `require('../app')` triggers transitively),
+  `bin/www` now defers `require('../app')` until after `bao-conf.init()`
+  resolves. Fail-soft: if OpenBao is unreachable, boot continues from
+  `CONF_SECRETS`. The `config/proxy-secrets.js` file is now an operator-edit
+  seed artifact (gitignored); OpenBao is authoritative.
+- Bumped package version to track the release tag.
+
+#### jump-host — [v1.14.1](https://github.com/theta42/jump-host/releases/tag/v1.14.1) (via [v1.14.0](https://github.com/theta42/jump-host/releases/tag/v1.14.0))
+
+##### v1.14.1 — Fixed
+- **Bumped `@simpleworkjs/bao-conf` to 1.0.1** so standalone/no-OpenBao boots
+  don't crash. bao-conf 1.0.0's `init()` threw when `VAULT_TOKEN` was unset,
+  which — combined with `bin/www`'s `.catch(() => process.exit(1))` — made the
+  jump host exit at boot in any deployment without an OpenBao sidecar
+  (standalone Docker, bare metal). 1.0.1 makes `init()` fail-soft on a missing
+  token (warn + continue from `CONF_SECRETS`), matching the documented
+  contract. The theta-suite stack is unaffected (it always sets a scoped
+  `VAULT_TOKEN`).
+
+##### v1.14.0 — Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/jump-host/conf` over the file-loaded config. The jump
+  host authenticates to OpenBao with a scoped `VAULT_TOKEN` (policy
+  `jump-host` — read-only on its own path), never the root token. Because the
+  OIDC `clientSecret` is captured at require time inside `createOidcClient`
+  (during `require('../models')`), `bin/www` now runs `bao-conf.init()`
+  **before** `require('../models')`. Fail-soft: if OpenBao is unreachable,
+  boot continues from `CONF_SECRETS`. The `config/jump-secrets.js` file is now
+  an operator-edit seed artifact (gitignored); OpenBao is authoritative.
+- Bumped package version to track the release tag.
+
+## [v1.27.2] - 2026-08-01
+
+- Updated `proxy` to v1.12.1 (Dependabot security/maintenance bumps).
+
+#### proxy — [v1.12.1](https://github.com/theta42/proxy/releases/tag/v1.12.1)
+
+##### Changed
+- Bumped `body-parser` 2.2.2 → 2.3.0 (Dependabot #175).
+- Bumped `ejs` and `brace-expansion` (Dependabot #179, security maintenance).
+
+## [v1.27.1] - 2026-08-01
+
+- Added automated integration tests for the environment (`test-integration.sh`).
+- Updated `sso-manager-node` to v1.15.2 (Directory UI tab styling fixes and Vault documentation).
+
+## [v1.27.0] - 2026-08-01
+
+- Updated `sso-manager-node` to v1.15.0 (UI/UX improvements and structured conf page).
+
+## [v1.26.0] - 2026-08-01
+
+- Made OpenBao production-ready by using a persistent file backend, enabling `IPC_LOCK`, and dynamically generating a robust config file.
+- Automated OpenBao initialization, unsealing, and secrets seeding via `setup.sh`.
+
+## [v1.25.0] - 2026-08-01
+
+- Added OpenBao (Vault) container for secrets management and native UI proxying.
+- Updated `sso-manager-node` to v1.14.0 (Discovery and Vault integration).
+- Updated `proxy` to v1.12.0.
+
 ## [Unreleased]
 
+## [1.23.0] - 2026-07-31
+
+### Submodules bumped
+- jump-host `v1.12.0` -> [`v1.13.0`](https://github.com/theta42/jump-host/releases/tag/v1.13.0)
+- proxy `v1.10.0` -> [`v1.11.0`](https://github.com/theta42/proxy/releases/tag/v1.11.0)
+- sso-manager-node `v1.12.0` -> [`v1.13.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.13.0)
+
+#### jump-host — [v1.13.0](https://github.com/theta42/jump-host/releases/tag/v1.13.0)
+
+##### Changed
+- **Title changed to "SSO Manager"** — the jump-host web UI now presents itself as "SSO Manager" in the navbar and page title, matching its role as the unified access portal for both services and hosts.
+
+#### sso-manager-node — [v1.13.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.13.0)
+
+##### Changed
+- **Directory page cleaned up** — removed the parent badge and slug display from the directory table; resource names now align with the badges above for a cleaner, more compact layout.
+- **Users list SSH key column fixed** — users with multiple SSH keys no longer show multiple checkmarks; the column now shows a single checkmark indicating "has key" regardless of key count.
+
+#### proxy — [v1.11.0](https://github.com/theta42/proxy/releases/tag/v1.11.0)
+
+##### Changed
+- **Permissions, Users, and Groups pages converted to table layouts** — card grids replaced with striped tables for better scanability and alignment. Users page adds per-field validation error display alongside the summary message.
+- **Groups page auto-refreshes** — adding or removing a group now triggers an explicit reload, ensuring the list stays in sync without manual refresh.
+
+## [1.22.0] - 2026-07-31
+
+### Submodules bumped
+- jump-host `v1.11.0` -> [`v1.12.0`](https://github.com/theta42/jump-host/releases/tag/v1.12.0)
+- proxy `v1.9.0` -> [`v1.10.0`](https://github.com/theta42/proxy/releases/tag/v1.10.0)
+- sso-manager-node `v1.11.0` -> [`v1.12.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.12.0)
+
+#### jump-host — [v1.12.0](https://github.com/theta42/jump-host/releases/tag/v1.12.0)
+
+##### Added
+- **TUI host picker with colors**: ANSI-colored terminal UI with box-drawing header, cyan/magenta/green title treatment, per-row coloring (cyan hostnames, blue IPs), environment badges (red PROD / dim DEV), green inverse selection highlight with "◄ SELECTED ►" indicator, yellow filter text, and a footer separator with quick-select hint.
+
+#### sso-manager-node — [v1.12.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.12.0)
+
+##### Changed
+- **Catalog page (`/`) redesigned**: Removed the portal banner; "My Access" section now has tabs separating Services and Hosts; icons support both Font Awesome classes and image URLs (http/https).
+- **Profile page redesigned as a single card with tabs**: Password reset is now a modal button; "My groups", "My Services", "Security & Usage Stats", and "Members of X's group" are now tabs on the main profile card instead of separate cards; metrics display fixed to properly load and show service usage data.
+
+#### proxy — [v1.10.0](https://github.com/theta42/proxy/releases/tag/v1.10.0)
+
+##### Changed
+- **Permissions page**: Converted from card grid to table/list layout with columns: Subject, Scope, Domain, Role, Actions.
+- **Users page**: Converted from card grid to table/list layout; form validation now shows both a summary message AND per-field error messages with visual highlighting.
+- **Groups page**: Added automatic refresh after adding/deleting groups to ensure new entries appear immediately.
+
+## [1.21.0] - 2026-07-31
+
+### Submodules bumped
+- ldap-client `v1.1.0` -> [`v1.1.1`](https://github.com/theta42/ldap-client/releases/tag/v1.1.1)
+- sso-manager-node `v1.10.0` -> [`v1.11.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.11.0)
+
+> **Operational note — the SSO image now builds slapd from source.** OpenLDAP's
+> `nestgroup` overlay (nested groups) exists only on master; no 2.6.x release
+> ships it. `Dockerfile.openldap` therefore compiles OpenLDAP from a **pinned**
+> commit, which makes the SSO image slower to build and pulls `pw-sha2` from
+> contrib. Two consequences worth knowing:
+>
+> - Master ships **LMDB 1.0.0**, whose on-disk format is mutually unreadable
+>   with the 0.9.x in 2.6.x (`MDB_INVALID: File is not an LMDB file`). Moving an
+>   existing `/var/lib/ldap` onto this image is a `slapcat` -> `slapadd` reload,
+>   not a restart.
+> - There is a `TODO` to drop the whole from-source stage once `nestgroup` ships
+>   in a release. The entrypoint already probes for `nestgroup.so` and the app
+>   keys off `app_ldap__nestedGroupsServerSide`, so that swap needs no other
+>   changes.
+
+#### sso-manager-node — [v1.11.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.11.0)
+
+##### Added
+- **End-user catalog at `/`** — the first ungated nav item; previously every nav entry was admin-only and a normal user had no signposted destination. Search/filter, per-kind icons, and a *how to reach it* block per card: the URL for a service, the SSH invocation for a host (using the jump-host `uid_-_slug@host` grammar when `directory.jumpHost` is set).
+- **Self-service access requests** — `/api/access-requests` (create, list own, list decidable, approve, deny, withdraw) with approve/deny queues on the catalog. Approving performs the LDAP group add, so LDAP stays the access-control truth. Requests target a resource's `_access` group, never `_admin`. Replaces the "coming soon" stub.
+- **Admin access visibility** — an Access column on the directory table (member/group counts, flagging links whose LDAP group was deleted) and a "what can this user reach" lookup, the reverse question that previously had no UI at all.
+- **Nested LDAP groups.** `groupOfNames.member` already accepts a group DN, so nesting needs no schema — what it needs is resolution, which no released OpenLDAP performs. Server-side via the pinned-master `nestgroup` overlay; client-side the app computes the closure itself (cycle-detected, depth-capped) against any other server. `PUT`/`DELETE /api/group/:group/nested/:child`, `GET /api/group/:group/effective`, and a **Nested** tab on each group card.
+- **`app_super_admin` is now seeded** (it never was) and nested into `app_sso_admin` / `app_sso_invite` / `app_sso_oauth_admin`, so the privilege is real LDAP membership visible to SSSD and sudo rather than a special case in app code. Resource creation nests `app_super_admin` -> `<slug>_admin` and `<slug>_admin` -> `<slug>_access`.
+- Resource metadata `icon` and `tagline`, collected on the admin form with a live icon preview.
+
+##### Fixed
+- **`GET /api/discovery/me` returned only `isPublic` resources for every human caller** — it read `req.user.groups`, which does not exist (`req.user` carries `memberOf`), so the empty list failed open. "My Services" was blank for everyone, and `isDirectoryAdmin()` was false even for real directory admins.
+- **The portal's "Discover More Services" was dead for every non-admin** — it called the admin-gated endpoint and swallowed the 403 into an empty array.
+- **Services reported no address** — `/me` had reimplemented `getMyAccess` without its parent-walking resolution, so a service reached at its host's IP resolved to nothing.
+- `GET /api/user/me` derived `isAdmin` from `memberOf`, which is only transitive with `nestgroup`; against a stock server an admin holding their group via nesting lost the entire admin UI while still passing every server-side check.
+- `utils/permission.js`'s `byGroup` saw only direct membership.
+- Adding an existing group member, and removing a group's last member, both returned bare 500s; now 409s that explain themselves.
+- `DELETE /api/directory-admin/resources/:id` deleted the resource before its edges and group links, orphaning rows on a mid-way failure.
+- `/api/directory-admin/audit-logs` shelled out to `tail` via `execSync`; replaced with a bounded async read.
+- Broken `api.html` link in the published docs.
+
+##### Changed
+- `@simpleworkjs/directory-schema` -> `^1.1.0`, declaring ten metadata keys the admin form always wrote but the schema never listed. Undeclared keys are dropped for non-admin callers — which blanked the portal's `OS:` field, hid every service's port, and left machine tokens unable to read the port mapping the firewall consumer exists to render.
+
+#### ldap-client — [v1.1.1](https://github.com/theta42/ldap-client/releases/tag/v1.1.1)
+
+##### Fixed
+- Sets `ldap_group_nesting_level = 5` so SSSD walks nested groups itself when pointed at a server without `nestgroup`. Against the SSO's bundled slapd the existing `memberof=` access filter is already transitive, so SSH login inherits nesting for free. The explicit `app_super_admin` clause is kept, to keep super-admin login working against a directory predating the new nesting.
+
+
+## [1.20.0] - 2026-07-30
+
+### Added
+- **`setup.sh` persists `SSO_GIT_COMMIT`/`PROXY_GIT_COMMIT`/`JUMP_GIT_COMMIT` into `./.env`** (new `env_upsert` helper), which `docker compose` auto-loads on every future invocation in this directory. Previously these were only `export`ed for the current shell, so an ad-hoc `docker compose up --build <service>` run later (outside a full `setup.sh` run) would build with an empty `GIT_COMMIT` arg — and since each submodule's checked-out `.git` is a pointer file, not a real repo, the in-container git fallback can't resolve it either, so the image silently baked "unknown" as its commit hash. `.gitignore`'s `.env` comment updated to describe this (it was previously labeled "legacy, no longer used").
+
+### Submodules bumped
+- jump-host `v1.10.2` -> [`v1.11.0`](https://github.com/theta42/jump-host/releases/tag/v1.11.0)
+- ldap-client `v1.0.0` -> [`v1.1.0`](https://github.com/theta42/ldap-client/releases/tag/v1.1.0)
+- proxy `v1.8.0` -> [`v1.9.0`](https://github.com/theta42/proxy/releases/tag/v1.9.0)
+- sso-manager-node `v1.9.0` -> [`v1.10.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.10.0)
+
+#### sso-manager-node — [v1.10.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.10.0)
+
+##### Added
+- `app_super_admin` cross-app group: members are full admins here regardless of `app_sso_admin` membership. The same group is now also recognized by proxy and jump-host, and by `ldap-client`'s SSSD access filter (SSH login on every host).
+
+##### Changed
+- Renamed the Executive page to Overview (route, view, `/api/metrics/overview`, nav label, docs). `/executive` kept as a 301 redirect.
+
+#### proxy — [v1.9.0](https://github.com/theta42/proxy/releases/tag/v1.9.0)
+
+##### Added
+- `app_super_admin` cross-app group recognized as a global admin (`conf.auth.adminGroups`).
+
+##### Changed
+- Users and Permissions pages: the always-visible sidebar "Add" forms are now an "Add User"/"Add Permission" button that opens an `app.modal` dialog, matching the hosts.ejs convention.
+- Let's Encrypt ACME account key now defaults to the already-persisted `/data` volume instead of a CWD-relative path (`./le_key.cert` -> `/app/le_key.cert` in the container), which was lost on every image rebuild.
+
+#### jump-host — [v1.11.0](https://github.com/theta42/jump-host/releases/tag/v1.11.0)
+
+##### Added
+- `app_super_admin` (cross-app) and `app_jump_admin` groups: super admins are full admins here same as `app_sso_admin`; jump admins get audit page/data access without other admin rights. The Audit page/API is now actually admin-gated server-side (previously the page shell rendered for any logged-in user, only its data was gated).
+- Host list adds Last connection/Last failed connection columns and highlights rows green (a session is live right now) or yellow (the most recent attempt failed), backed by new per-host last-success/last-fail timestamps.
+
+##### Changed
+- Dashboard's stat boxes and Top hosts/Top users cards moved to the Audit page. "All hosts" renamed to "My hosts".
+
+#### ldap-client — [v1.1.0](https://github.com/theta42/ldap-client/releases/tag/v1.1.0)
+
+##### Added
+- `app_super_admin` cross-app group now grants SSH login access to every host (`ldap_access_filter` + `ldap_access_groups`), matching the same group's admin rights in sso-manager-node, proxy, and jump-host. Sudo is not yet extended to super admins (`ldap_sudo_search_filter` remains non-functional on this SSSD version — pre-existing, documented gap).
+
+## [1.19.0] - 2026-07-30
+
+### Added
+- **New `ldap-client` submodule + `ldap-test-host` service** (`jump-host` compose profile): a real SSSD + AuthorizedKeysCommand LDAP-joined downstream host for testing jump-host's actual key-injection -> upstream-connect flow end-to-end against this stack's own local LDAP, instead of a container with a manually-dropped public key in `authorized_keys`. Verified live (SSH CLI and WinSCP) through jump-host's `uid_-_target` grammar.
+
+#### ldap-client — [v1.0.0](https://github.com/theta42/ldap-client/releases/tag/v1.0.0) (first tagged release)
+
+##### Added
+- Docker test fixture (`Dockerfile` + `entrypoint.sh`): Ubuntu 22.04 + sssd + sshd, no systemd required.
+
+##### Fixed
+Building that fixture surfaced three real bugs that would break login on any deployment, not just the test fixture:
+- `sssd.conf.mo` used `ldap_bind_dn`/`ldap_bind_pw`, which aren't real SSSD options — corrected to `ldap_default_bind_dn` / `ldap_default_authtok(_type)`.
+- `sssd.conf.mo` had no explicit `services =` list, so SSSD started only its backend, never the nss/pam responders — `getent passwd <ldap-user>` silently failed even with the domain reachable.
+- `ldap-ssh-key.sh`'s `memberof` filter was missing the `cn=` prefix on the group name, so the AuthorizedKeysCommand script always returned zero keys for a correctly-provisioned user — no error, just silently nothing.
+
+#### sso-manager-node — [v1.9.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.9.0)
+
+##### Added
+- Directory modal's Associated LDAP Groups tab now supports full membership management: view, add, and remove members/owners of each associated group directly from the tab.
+- `app.util.revealItem()` (shared `app-base.js`): scrolls a just-added/-edited element into view and flashes its background.
+
+##### Changed
+- Groups page's search/sort bar is now sticky while scrolling.
+- Directory table: Kind/Name/Env/Host merged into a single "Resource" column.
+
+#### proxy — [v1.8.0](https://github.com/theta42/proxy/releases/tag/v1.8.0)
+
+##### Added
+- Users backed by SSO/OIDC login are now marked "External (SSO)" and read-only (password-change hidden client-side, `PUT /password/:username` rejects with 403 server-side). Redis user-backend only.
+
+##### Changed
+- All pages now wrap their content in a standard-width container, matching sso-manager-node instead of rendering full-bleed.
+- Users and Permissions pages converted from bare `<table>`s to the card-grid convention already used on the Groups page.
+
+#### jump-host — [v1.10.2](https://github.com/theta42/jump-host/releases/tag/v1.10.2)
+
+##### Changed
+- Dashboard, Sessions, and Audit pages now match sso-manager-node/proxy's page width.
+- Audit's nav entry is now admin-gated (`groups: ['admin']`).
+
+### Bumped
+- sso-manager-node -> [v1.9.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.9.0)
+- proxy -> [v1.8.0](https://github.com/theta42/proxy/releases/tag/v1.8.0)
+- jump-host -> [v1.10.2](https://github.com/theta42/jump-host/releases/tag/v1.10.2)
+- ldap-client -> [v1.0.0](https://github.com/theta42/ldap-client/releases/tag/v1.0.0) (new submodule)
+
+## [1.18.0] - 2026-07-28
+
+### Changed
+Cross-app API-token self-service UI unification: all 3 apps now share the
+same card-grid list, "+ New Token" modal-based create flow, `app.modal`-based
+secret reveal, and Edit modal (with real created-by/on audit metadata).
+
+#### sso-manager-node — [v1.8.2](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.2), [v1.8.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.3)
+
+**v1.8.2**
+
+##### Fixed
+- **Creating a new OAuth integration didn't reliably show the "save this client secret now" reveal modal** — `saveResource()` called `app.modal.close()` immediately before conditionally showing the secret via `app.modal.open()`. `app.modal` is a singleton, and `close()` immediately followed by `open()` collides with Bootstrap's hide-transition guard. An intervening `await loadResources()` made this race unlikely to lose in practice, but not guaranteed to — found while fixing the same, guaranteed-to-lose bug in jump-host and proxy's API-token create flows.
+
+**v1.8.3**
+
+##### Changed
+- **`profile.ejs`'s self-service API-token UI unified onto `app.modal`**, matching the pattern already shipped this round in `directory.ejs`, proxy, and jump-host: the static `#secretModal`/`#editModal` elements are retired in favor of the shared `app.modal` singleton, the always-visible inline create-form card becomes a "+ New Token" button + modal, and badge classes switch from `bg-*` to `text-bg-*`.
+- Checkmark-flash copy feedback (silently broken by FontAwesome's `<i>`→`<svg>` replacement) replaced with toast-based `copyFieldValue`, matching proxy and jump-host.
+
+#### proxy — [v1.7.0](https://github.com/theta42/proxy/releases/tag/v1.7.0)
+
+##### Added
+- **API tokens: "+ New Token" modal button (replacing the always-visible inline create-form card) and a new Edit modal** — continues the cross-app API-token UI unification started in jump-host. The Edit modal's footer shows real created-by/on data; the `PUT /api-token/:id` route already fully supported editing, so no backend change was needed.
+
+##### Fixed
+- **Creating an API token didn't show the "save this secret now" reveal modal** — the create flow called `app.modal.close()` immediately before `app.modal.open()` (to show the secret) in the same tick; since `app.modal` is a singleton, that collided with Bootstrap's hide-transition guard and the reveal modal silently never appeared.
+
+#### jump-host — [v1.10.0](https://github.com/theta42/jump-host/releases/tag/v1.10.0), [v1.10.1](https://github.com/theta42/jump-host/releases/tag/v1.10.1)
+
+**v1.10.0**
+
+##### Added
+- **API-token UI unified with sso-manager-node/proxy**: card grid replacing the bare table, a new Edit modal (footer shows real created-by/on data), and a Description field on both the create and edit flows — the model and API already fully supported all of this, it just wasn't exposed anywhere in the dashboard.
+
+##### Changed
+- `@simpleworkjs/frontend` bumped to `^0.2.6` (this app was still on `^0.2.5`).
+
+**v1.10.1**
+
+##### Fixed
+- **The API-token reveal modal silently didn't show after creating a token** — `submitApiToken()` called `app.modal.close()` immediately before `showToken()`'s `app.modal.open()` in the same tick, colliding with Bootstrap's hide-transition guard on the singleton modal. Same root cause as the OAuth-secret-reveal race fixed in sso-manager-node (v1.8.2) and the create-token race fixed in proxy (v1.7.0).
+
+### Bumped
+- sso-manager-node -> [v1.8.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.3)
+- proxy -> [v1.7.0](https://github.com/theta42/proxy/releases/tag/v1.7.0)
+- jump-host -> [v1.10.1](https://github.com/theta42/jump-host/releases/tag/v1.10.1)
+
+## [1.17.0] - 2026-07-28
+
+### Added
+- **proxy's host modal now has a footer (created/updated-by/on metadata) and a linkable `/hosts/{host}` URL**, migrated onto the same shared `app.modal` component as sso-manager-node's resource modal — continuing the entity-modal standardization across the stack.
+
+### Fixed
+- **proxy: the Let's-Encrypt challenge-type/wildcard-matching visibility logic could stop reacting to the hostname field after the first Add/Edit host**, and **the SSO allow-list autocomplete could go empty starting on the second Add/Edit** — both were DOM-rebuild timing bugs in the same class as the resource-modal fixes already shipped.
+- **sso-manager-node: the resource modal's "Associated LDAP Groups" autocomplete went empty after the first Add/Edit** — same DOM-rebuild timing bug, now fixed.
+
+### Bumped
+- sso-manager-node -> [v1.8.1](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.1)
+- proxy -> [v1.6.0](https://github.com/theta42/proxy/releases/tag/v1.6.0)
+
+## [1.16.0] - 2026-07-28
+
+### Added
+- **"Quick Jump" copy-to-clipboard section on the jump-host dashboard** — one-click-copy SSH commands (interactive-picker mode, plus a per-host `uid_-_target` grammar-mode command) instead of having to remember/reconstruct the format by hand.
+
+### Fixed
+- **jump-host audit records for a failed downstream connection only ever said `upstream-unreachable`**, with no way to tell a network-layer failure from an auth failure — the real error (ECONNREFUSED, ETIMEDOUT, an ssh2 auth-failure message, etc.) is now captured and shown as a tooltip on the audit table's fail badge.
+
+### Bumped
+- jump-host -> [v1.9.0](https://github.com/theta42/jump-host/releases/tag/v1.9.0)
+
+## [1.15.0] - 2026-07-28
+
+### Fixed
+- **sso-manager's Directory data (every site/host/service/oauth-client resource and their relationships/LDAP-group associations) had no persistent volume** — `@simpleworkjs/orm` fell back to `./config/inventory.sqlite` (relative to the app's `/app` cwd) whenever `conf.orm` wasn't set, which sits in the container's ephemeral writable layer, not any mounted volume. Every container recreate (`docker compose up --build`, `down`/`up`, an image rebuild) silently wiped the entire Directory Management page. `setup.sh`'s generated `sso-secrets.js` (and the example template) now set `orm: { dialect: 'sqlite', storage: '/data/inventory.sqlite' }`, co-locating it with the already-persisted `sso-data` volume (where Redis lives). **Existing deployments**: this repo doesn't rewrite an operator's existing `config/sso-secrets.js` (re-running `setup.sh` leaves it untouched by design) — add the `orm` block above manually, and copy the container's current `/app/config/inventory.sqlite` to `/data/inventory.sqlite` *before* recreating the container, or the existing Directory data will be lost on the next recreate instead of migrated.
+
+### Bumped
+- sso-manager-node -> [v1.8.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.0)
+
+## [1.14.0] - 2026-07-28
+
+### Fixed
+- **jump-host's Redis had zero persistence** (`--save '' --appendonly no`, no data-dir volume) — every container rebuild/recreation (including a `setup.sh` re-run) silently wiped all sessions, in-flight OAuth logins, and any admin-created API token. This is the root cause of the reported "re-running setup.sh breaks OAuth with jump" — the jump-host container gets recreated, and any token or in-flight login vanished with it, while proxy was unaffected because its Redis was already persisted. Now jump-host's Redis persists (AOF + periodic RDB) to `/data`, mounted as a new named volume, `jump-redis-data`. Verified live: minted a PAT, force-recreated the container, confirmed the same PAT still authenticated afterward.
+
+### Changed
+- `docker-compose.yml`: added the `jump-redis-data` volume, mounted at `/data` on the `jump-host` service.
+
+### Bumped
+- jump-host -> [v1.8.1](https://github.com/theta42/jump-host/releases/tag/v1.8.1)
+
+## [1.13.0] - 2026-07-28
+
+### Fixed
+Found via feedback on a fresh install:
+- **jump-host's OAuth client had no parent in the Directory.** `seedDirectory()` only ever linked the proxy's OAuth client; jump-host's own (minted by `provisionJumpHost`) was created but never passed through, so it never got a `ResourceEdge`. Existing deployments self-heal on the next `setup.sh` run.
+- **TUI-mode SSH connections (bare `ssh user@host`) could drop** with "PTY allocation request failed" / "shell request failed" — a session-listener race in jump-host, same class of bug `runGrammar` already had a fix for.
+- **Every form submit briefly showed literal HTML** instead of a loading spinner, across all three apps.
+- **`POST /api/user/` and `PUT /api/user/password` had no success message** — a green notification with nothing in it right after adding a user.
+- **The login page gave no explanation for why the user landed there** when redirected mid-OAuth-flow.
+
+### Changed
+- **Directory: tree view is now the only view; clicking a resource's name opens its detail modal.**
+
+### Bumped
+- sso-manager-node -> [v1.7.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.7.0)
+- proxy -> [v1.5.3](https://github.com/theta42/proxy/releases/tag/v1.5.3)
+- jump-host -> [v1.8.0](https://github.com/theta42/jump-host/releases/tag/v1.8.0)
+
+No `setup.sh` or compose change. Also confirmed (no fix needed): the Let's Encrypt ACME account key persists correctly across container rebuilds — `lua-resty-auto-ssl`'s Redis storage adapter writes through the bundled Redis, which is started with `--appendonly yes` into `/data`, mapped to the persisted `proxy-data` volume. Only an explicit `docker-compose down -v` / volume removal would lose it (which is also what's required, and expected, on a domain change).
+
+## [1.12.0] - 2026-07-28
+
+### Bumped
+- sso-manager-node -> [v1.6.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.3) — fixes the root cause of a real "lost user" report: `routes/group.js` never invalidated the User cache on membership changes, so an account added to the `app_sso_service_account` marker group (which hides accounts from the Users page's People tab) could look like it had vanished for up to 5 minutes — and, separately, could be added to that group with no warning at all. Both fixed; see the linked release for detail.
+
+No `setup.sh` or compose change.
+
+## [1.11.0] - 2026-07-28
+
+### Added
+- **`test/check_jump_ldap_tls.js`**, wired into the `Lint` workflow: a static consistency check on the jump-secrets.js template `bootstrap.js` generates, so the `ldap://` + `tlsOptions` mistake that broke every SSH login in 1.10.0 fails CI before it ever reaches a real deployment again.
+- **A static "no native `alert()`/`confirm()`/`prompt()`" check** is now part of all three apps' own test suites (they block all further browser events on the page — see 1.9.0/1.10.0's release notes).
+
+### Bumped
+- sso-manager-node -> [v1.6.2](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.2) — fixes `DELETE /api/oauth/client/:id` (`client.remove is not a function`, a genuine 500 masked by tests that never checked the response status), plus the regression test above.
+- proxy -> [v1.5.2](https://github.com/theta42/proxy/releases/tag/v1.5.2) — the regression test above.
+- jump-host -> [v1.7.1](https://github.com/theta42/jump-host/releases/tag/v1.7.1) — the regression test above.
+
+No `setup.sh` or compose change.
+
+## [1.10.0] - 2026-07-27
+
+### Fixed
+- **`bootstrap/bootstrap.js`'s jump-secrets.js template now points jump-host at `ldaps://sso-manager:636`**, not `ldap://sso-manager:389`. The plain-port URL combined with jump-host's `tlsOptions` made `ldapts` attempt implicit TLS against a port serving plaintext LDAP — slapd dropped every connection before any LDAP message parsed, so SSH password login failed for every account, with any password, indistinguishable from a wrong credential. Root-caused by standing up a local jump-host, editing its config, and calling `getUser`/`checkPassword` directly inside the container. **Existing deployments must edit `./config/jump-secrets.js` themselves** (this template only affects fresh bootstraps) — see theta42/theta-suite#99. Companion defensive fix: [simpleworkjs/ldap v1.0.2](https://github.com/simpleworkjs/ldap/releases/tag/v1.0.2) now rejects this `ldap://` + `tlsOptions` combination outright.
+
+### Bumped
+- jump-host -> [v1.7.0](https://github.com/theta42/jump-host/releases/tag/v1.7.0) — adds self-service API tokens (create/list/rotate/revoke from its dashboard); jump-host previously had none.
+
+No `setup.sh` or compose change.
+
+## [1.9.0] - 2026-07-27
+
+### Bumped
+- sso-manager-node -> [v1.6.1](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.1)
+- proxy -> [v1.5.1](https://github.com/theta42/proxy/releases/tag/v1.5.1)
+
+Both apps had every native `alert()`/`confirm()` call removed, replaced by
+`@simpleworkjs/frontend`'s `app.messages.action`/`confirm`/`toast` (the
+same modules adopted in [1.8.0](#180---2026-07-27)). This was found live,
+mid browser-verification of that release: clicking sso-manager-node
+directory.ejs's "Rotate Client Secret" triggered a native `confirm()`,
+which blocks all further browser events on the page — a real hazard for
+anyone driving the app with browser automation, not just a cosmetic
+inconsistency. sso-manager-node also dropped `app.user.remove`/
+`app.oauthClient.remove` from `public/js/app.js` (dead code with a native
+`confirm()` guard and zero callers).
+
+No `setup.sh`, compose, or config change.
+
+## [1.8.0] - 2026-07-27
+
+### Bumped
+- sso-manager-node -> [v1.6.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.0)
+- proxy -> [v1.5.0](https://github.com/theta42/proxy/releases/tag/v1.5.0)
+- jump-host -> [v1.6.0](https://github.com/theta42/jump-host/releases/tag/v1.6.0)
+
+All three apps adopt the newly published `@simpleworkjs/frontend` package's
+`app.messages`, `app.modal`, and `app.validate` modules, replacing the
+vendored `app.util.actionMessage`/`actionConfirm`/`alert` in
+`public/lib/js/app-base.js` (byte-identical across all three apps) and the
+vendored `public/lib/js/val.js` (byte-identical in sso-manager-node and
+jump-host, and the same engine plus proxy-only DNS/hostname rules in proxy).
+Message content is now HTML-escaped — the ad hoc `app.util.alert()` this
+replaces had none — and `app.messages.action` falls back to a page-wide
+toast when there's no inline `.actionMessage` target on the page. proxy's
+`host`/`target`/`hostname` wildcard-DNS validation rules (mirroring
+`utils/hostname_validate.js`) move to its own `public/js/app.js`, registered
+via `$.validateSettings`, since they're proxy-specific and don't belong in
+the shared package's generic rule set (`eq`/`user`/`password`/`ip`).
+jump-host doesn't currently use any `[validate]` attributes, so its `val.js`
+swap is dedup/future-proofing rather than a behavior change.
+
+`app.api`/`app.auth`/`app.pubsub`/`app.socket` in each app's `app-base.js`
+are untouched: they're app-specific (a dual-mode callback/promise API with
+`auth-token` header injection) and not something the frontend package's
+generic `app.js` provides, so it isn't loaded.
+
+No `setup.sh`, compose, or config change.
+
+## [1.7.0] - 2026-07-27
+
+### Bumped
+- sso-manager-node -> [v1.5.1](https://github.com/theta42/sso-manager-node/releases/tag/v1.5.1)
+- jump-host -> [v1.5.0](https://github.com/theta42/jump-host/releases/tag/v1.5.0)
+
+Two production bugs fixed: `PUT /api/user/:uid` 500'd with an LDAP
+`ObjectClassViolationError` when setting `sshPublicKey` on any account
+predating the `ldapPublicKey` objectClass (notably the bootstrap admin) —
+and the exact same bug, in the shared `@simpleworkjs/ldap` package's
+`addSshKey`, was silently aborting SSH connections at jump-host's
+key-injection step for the same class of accounts. Both are fixed by
+ensuring the objectClass is present before writing the attribute. Also
+fixed: the Directory's "add resource" modal left the parent-Service
+dropdown blank when adding an OAuth Integration.
+
+Jump-host's web dashboard also gained a "Hosts you can reach" list
+(admins see "All hosts") — previously it only showed usage metrics with
+no way to see your actual access from the browser.
+
+No `setup.sh`, compose, or config change.
+
+## [1.6.0] - 2026-07-26
+
+### Bumped
+- jump-host -> [v1.4.0](https://github.com/theta42/jump-host/releases/tag/v1.4.0)
+
+Jump-host gains **standalone mode**: it can now run with no LDAP directory and
+no SSO Manager at all, storing users and hosts itself via
+`@simpleworkjs/orm` (Sequelize; SQLite by default, any Sequelize-supported
+dialect). This is an app-internal capability, opt-in via
+`standalone.enabled` in jump-host's own config — the bundled theta-suite stack
+is unaffected and continues to wire jump-host to the shared LDAP directory
+and SSO Manager as before. Two bugs were also fixed in jump-host's SSH
+server: an ephemeral listen port (`0`) was silently overridden back to the
+default, and session listeners could miss a client's immediate `exec`/`shell`
+request.
+
+No `setup.sh`, compose, or config change on the theta-suite side.
+
+## [1.5.0] - 2026-07-26
+
+### Bumped
+- sso-manager-node -> [v1.5.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.5.0)
+- proxy -> [v1.4.0](https://github.com/theta42/proxy/releases/tag/v1.4.0)
+- jump-host -> [v1.3.0](https://github.com/theta42/jump-host/releases/tag/v1.3.0)
+
+This release finishes the UI half of the unification that 1.4.0 deferred: the
+three apps now share one front-end shell. `views/top.ejs`, `views/bottom.ejs`
+and `public/lib/js/app-base.js` are byte-identical across sso-manager-node,
+proxy and jump-host, and everything per-app moved into each repo's new
+`nodejs/utils/ui.js` (nav items and the groups that may see them, footer links,
+favicon, profile/logout targets, update-banner on/off). Nav gating is one model
+everywhere — the shell reveals `.group-required-<cn>` from `GET /api/user/me`,
+normalising sso's LDAP DNs and the OIDC clients' group CNs to the same shape,
+with the clients' `isAdmin` flag exposed as a synthetic `admin` group. jQuery is
+4.0.0 and EJS 3.1.10 in all three.
+
+Five client-side bugs were fixed along the way, including two that broke real
+flows: `app.api.delete` ignored the callback that `formAJAX` passes (so
+DELETE-method forms — the proxy's host and DNS delete buttons — never refreshed),
+and the login page threw on every logged-out visit while revealing its card.
+
+No `setup.sh`, compose or config change: this is app-internal UI work. Verified
+by driving a full stack of all three apps in a browser — every page renders
+console-clean, nav gating is correct per role, and the OIDC login round trip
+completes on both OIDC clients.
+
+sso-manager-node 1.5.0:
+
+### Changed
+- **Unified the front-end UI shell across the three theta42 apps.** `views/top.ejs`, `views/bottom.ejs` and `public/lib/js/app-base.js` are now byte-identical in sso-manager-node, proxy and jump-host, so the apps look and behave the same and a shell change lands in one edit per repo instead of three divergent ones. Everything that differs between the apps moved into a new `nodejs/utils/ui.js`, exposed to every render as `ui` via `app.locals`: nav items and the groups that may see them, footer repo/license/docs/Terms links, favicon, the profile and post-logout targets, and whether the update banner exists at all.
+- **One nav-gating model everywhere.** `app-base.js` reveals `.group-required-<cn>` elements for each group the current user is in, read from `GET /api/user/me`. sso-manager-node reports LDAP DNs in `memberOf` and the OIDC clients report CNs in `groups`; both normalise to CNs client-side, and the clients' effective-rights `isAdmin` flag is exposed as a synthetic `admin` group — so one gating model covers a group-based provider and boolean-admin clients without either app learning the other's response shape.
+- **`GET /api/user/me` is fetched once per page load and cached** (`app.auth.loadUser`). The nav, per-view `forceLogin` and every group-gated element read that one promise instead of issuing their own request.
+- `app.auth.isLoggedIn` is dual-mode: it returns a Promise **and** invokes an optional node-style callback, so the async and callback call styles both work against one shared `top.ejs`.
+- `app.auth.forceLogin` no longer uses `$.holdReady` (removed in jQuery 4). An unauthenticated user is redirected to `/login?redirect=<path>`; group requirements are still enforced, and `logOut` now only clears the session, leaving the destination to the caller (`ui.logoutRedirect`).
+- Dependency alignment across all three apps: `jquery` `^4.0.0` and `ejs` `^3.1.10`.
+
+### Fixed
+- **`app.api.delete` dropped its callback when called by `formAJAX`.** `formAJAX` always passes the serialized form as the second argument, so a DELETE-method form's callback landed in the data slot and never ran. `delete` now accepts both `(url, callback)` and `(url, data, callback)`.
+- **`app.api.post`/`put` referenced an undefined `callback2`** and threw when handed a non-function callback. Both are now dual-mode Promise/callback.
+- **The login page's "reveal the card once we know you're logged out" branch threw** (`Cannot read properties of null`) whenever the logged-in check answered before the parser reached that element — which it always did without a stored token. It now runs on DOM ready.
+- **`logInRedirect` on the legacy `/login/<path>` form kept only the path.** The OIDC provider routes an unauthenticated authorization request through `/login/oauth/authorize?client_id=…&state=…`; dropping the query there loses the entire authorization request. The suffix form now preserves its query string.
+
+### Fixed (sso-manager-node)
+- `public/lib/js/val.js` shadowed `message` with `let` inside `validateField`, so a custom rule's return value never reached `validateMessage` and the caller always saw the generic length message. Resolved by adopting the shared validator, which also brings the `target`/`hostname` rules and the real password policy (>= 8 chars, and either 12+ or 3 of 4 character classes) to this app.
+- `public/js/app.js` used `$.isFunction`, removed in jQuery 4.
+
+### Added (sso-manager-node)
+- `GET /api/user/me` now also reports `isAdmin` (membership in `app_sso_admin`), the single effective-rights flag the shared UI shell gates the update banner on. Group-level gating still reads `memberOf`.
+
+### Verified
+- Browser-verified against a full theta-suite stack (sso-manager + proxy + jump-host): every top-level page renders with a clean console; nav gating is correct for admin and non-admin; `forceLogin`'s onboarding and group gates fire; `val.js` blocks a weak password and accepts a strong one through a real form submit; the DELETE-method forms work; and the OIDC login round trip (authorize with PKCE -> login -> consent -> callback -> token fragment) completes on both OIDC clients.
+
+proxy 1.4.0:
+
+### Changed
+- **Unified the front-end UI shell across the three theta42 apps.** `views/top.ejs`, `views/bottom.ejs` and `public/lib/js/app-base.js` are now byte-identical in sso-manager-node, proxy and jump-host, so the apps look and behave the same and a shell change lands in one edit per repo instead of three divergent ones. Everything that differs between the apps moved into a new `nodejs/utils/ui.js`, exposed to every render as `ui` via `app.locals`: nav items and the groups that may see them, footer repo/license/docs/Terms links, favicon, the profile and post-logout targets, and whether the update banner exists at all.
+- **One nav-gating model everywhere.** `app-base.js` reveals `.group-required-<cn>` elements for each group the current user is in, read from `GET /api/user/me`. sso-manager-node reports LDAP DNs in `memberOf` and the OIDC clients report CNs in `groups`; both normalise to CNs client-side, and the clients' effective-rights `isAdmin` flag is exposed as a synthetic `admin` group — so one gating model covers a group-based provider and boolean-admin clients without either app learning the other's response shape.
+- **`GET /api/user/me` is fetched once per page load and cached** (`app.auth.loadUser`). The nav, per-view `forceLogin` and every group-gated element read that one promise instead of issuing their own request.
+- `app.auth.isLoggedIn` is dual-mode: it returns a Promise **and** invokes an optional node-style callback, so the async and callback call styles both work against one shared `top.ejs`.
+- `app.auth.forceLogin` no longer uses `$.holdReady` (removed in jQuery 4). An unauthenticated user is redirected to `/login?redirect=<path>`; group requirements are still enforced, and `logOut` now only clears the session, leaving the destination to the caller (`ui.logoutRedirect`).
+- Dependency alignment across all three apps: `jquery` `^4.0.0` and `ejs` `^3.1.10`.
+
+### Fixed
+- **`app.api.delete` dropped its callback when called by `formAJAX`.** `formAJAX` always passes the serialized form as the second argument, so a DELETE-method form's callback landed in the data slot and never ran. `delete` now accepts both `(url, callback)` and `(url, data, callback)`.
+- **`app.api.post`/`put` referenced an undefined `callback2`** and threw when handed a non-function callback. Both are now dual-mode Promise/callback.
+- **The login page's "reveal the card once we know you're logged out" branch threw** (`Cannot read properties of null`) whenever the logged-in check answered before the parser reached that element — which it always did without a stored token. It now runs on DOM ready.
+- **`logInRedirect` on the legacy `/login/<path>` form kept only the path.** The OIDC provider routes an unauthenticated authorization request through `/login/oauth/authorize?client_id=…&state=…`; dropping the query there loses the entire authorization request. The suffix form now preserves its query string.
+
+### Added
+- `.group-required { display: none }` in `public/css/styles.css`, the base rule the shared gating model reveals against.
+- Admin-only nav items lost their inline `display: none` in favour of that class, and the brand link points at `/` instead of `#`.
+
+### Verified
+- Browser-verified against a full theta-suite stack (sso-manager + proxy + jump-host): every top-level page renders with a clean console; nav gating is correct for admin and non-admin; `forceLogin`'s onboarding and group gates fire; `val.js` blocks a weak password and accepts a strong one through a real form submit; the DELETE-method forms work; and the OIDC login round trip (authorize with PKCE -> login -> consent -> callback -> token fragment) completes on both OIDC clients.
+
+jump-host 1.3.0:
+
+### Changed
+- **Unified the front-end UI shell across the three theta42 apps.** `views/top.ejs`, `views/bottom.ejs` and `public/lib/js/app-base.js` are now byte-identical in sso-manager-node, proxy and jump-host, so the apps look and behave the same and a shell change lands in one edit per repo instead of three divergent ones. Everything that differs between the apps moved into a new `nodejs/utils/ui.js`, exposed to every render as `ui` via `app.locals`: nav items and the groups that may see them, footer repo/license/docs/Terms links, favicon, the profile and post-logout targets, and whether the update banner exists at all.
+- **One nav-gating model everywhere.** `app-base.js` reveals `.group-required-<cn>` elements for each group the current user is in, read from `GET /api/user/me`. sso-manager-node reports LDAP DNs in `memberOf` and the OIDC clients report CNs in `groups`; both normalise to CNs client-side, and the clients' effective-rights `isAdmin` flag is exposed as a synthetic `admin` group — so one gating model covers a group-based provider and boolean-admin clients without either app learning the other's response shape.
+- **`GET /api/user/me` is fetched once per page load and cached** (`app.auth.loadUser`). The nav, per-view `forceLogin` and every group-gated element read that one promise instead of issuing their own request.
+- `app.auth.isLoggedIn` is dual-mode: it returns a Promise **and** invokes an optional node-style callback, so the async and callback call styles both work against one shared `top.ejs`.
+- `app.auth.forceLogin` no longer uses `$.holdReady` (removed in jQuery 4). An unauthenticated user is redirected to `/login?redirect=<path>`; group requirements are still enforced, and `logOut` now only clears the session, leaving the destination to the caller (`ui.logoutRedirect`).
+- Dependency alignment across all three apps: `jquery` `^4.0.0` and `ejs` `^3.1.10`.
+
+### Fixed
+- **`app.api.delete` dropped its callback when called by `formAJAX`.** `formAJAX` always passes the serialized form as the second argument, so a DELETE-method form's callback landed in the data slot and never ran. `delete` now accepts both `(url, callback)` and `(url, data, callback)`.
+- **`app.api.post`/`put` referenced an undefined `callback2`** and threw when handed a non-function callback. Both are now dual-mode Promise/callback.
+- **The login page's "reveal the card once we know you're logged out" branch threw** (`Cannot read properties of null`) whenever the logged-in check answered before the parser reached that element — which it always did without a stored token. It now runs on DOM ready.
+- **`logInRedirect` on the legacy `/login/<path>` form kept only the path.** The OIDC provider routes an unauthenticated authorization request through `/login/oauth/authorize?client_id=…&state=…`; dropping the query there loses the entire authorization request. The suffix form now preserves its query string.
+
+### Added
+- `.group-required { display: none }` in `public/css/styles.css`, the base rule the shared gating model reveals against.
+- `#spa-shell` dropped its inline `margin-top`; `styles.css` already sets it and the shared shell adjusts it when a banner is shown.
+
+### Verified
+- Browser-verified against a full theta-suite stack (sso-manager + proxy + jump-host): every top-level page renders with a clean console; nav gating is correct for admin and non-admin; `forceLogin`'s onboarding and group gates fire; `val.js` blocks a weak password and accepts a strong one through a real form submit; the DELETE-method forms work; and the OIDC login round trip (authorize with PKCE -> login -> consent -> callback -> token fragment) completes on both OIDC clients.
+
+## [1.4.0] - 2026-07-25
+
+### Bumped
+- sso-manager-node -> [v1.4.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.4.0)
+- proxy -> [v1.3.0](https://github.com/theta42/proxy/releases/tag/v1.3.0)
+- jump-host -> [v1.2.0](https://github.com/theta42/jump-host/releases/tag/v1.2.0)
+
+This release unifies the three theta42 apps onto shared `@simpleworkjs/*` packages
+(`oidc-client`, `directory-schema`, `ldap`, `app-stack` — published under the
+simpleworkjs org at 1.0.0), replacing each app's byte-identical forks of the same
+code so they share one codebase and API schema. It also fixes a security
+regression in the SSO directory discovery API (OAuth `client_secret_hash` leaked
+to every authenticated caller) and the envelope drift that broke jump-host
+bridging. The shared UI chrome (`top.ejs`/`bottom.ejs`, `app-base.js`, `val.js`)
+is intentionally **not** unified in this release — that work is deferred to a
+browser-verified session; see `UI_UNIFICATION_HANDOFF.md`. No `setup.sh` change:
+the new `@simpleworkjs/*` deps resolve from npm inside each app's image build
+(`npm ci` stays clean; no `file:`/`link:`).
+
+sso-manager-node 1.4.0:
+
+### Security
+- **The directory discovery API leaked OAuth `client_secret_hash` (and any secret-ish metadata key) to every authenticated caller.** `Resource` doesn't override `toJSON`, so the ORM serialized `metadata` wholesale — including the `client_secret_hash` stored on `kind:'oauth'` resources — across `GET /api/discovery/resources`, `/graph`, `/me`, `/resources/:slug`, and the directory-admin `GET /api/directory-admin/resources`. Every discovery read endpoint and the admin list now route through `projectResource`/`projectResources` from `@simpleworkjs/directory-schema`, which unconditionally strips secret keys (anything matching `/secret|password|privatekey/i`, including `client_secret_hash`) and, for non-directory-admins, reduces metadata to a public allowlist. Admins never receive `client_secret_hash` either.
+
+### Fixed
+- **Directory discovery envelope drift.** `routes/discovery.js` (the `autoRouter(Resource)` mounted live at `app.js:87`) returned **bare arrays**, not the `{ results: [...] }` envelope the directory contract specifies — so jump-host's `data.results || []` collapsed every per-group query to `[]` and no user could bridge. Discovery is now served by explicit `/resources`, `/resources/:slug`, `/graph`, `/me` handlers that all return the `{ results }` envelope. The dead `routes/api_discovery.js` (mounted at `app.js:112`, *after* the 404 catcher) and its mount were removed.
+- `GET /api/discovery/resources?group=<cn>` now returns 200 with `{ results: [...] }` instead of 404.
+
+### Added
+- `@simpleworkjs/directory-schema` — the directory contract: the `kind` enum, `Resource`/`ResourceEdge`/`ResourceGroup` field defs, the `{ results }` envelope, the security projection (`projectResource`/`projectResources`/`isDirectoryAdmin`), and the discovery client. `models/resource.js` imports the field defs; the discovery + directory-admin routes use the projection.
+- `@simpleworkjs/ldap` — `models/user_ldap.js` and `models/group_ldap.js` now take `escapeFilter`/`escapeDN` and `makeClient`/`withClient` from the shared package (via local wrappers that pass `conf`); sso keeps its rich `User.get`/`Group.get`/`User.login`/`User.addSSHkey` (posix/write-side stays app-local). sso's `makeClient` passes no `tlsOptions`, so cert validation is unchanged.
+- `@simpleworkjs/app-stack` — unified `build_info` (`{buildVersion, buildHash, buildYear}`) and the `static-modules` mounting helper. `utils/build_info.js` and the static-modules loop in `routes/index.js` use the shared helpers.
+- New `tests/discovery.test.js` (jest + supertest, runs under the docker harness): locks in the `{ results }` envelope on `/resources`, `/graph`, `/me`, `/resources/:slug`, the `?group=` 200-regression, and the no-`client_secret_hash`/no-secret-key guarantee for every caller.
+
+### Changed
+- Dependency alignment: `ldapts` `^8.1.2` → `^8.1.8`. The new `@simpleworkjs/*` deps resolve from the npm registry (`^1.0.0`); no `file:`/`link:` entries in the lockfile, so `npm ci` is clean in docker builds.
+- `build_info` export shape changed from `{commit, version}` to `{buildVersion, buildHash, buildYear}` (the shared shape used by all three apps).
+
+proxy 1.3.0:
+
+### Added
+- `@simpleworkjs/oidc-client` — the OIDC client (session models, auth router, OIDC utils, safe-redirect, local-admin bootstrap). Deleted the local `utils/oidc.js`, `utils/safe_redirect.js`, `models/oidc_state.js`, `models/token.js`, `models/auth.js`, `routes/auth.js`; `models/index.js` wires the factory. The per-host SSO in `routes/host_auth.js` is unchanged but consumes the shared OIDC utils.
+- `@simpleworkjs/ldap` — the ldapts client + RFC 4515/4514 escaping.
+- `@simpleworkjs/app-stack` — unified `build_info` (`{buildVersion, buildHash, buildYear}`) and the `static-modules` mounting helper. `utils/build_info.js` and the static-modules loop in `routes/render.js` now use the shared helpers.
+
+### Security
+- **LDAP filter injection in `User.get`.** The user lookup built its search filter by interpolating `data.username` raw into `(&(objectClass=inetOrgPerson)(uid=<username>))`. A username containing `*`, `(`, `)`, `\`, or NUL could widen or alter the filter (e.g. `*` → match-all). The filter value is now passed through `escapeFilter` from `@simpleworkjs/ldap` (RFC 4515 escaping).
+
+### Changed
+- Dependency alignment: `model-redis` `^1.5` → `^1.6.0`, `ldapts` `^8.1.2` → `^8.1.8`. The four new `@simpleworkjs/*` deps resolve from the npm registry (`^1.0.0`); no `file:`/`link:` entries in the lockfile, so `npm ci` is clean in docker builds.
+- `build_info` export shape changed from `{commit, version}` to `{buildVersion, buildHash, buildYear}` (the shared shape used by all three apps). The `/health` endpoint and footer now report `buildVersion`/`buildHash`.
+
+jump-host 1.2.0:
+
+### Added
+- `@simpleworkjs/oidc-client` — the OIDC client (session models, auth router, OIDC utils, safe-redirect, local-admin bootstrap). Deleted the local `utils/oidc.js`, `utils/safe_redirect.js`, `models/oidc_state.js`, `models/token.js`, `models/auth.js`, `routes/auth.js`; `models/index.js` wires the factory and the local-admin bootstrap.
+- `@simpleworkjs/directory-schema` — the sso↔jump-host directory contract. `utils/access.js` now fetches reachable hosts through the shared `createDirectoryClient` (`getResourcesByGroup`).
+- `@simpleworkjs/ldap` — `models/user_ldap.js` is now a thin wrapper over `createLdapClient`, preserving this app's loose TLS default (`rejectUnauthorized: false`) and the exact export shape.
+- `@simpleworkjs/app-stack` — unified `build_info` (`{buildVersion, buildHash, buildYear}`) and the `static-modules` mounting helper. `build_info` moved from `models/` to `utils/`; `routes/render.js` uses `mountStaticModules`.
+
+### Fixed
+- **Directory envelope drift was silently treated as "no reachable hosts".** `utils/access.js` previously read `data.results || []`, so if the SSO directory ever returned a bare array (envelope drift) every per-group query collapsed to `[]` and no user could bridge. The shared client now validates the `{ results }` envelope on every call and treats an envelope violation as a failed group fetch rather than silently returning `[]`.
+
+### Changed
+- Dependency alignment: `ldapts` `^8.1.2` → `^8.1.8`, `redis` `^4.7` → `^6.1.0` (the direct `redis` dep is unused — only `model-redis` is used, which already brings `redis` ^6.1.0). The new `@simpleworkjs/*` deps resolve from the npm registry (`^1.0.0`); no `file:`/`link:` entries in the lockfile, so `npm ci` is clean in docker builds.
+- `build_info` export shape changed from `{commit, version}` to `{buildVersion, buildHash, buildYear}` (the shared shape used by all three apps). The `/health` endpoint and footer now report `buildVersion`/`buildHash`.
+- `app-base.js` `forceLogin`/`logInRedirect` switched to the `?redirect=` query-param convention (matching the server-side `/login?redirect=` route).
+
+## [1.3.7] - 2026-07-23
+
+### Added
+- The bootstrap now provisions the jump host's **web-UI SSO login** when the jump host is enabled: it mints a dedicated `theta-jump` OAuth client and writes a full `oidc` block (endpoints, client id/secret, callback) plus a generated local anti-lockout admin password into `./config/jump-secrets.js`. Matches how the proxy's OIDC client is provisioned. An existing pre-OIDC `jump-secrets.js` (API token but no OIDC client) is regenerated so upgraders get SSO login. Requires jump-host ≥ v1.1.0.
+
 ## [1.3.6] - 2026-07-23
 
 ### Bumped
@@ -33,12 +881,12 @@ sso-manager-node 1.3.2:
 sso-manager-node 1.3.1:
 
 ### Added
-- The Directory documentation (`docs/directory.md`) is now surfaced: registered in-app at `/docs/directory` ("Directory & Inventory"), help-linked from the Directory page header, and linked from the docs-site index. Extended with the shared slug conventions (`site_<name>`, `host_<hostname>` — as used by ldap-client and the theta-env seed), the automatic-registration story (theta-env stack seeding, ldap-client Linux host enrollment), and the API surface (admin at `/api/directory-admin`, read-only graph at `/api/discovery`).
+- The Directory documentation (`docs/directory.md`) is now surfaced: registered in-app at `/docs/directory` ("Directory & Inventory"), help-linked from the Directory page header, and linked from the docs-site index. Extended with the shared slug conventions (`site_<name>`, `host_<hostname>` — as used by ldap-client and the theta-suite seed), the automatic-registration story (theta-suite stack seeding, ldap-client Linux host enrollment), and the API surface (admin at `/api/directory-admin`, read-only graph at `/api/discovery`).
 
 ### Changed
 - Direct LDAP binds are described as first-class, not "legacy", across README, DEPLOYMENT.md, docs, and the Dockerfile: Linux hosts are a primary consumer of the directory (PAM/SSSD login, LDAP-backed `sudo` via `sudoRole`, SSH public keys via openssh-lpk) — exactly what the custom schemas exist for.
 
-### theta-env own changes
+### theta-suite own changes
 
 ### Added
 - `CFG_SITE_NAME` in `setup.env` (right below `CFG_DOMAIN`, default `local`): names the SSO directory site the stack registers itself under — slug `site_<name>`, matching the `parentSlug` convention ldap-client-joined Linux hosts use, so they land under the same site.
@@ -114,7 +962,7 @@ sso-manager-node:
 ### Changed
 - Refreshed all README screenshots (dashboard, users, groups, OAuth apps) against the current UI, and added a new Sites & Replication screenshot.
 
-### theta-env own changes
+### theta-suite own changes
 - Refreshed `docs/images/sso-dashboard.png` and `docs/images/proxy-hosts.png` to match the submodules' updated screenshots.
 
 ## [1.1.20] - 2026-07-20
@@ -144,7 +992,7 @@ sso-manager-node:
 - `routes/index.js` now derives the displayed LDAPS URL from `conf.ldap.ldapsHost`/`ldapsPort` with fallback to the OAuth issuer host.
 - `docs/configuration.md`, `docs/ldap.md`, `DEPLOYMENT.md`, and `secrets.js.example` document the new `ldapsHost`/`ldapsPort` options and recommended network layouts.
 
-### theta-env own changes
+### theta-suite own changes
 - `setup.env.example` adds optional `CFG_LDAPS_HOST` for the internal LDAPS hostname.
 - `setup.sh` passes `CFG_LDAPS_HOST` into the generated `./config/sso-secrets.js` as `ldap.ldapsHost`.
 - `config.example/sso-secrets.js.example` documents `ldap.ldapsHost` / `ldap.ldapsPort`.
@@ -188,7 +1036,7 @@ sso-manager-node:
 ### Fixed
 - `models/email.js`: fixed from-address template rendering bug.
 
-### theta-env own changes
+### theta-suite own changes
 - `CHANGELOG.md` now embeds the full app-level release notes for each submodule bump, not just links.
 - `.env.example` no longer ships realistic-looking default passwords; values are clearly placeholders.
 - `config.example/*.js.example` comments now describe the actual `CONF_SECRETS` env-var loading mechanism.
@@ -328,10 +1176,10 @@ sso-manager-node:
 - proxy -> [v1.1.7](https://github.com/theta42/proxy/releases/tag/v1.1.7)
 - sso-manager-node -> [v1.1.6](https://github.com/theta42/sso-manager-node/releases/tag/v1.1.6)
 
-Both: redesigned the GitHub Pages docs site to match each app's own look (dark navbar/footer, Bootstrap 5, Font Awesome) instead of the generic `jekyll-theme-cayman` theme, added a real cross-page nav, SEO (`jekyll-seo-tag` + `jekyll-sitemap`), and mobile-responsive layout. theta-env's own docs site got the same treatment in this release too (see below).
+Both: redesigned the GitHub Pages docs site to match each app's own look (dark navbar/footer, Bootstrap 5, Font Awesome) instead of the generic `jekyll-theme-cayman` theme, added a real cross-page nav, SEO (`jekyll-seo-tag` + `jekyll-sitemap`), and mobile-responsive layout. theta-suite's own docs site got the same treatment in this release too (see below).
 
 ### Changed
-- theta-env's own docs site redesigned the same way -- dark navbar/footer using the shared theta42 logo (this repo has no app UI of its own), cross-page nav, SEO, mobile-responsive. `docs/index.md`'s "More docs" section removed (redundant with the new nav).
+- theta-suite's own docs site redesigned the same way -- dark navbar/footer using the shared theta42 logo (this repo has no app UI of its own), cross-page nav, SEO, mobile-responsive. `docs/index.md`'s "More docs" section removed (redundant with the new nav).
 - Added `docs/_site` to `.gitignore` (missing entirely before).
 
 ## [1.1.6] - 2026-07-16
@@ -364,7 +1212,7 @@ Both: bumped `jq-repeat` 2.0.1 -> 2.1.0. proxy fixed real breakage from the remo
 ## [1.1.3] - 2026-07-16
 
 ### Added
-- `CHANGELOG.md` (this file). Closes [#43](https://github.com/theta42/theta-env/issues/43).
+- `CHANGELOG.md` (this file). Closes [#43](https://github.com/theta42/theta-suite/issues/43).
 
 ### Bumped
 - proxy -> [v1.1.3](https://github.com/theta42/proxy/releases/tag/v1.1.3)
@@ -399,22 +1247,23 @@ First tagged release. Establishes the `vX.Y.Z` tag convention going forward.
 - proxy -> [v1.1.0](https://github.com/theta42/proxy/releases/tag/v1.1.0)
 - sso-manager-node -> [v1.1.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.1.0)
 
-[Unreleased]: https://github.com/theta42/theta-env/compare/v1.1.20...HEAD
-[1.1.17]: https://github.com/theta42/theta-env/compare/v1.1.16...v1.1.17
-[1.1.16]: https://github.com/theta42/theta-env/compare/v1.1.15...v1.1.16
-[1.1.15]: https://github.com/theta42/theta-env/compare/v1.1.14...v1.1.15
-[1.1.14]: https://github.com/theta42/theta-env/compare/v1.1.13...v1.1.14
-[1.1.13]: https://github.com/theta42/theta-env/compare/v1.1.12...v1.1.13
-[1.1.12]: https://github.com/theta42/theta-env/compare/v1.1.11...v1.1.12
-[1.1.11]: https://github.com/theta42/theta-env/compare/v1.1.10...v1.1.11
-[1.1.10]: https://github.com/theta42/theta-env/compare/v1.1.9...v1.1.10
-[1.1.9]: https://github.com/theta42/theta-env/compare/v1.1.8...v1.1.9
-[1.1.8]: https://github.com/theta42/theta-env/compare/v1.1.7...v1.1.8
-[1.1.7]: https://github.com/theta42/theta-env/compare/v1.1.6...v1.1.7
-[1.1.6]: https://github.com/theta42/theta-env/compare/v1.1.5...v1.1.6
-[1.1.5]: https://github.com/theta42/theta-env/compare/v1.1.4...v1.1.5
-[1.1.4]: https://github.com/theta42/theta-env/compare/v1.1.3...v1.1.4
-[1.1.3]: https://github.com/theta42/theta-env/compare/v1.1.2...v1.1.3
-[1.1.2]: https://github.com/theta42/theta-env/compare/v1.1.1...v1.1.2
-[1.1.1]: https://github.com/theta42/theta-env/compare/v1.1.0...v1.1.1
-[1.1.0]: https://github.com/theta42/theta-env/releases/tag/v1.1.0
+[Unreleased]: https://github.com/theta42/theta-suite/compare/v1.4.0...HEAD
+[1.4.0]: https://github.com/theta42/theta-suite/compare/v1.3.7...v1.4.0
+[1.1.17]: https://github.com/theta42/theta-suite/compare/v1.1.16...v1.1.17
+[1.1.16]: https://github.com/theta42/theta-suite/compare/v1.1.15...v1.1.16
+[1.1.15]: https://github.com/theta42/theta-suite/compare/v1.1.14...v1.1.15
+[1.1.14]: https://github.com/theta42/theta-suite/compare/v1.1.13...v1.1.14
+[1.1.13]: https://github.com/theta42/theta-suite/compare/v1.1.12...v1.1.13
+[1.1.12]: https://github.com/theta42/theta-suite/compare/v1.1.11...v1.1.12
+[1.1.11]: https://github.com/theta42/theta-suite/compare/v1.1.10...v1.1.11
+[1.1.10]: https://github.com/theta42/theta-suite/compare/v1.1.9...v1.1.10
+[1.1.9]: https://github.com/theta42/theta-suite/compare/v1.1.8...v1.1.9
+[1.1.8]: https://github.com/theta42/theta-suite/compare/v1.1.7...v1.1.8
+[1.1.7]: https://github.com/theta42/theta-suite/compare/v1.1.6...v1.1.7
+[1.1.6]: https://github.com/theta42/theta-suite/compare/v1.1.5...v1.1.6
+[1.1.5]: https://github.com/theta42/theta-suite/compare/v1.1.4...v1.1.5
+[1.1.4]: https://github.com/theta42/theta-suite/compare/v1.1.3...v1.1.4
+[1.1.3]: https://github.com/theta42/theta-suite/compare/v1.1.2...v1.1.3
+[1.1.2]: https://github.com/theta42/theta-suite/compare/v1.1.1...v1.1.2
+[1.1.1]: https://github.com/theta42/theta-suite/compare/v1.1.0...v1.1.1
+[1.1.0]: https://github.com/theta42/theta-suite/releases/tag/v1.1.0

README.md

@@ -1,9 +1,10 @@
-# theta-env
+# theta-suite
 
 The whole theta42 identity + access stack in one repo, brought up with a single
 command — for home labs and small businesses.
 
-It wires together two projects that already work on their own:
+It composes four applications around a shared [OpenBao](https://openbao.org/)
+secrets store, brought up with one command:
 
 - **[SSO Manager](https://github.com/theta42/sso-manager-node)** — an OIDC
   provider with a built-in LDAP directory (OpenLDAP) and a web UI for managing
@@ -11,12 +12,15 @@ It wires together two projects that already work on their own:
 - **[theta42/proxy](https://github.com/theta42/proxy)** — an OIDC-protected
   reverse proxy (OpenResty) that puts any of your apps behind SSO login and can
   look users up directly in LDAP.
+- **[Jump Host](https://github.com/theta42/jump-host)** — directory-driven SSH
+  access to your machines through one public entry point.
+- **[ldap-client](https://github.com/theta42/ldap-client)** — enrolls Linux
+  hosts into the directory for PAM/SSSD login, sudo, and SSH keys.
 
-Each project still runs **standalone** (`docker compose up` in its own folder);
-this repo just composes them and automates the first-run glue so they find each
-other.
+All four load their secrets from OpenBao at boot; `setup.sh` automates the
+first-run glue so they find each other and the secrets store.
 
-**Documentation:** [https://theta42.github.io/theta-env/](https://theta42.github.io/theta-env/)
+**Documentation:** [https://theta42.github.io/theta-suite/](https://theta42.github.io/theta-suite/)
 
 ## Screenshots
 
@@ -26,14 +30,18 @@ The SSO Manager and the proxy it fronts, both stood up by one `./setup.sh` run:
 | --- | --- |
 | [![SSO Manager dashboard](docs/images/sso-dashboard.png)](docs/images/sso-dashboard.png) | [![Proxy host list](docs/images/proxy-hosts.png)](docs/images/proxy-hosts.png) |
 
-**Why use this instead of running the two separately?** The two only become
-useful once the proxy is registered as an OIDC client of the SSO and pointed at
-the SSO's LDAP directory — and the SSO's domain has to match across half a dozen
-config fields or logins silently fail with `Invalid Credentials`. Doing that by
-hand is fiddly and easy to get wrong. `setup.sh` asks for your domain once (in
-`setup.env`), generates both config files with it filled in everywhere, registers
-the proxy as an OIDC client, and snapshots state before every rebuild — so you
-get a working SSO + proxy stack in one command and a safe way to upgrade it.
+## Configuration
+
+`setup.sh` automates the first-run glue between subprojects:
+- Asks for your domain once (in `setup.env`) and fills it in across all config files.
+- Registers the proxy as an OIDC client of the SSO.
+- Persists submodule commit hashes in `.env` for reproducibility (e.g., `SSO_GIT_COMMIT`, `PROXY_GIT_COMMIT`). This ensures future `docker compose` runs use the same submodule versions.
+
+**Why use this instead of running the two separately?** The two only become useful once the proxy is registered as an OIDC client of the SSO and pointed at the SSO's LDAP directory — and the SSO's domain has to match across half a dozen config fields or logins silently fail with `Invalid Credentials`. Doing that by hand is fiddly and easy to get wrong. `setup.sh` handles this automatically and snapshots state before every rebuild — so you get a working SSO + proxy stack in one command and a safe way to upgrade it.
+
+## Unified Release Status
+- ✅ **Phase 1 (oidc-client)**: Complete.
+- ⏳ **Phases 2-5**: Pending (see [roadmap](#)).
 
 ```
             ┌──────────────────────────────────────────────┐
@@ -121,9 +129,10 @@ see browser warnings.)
 
 Optional extra ports (only if you need them):
 - **4443** — alternate HTTPS listener (e.g. if 443 is taken by something else).
-- **636** (LDAPS) — only if a legacy app on another machine binds to LDAP
-  directly over the network. The proxy itself reaches LDAP over the internal
-  Docker network, so you do **not** need to expose 636 for the stack to work.
+- **636** (LDAPS) — for direct-LDAP clients on other machines (Linux hosts
+  via PAM/SSSD, LDAP-native apps). The proxy itself reaches LDAP over the
+  internal Docker network, so you do **not** need to expose 636 for the stack
+  to work.
   **Do not forward 636 to the public internet.** If you need LAN clients to bind
   LDAP, set `CFG_LDAPS_HOST=ldap.internal.example.com` (or `sso-manager` for
   same-host Docker clients) in `setup.env` and use an internal DNS record / cert
@@ -139,8 +148,8 @@ standalone (`docker-compose`) both work.
 ## Quickstart
 
 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your domain
 ./setup.sh            # first run: generates ./config/ from setup.env, builds + bootstraps + starts
 ```
@@ -177,11 +186,21 @@ operator-owned and `setup.env` is ignored.
    would 404. Idempotent; skips a host that already exists.
 6. Prints your first admin login + the public URLs.
 
-### Configuration — `./config/` (no `.env` files)
+### Configuration & secrets — OpenBao + `./config/`
 
-All config and secrets live in a bind-mounted `./config/` directory (gitignored),
-read by each app's `@simpleworkjs/conf` via the `CONF_SECRETS` env var, which
-the entrypoint points at the mounted file:
+Secrets live in **OpenBao** (a Vault fork, container `openbao:8200` on
+`theta-net`), the single authoritative store. Each app loads them at boot with
+[@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+deep-merges `secret/<app>/conf` over the file-loaded config — **fail-soft**, so
+if OpenBao is unreachable the app boots from the file fallback. End users get
+personal per-user secret storage (`secret/users/<uid>/*`) in the SSO **Vault**
+UI, and admins mint scoped tokens for external apps (`secret/apps/<name>/*`).
+See **[docs/secrets.md](docs/secrets.md)** for the full architecture, policies,
+token model, rotation, and the external-app convention.
+
+A bind-mounted `./config/` directory (gitignored) holds the operator-edit
+seed files and the fail-soft fallback, read by each app's `@simpleworkjs/conf`
+via the `CONF_SECRETS` env var:
 
 - **`./config/sso-secrets.js`** — SSO config: `ldap` (base, admin password,
   user/group bases), `oauth` (issuer, `jwtSecret`), `smtp`, `name`, plus
@@ -192,11 +211,15 @@ the entrypoint points at the mounted file:
   same `serviceAccountPass`), `auth` (admin groups/users).
 
 `./setup.sh` generates both on first run from `./setup.env` (the one place the
-domain is entered — see *Quickstart*) with random secrets. There is **no
-`.env` / `proxy.env`** — edit `./config/*.js` directly. Compose only interpolates
-port defaults (`SSO_PORT`, `HTTP_PORT`, etc.), which you can override on the
-command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See `config.example/` for the
-full annotated shape, and each submodule's `secrets.js.example`.
+domain is entered — see *Quickstart*) with random secrets, seeds them into
+OpenBao, and mints scoped per-app tokens (`SSO_VAULT_TOKEN` /
+`PROXY_VAULT_TOKEN` / `JUMP_VAULT_TOKEN`) into `./.env`. There is **no
+`.env` / `proxy.env`** for app config — edit `./config/*.js` directly (and
+re-seed into OpenBao, or use the SSO Configuration UI for live edits). Compose
+only interpolates port defaults (`SSO_PORT`, `HTTP_PORT`, etc.), which you can
+override on the command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See
+`config.example/` for the full annotated shape, and each submodule's
+`secrets.js.example`.
 
 > **Migrating from an older `.env`-based deployment?** If `.env` and/or
 > `proxy.env` exist when you first run `./setup.sh`, it migrates them into
@@ -215,9 +238,10 @@ full annotated shape, and each submodule's `secrets.js.example`.
 - **Proxy mgmt UI**: `https://<PROXY_HOST>` — add the Host records you want to
   protect with OIDC. (First-run fallback: `http://<host>:3000`, reachable on the
   LAN by default.)
-- **Direct LDAP for legacy apps**: bind to `ldaps://<host>:636` as
-  `cn=admin,<base>` (admin) or `cn=ldapclient,ou=people,<base>` (read-only
-  service account the bootstrap created). Use LDAPS, not plain LDAP.
+- **Direct LDAP for LDAP-native clients and Linux hosts**: bind to
+  `ldaps://<host>:636` as `cn=admin,<base>` (admin) or
+  `cn=ldapclient,ou=people,<base>` (read-only service account the bootstrap
+  created). Use LDAPS, not plain LDAP.
 
 ### API tokens (personal access tokens)
 
@@ -325,8 +349,11 @@ docker compose cp sso-manager:/data/dump.rdb sso-manager.rdb
 docker compose exec proxy redis-cli BGSAVE
 docker compose cp proxy:/data/dump.rdb proxy.rdb
 
-# Secrets
+# Secrets — ./config/ (the seed/fallback; OpenBao is authoritative)
 cp -a ./config config-backup && chmod 700 config-backup
+# OpenBao (the authoritative secret store — back up its data volume)
+docker run --rm -v theta-suite_openbao-data:/data -v "$PWD":/backup alpine \
+  tar czf /backup/openbao-data.tgz -C /data .
 ```
 
 ### Restore — full disaster recovery
@@ -377,9 +404,15 @@ Redis and are preserved by the volume.
 
 ---
 
-## Running each project standalone
+## Running a component individually
 
-The two submodules work on their own — this repo just composes them:
+> The integrated stack (`./setup.sh`) is the supported path. The per-project
+> commands below are for the advanced case of running one component on its own
+> (separate host, no orchestrator) — you then manage secrets from the
+> `config/*-secrets.js` file only (no shared OpenBao) and do the OIDC/LDAP wiring
+> by hand. See [docs/standalone.md](docs/standalone.md).
+
+Each submodule builds and runs on its own:
 
 - **SSO Manager alone**:
   ```bash
@@ -465,7 +498,7 @@ exactly in the bootstrap) so the SSO can verify them on bind.
 ## Repo layout
 
 ```
-theta-env/
+theta-suite/
 ├── setup.env.example   # first-run config template — cp to setup.env, set CFG_DOMAIN
 ├── config.example/      # committed annotated config templates (copy to ./config/)
 ├── docker-compose.yml   # sso-manager + proxy on one bridge net
@@ -486,7 +519,7 @@ tagged release of each app, not whatever's most recently merged upstream. To
 lock to the pinned commits (offline rebuild, or a deliberate pin), run
 `SKIP_SUBMODULE_UPDATE=1 ./setup.sh`.
 
-See [CHANGELOG.md](CHANGELOG.md) for what changed in each theta-env release
+See [CHANGELOG.md](CHANGELOG.md) for what changed in each theta-suite release
 (and each submodule's own `CHANGELOG.md` —
 [proxy](https://github.com/theta42/proxy/blob/master/CHANGELOG.md),
 [sso-manager-node](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md)

bootstrap/bootstrap.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 /*
- * theta-env bootstrap — runs inside the sso-manager container to wire the
+ * theta-suite bootstrap — runs inside the sso-manager container to wire the
  * proxy into a (fresh or existing) SSO Manager. Invoked by setup.sh:
  *
  *   docker compose exec sso-manager node /bootstrap/bootstrap.js
@@ -23,6 +23,13 @@
  *                               into the file (the sso-manager mounts ./config
  *                               read-write for this purpose).
  *
+ * Generated creds are ALSO written into OpenBao (secret/proxy/conf and, when
+ * the jump host is enabled, secret/jump-host/conf) so the proxy + jump host
+ * load them from OpenBao at boot via @simpleworkjs/bao-conf. setup.sh passes
+ * the root VAULT_TOKEN on this exec for that purpose. The OpenBao write is
+ * fail-soft: if VAULT_TOKEN is unset or OpenBao is unreachable, the /config
+ * file remains the fallback and bootstrap does not fail the bring-up over it.
+ *
  * Idempotent: re-running converges to the ./config values. The LDAP service
  * account + admin passwords are reset to the file values on each run; the
  * OAuth client is created if missing. If proxy-secrets.js already holds a
@@ -87,6 +94,44 @@ const ADMIN_GROUPS = ['app_sso_admin', 'app_sso_oauth_admin'];
 const log  = (...a) => process.stderr.write('[bootstrap] ' + a.join(' ') + '\n');
 const out  = (k, v) => process.stdout.write(`${k}=${v}\n`);
 
+// ── OpenBao (Vault) writes ───────────────────────────────────────────────────
+// bootstrap generates the proxy's + jump host's OAuth client creds and writes
+// them back into /config/*-secrets.js (the file fallback). It ALSO writes the
+// complete conf into OpenBao so the proxy + jump host load it from there at
+// boot via @simpleworkjs/bao-conf. setup.sh passes the root VAULT_TOKEN on this
+// exec. Fail-soft: if VAULT_TOKEN is unset or OpenBao is unreachable, the write
+// is skipped with a warning — the file remains the fallback and bootstrap does
+// not fail the bring-up over it.
+const VAULT_ADDR  = process.env.VAULT_ADDR || 'http://openbao:8200';
+const VAULT_TOKEN = process.env.VAULT_TOKEN || '';
+
+// Re-require a /config module after its file has been rewritten on disk
+// (require caches the old contents otherwise).
+function freshRequire(p) {
+	delete require.cache[require.resolve(p)];
+	return require(p);
+}
+
+// PUT (replace) the data at secret/data/<vaultPath> with `data`. Warn-only.
+async function baoPut(vaultPath, data) {
+	if (!VAULT_TOKEN) { log('OpenBao: VAULT_TOKEN unset — skipping write of secret/' + vaultPath); return; }
+	try {
+		const res = await fetch(`${VAULT_ADDR}/v1/secret/data/${vaultPath}`, {
+			method: 'POST',
+			headers: { 'X-Vault-Token': VAULT_TOKEN, 'Content-Type': 'application/json' },
+			body: JSON.stringify({ data }),
+		});
+		if (!res.ok) {
+			const text = await res.text().catch(() => '');
+			log(`WARNING: OpenBao write secret/${vaultPath} failed (${res.status}) ${text} — app will use its file fallback`);
+		} else {
+			log(`OpenBao: wrote secret/${vaultPath}`);
+		}
+	} catch (e) {
+		log(`WARNING: OpenBao write secret/${vaultPath} threw (${e.message}) — app will use its file fallback`);
+	}
+}
+
 // Replicate the SSO's hashPasswordSSHA512 (models/user_ldap.js) exactly so the
 // directory stores passwords the SSO can verify on bind (pw-sha2 module).
 function hashPasswordSSHA512(password) {
@@ -229,14 +274,15 @@ async function listClients(token) {
 	return (data && data.results) || [];
 }
 
-async function createClient(token) {
+async function createClient(token, opts) {
+	const o = opts || { name: CLIENT_NAME, description: 'theta-suite proxy (auto-registered)', redirect_uris: [REDIRECT_URI] };
 	const res = await fetch(`${SSO_INTERNAL}/api/oauth/client`, {
 		method: 'POST',
 		headers: { 'auth-token': token, 'Content-Type': 'application/json' },
 		body: JSON.stringify({
-			name: CLIENT_NAME,
-			description: 'theta-env proxy (auto-registered)',
-			redirect_uris: [REDIRECT_URI],
+			name: o.name,
+			description: o.description,
+			redirect_uris: o.redirect_uris,
 			scopes: ['openid', 'profile', 'email', 'groups'],
 			allowed_groups: [],
 		}),
@@ -249,7 +295,7 @@ async function createClient(token) {
 	const id = (data.results && data.results.client_id) || data.client_id;
 	const secret = data.client_secret;
 	if (!id || !secret) throw new Error(`create OAuth client returned no id/secret: ${JSON.stringify(data)}`);
-	log(`Created OAuth client ${CLIENT_NAME} (${id})`);
+	log(`Created OAuth client ${o.name} (${id})`);
 	return { id, secret };
 }
 
@@ -333,7 +379,7 @@ const HOST_FACTS = {
 	kernel: process.env.STACK_HOST_KERNEL || '',
 };
 
-async function seedDirectory(token, clientId) {
+async function seedDirectory(token, clientId, jumpClientId) {
 	let resources = ((await dirGet(token, 'resources')).results) || [];
 
 	// Create a resource unless its slug (or a legacy alternate from an earlier
@@ -418,10 +464,11 @@ async function seedDirectory(token, clientId) {
 		subType: 'openresty',
 	});
 
-	// Optional SSH jump host service.
-	if (/^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '')) {
+	// SSH jump host service (core component — always registered).
+	let jumpSvc = null;
+	{
 		const jumpHost = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
-		await ensure('service', 'SSH Jump Host', 'jump-host', host.id, {
+		jumpSvc = await ensure('service', 'SSH Jump Host', 'jump-host', host.id, {
 			address: jumpHost ? `https://${jumpHost}` : '',
 			port: 3002,
 			gitRepo: 'https://github.com/theta42/jump-host',
@@ -429,19 +476,21 @@ async function seedDirectory(token, clientId) {
 		});
 	}
 
-	// Link the proxy's OAuth client (Resource-backed since sso-manager 1.3.0)
-	// under its service, if it appears in the directory and isn't linked yet.
-	if (clientId) {
-		const oauthRes = resources.find((r) => r.id === clientId);
-		if (oauthRes) {
-			const edges = ((await dirGet(token, 'edges')).results) || [];
-			const linked = edges.some((e) => e.childId === clientId);
-			if (!linked) {
-				await dirPost(token, 'edges', { parentId: psvc.id, childId: clientId, relation: 'oauth' });
-				log(`  directory: linked OAuth client under 'proxy'`);
-			}
+	// Link an OAuth client (Resource-backed since sso-manager 1.3.0) under its
+	// owning service, if it appears in the directory and isn't linked yet.
+	async function linkOauthClient(id, parent, label) {
+		if (!id || !parent) return;
+		const oauthRes = resources.find((r) => r.id === id);
+		if (!oauthRes) return;
+		const edges = ((await dirGet(token, 'edges')).results) || [];
+		const linked = edges.some((e) => e.childId === id);
+		if (!linked) {
+			await dirPost(token, 'edges', { parentId: parent.id, childId: id, relation: 'oauth' });
+			log(`  directory: linked OAuth client under '${label}'`);
 		}
 	}
+	await linkOauthClient(clientId, psvc, 'proxy');
+	await linkOauthClient(jumpClientId, jumpSvc, 'jump-host');
 }
 
 // Write the OAuth client creds back into /config/proxy-secrets.js so the proxy
@@ -474,25 +523,27 @@ function writeProxyCreds(id, secret) {
 	}
 }
 
-// ── 6. Optional: provision the SSH jump host ────────────────────────────────
-// When CFG_JUMP_HOST_ENABLED=true, the jump host needs: a directory API token
-// (to resolve which hosts a user may reach), an LDAP bind account that can
-// WRITE the sshPublicKey attribute (it injects its own key on first use), and
-// a config file it reads. We write /config/jump-secrets.js deriving LDAP/site
-// from sso-secrets.js + a freshly minted API token. The bundled jump host
-// binds as cn=admin (already able to write sshPublicKey) — hardened bare-metal
-// deployments should use a scoped account + attribute ACL instead (see the
-// jump-host README). Idempotent: skips if the file already has a real token.
-const JUMP_ENABLED = /^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '');
+// ── 6. Provision the SSH jump host ─────────────────────────────────────────
+// The jump host is a core component (always provisioned). It needs: a directory
+// API token (to resolve which hosts a user may reach), an LDAP bind account
+// that can WRITE the sshPublicKey attribute (it injects its own key on first
+// use), and a config file it reads. We write /config/jump-secrets.js deriving
+// LDAP/site from sso-secrets.js + a freshly minted API token. The bundled jump
+// host binds as cn=admin (already able to write sshPublicKey) — hardened
+// bare-metal deployments should use a scoped account + attribute ACL instead
+// (see the jump-host README). Idempotent: skips if the file already has a real
+// token.
 const JUMP_HOST = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
 const JUMP_SECRETS = '/config/jump-secrets.js';
 const JUMP_TOKEN_NAME = 'theta-jump-host';
+const JUMP_CLIENT_NAME = 'theta-jump';
+const JUMP_REDIRECT_URI = `https://${JUMP_HOST}/api/auth/oidc/callback`;
 
 async function mintApiToken(token, name) {
 	const res = await fetch(`${SSO_INTERNAL}/api/api-token`, {
 		method: 'POST',
 		headers: { 'auth-token': token, 'Content-Type': 'application/json' },
-		body: JSON.stringify({ name, description: 'theta-env jump host (auto-registered)' }),
+		body: JSON.stringify({ name, description: 'theta-suite jump host (auto-registered)' }),
 	});
 	if (!res.ok) throw new Error(`mint API token failed (${res.status}): ${await res.text().catch(() => '')}`);
 	const data = await res.json();
@@ -501,25 +552,39 @@ async function mintApiToken(token, name) {
 	return raw;
 }
 
-function jumpFileHasToken() {
+// The generated file is "complete" only if it has BOTH a real directory API
+// token AND an OIDC client id — an existing file from the pre-OIDC layout (a
+// token but no oidc block) is regenerated so the web UI's SSO login works.
+function jumpFileComplete() {
 	try {
 		const src = fs.readFileSync(JUMP_SECRETS, 'utf8');
-		return /apiToken:\s*['"]sso_[0-9a-f]{24}_[0-9a-f]{48}['"]/.test(src);
+		const hasToken = /apiToken:\s*['"]sso_[0-9a-f]{24}_[0-9a-f]{48}['"]/.test(src);
+		const hasOidc = /clientId:\s*['"][0-9a-f-]{8,}['"]/.test(src);
+		return hasToken && hasOidc;
 	} catch (_) { return false; }
 }
 
-function writeJumpSecrets(apiToken) {
+function writeJumpSecrets(apiToken, oidc, localAdminPass) {
 	const siteName = (sso.stack && sso.stack.siteName) || 'local';
 	const ldapsHost = (sso.ldap && sso.ldap.ldapsHost) || SSO_HOST;
 	const body = `'use strict';
-// Generated by theta-env bootstrap. The jump host reads this via
+// Generated by theta-suite bootstrap. The jump host reads this via
 // @simpleworkjs/conf (CONF_SECRETS). Binds as cn=admin so it can write the
 // sshPublicKey attribute (key injection); for a hardened deployment use a
 // scoped account with an sshPublicKey write-ACL instead (see jump-host README).
 module.exports = {
 \tname: ${JSON.stringify(sso.name || 'SSO Manager')},
 \tldap: {
-\t\turl: 'ldap://sso-manager:389',
+\t\t// ldaps:// (636), not ldap:// (389): @simpleworkjs/ldap's client always
+\t\t// sets tlsOptions (see jump-host's models/user_ldap.js), and ldapts
+\t\t// treats a non-empty tlsOptions as "use implicit TLS" regardless of the
+\t\t// URL scheme -- pointed at the plain port, that means it opens a raw TLS
+\t\t// handshake against a server expecting plaintext LDAP, which slapd just
+\t\t// drops (logged as "connection lost", no BIND ever attempted). This bit
+\t\t// jump-host silently: every SSH login failed with the generic
+\t\t// "Permission denied" for any password, because getUser()/checkPassword()
+\t\t// never even reached slapd.
+\t\turl: 'ldaps://sso-manager:636',
 \t\tbindDN: ${JSON.stringify(BIND_DN)},
 \t\tbindPassword: ${JSON.stringify(ADMIN_PASS)},
 \t\tuserBase: ${JSON.stringify(`ou=people,${BASE_DN}`)},
@@ -537,7 +602,27 @@ module.exports = {
 \t\tkeyComment: ${JSON.stringify(`jump-host@${siteName}`)},
 \t},
 \tweb: { port: 3002 },
-\tauth: { adminGroups: ['app_sso_admin'] },
+\t// Web UI SSO login — the jump host's own OAuth client. tokenEndpoint /
+\t// userinfoEndpoint use the internal docker-net address (server-to-server);
+\t// authorizationEndpoint is the public SSO host (browser-facing).
+\toidc: {
+\t\tenabled: true,
+\t\tissuer: ${JSON.stringify(`https://${SSO_HOST}`)},
+\t\tauthorizationEndpoint: ${JSON.stringify(`https://${SSO_HOST}/oauth/authorize`)},
+\t\ttokenEndpoint: 'http://sso-manager:3001/oauth/token',
+\t\tuserinfoEndpoint: 'http://sso-manager:3001/oauth/userinfo',
+\t\tclientId: ${JSON.stringify(oidc.id)},
+\t\tclientSecret: ${JSON.stringify(oidc.secret)},
+\t\tredirectUri: ${JSON.stringify(JUMP_REDIRECT_URI)},
+\t\tscopes: ['openid', 'profile', 'email', 'groups'],
+\t\tgroupsClaim: 'groups',
+\t\tusernameClaim: 'preferred_username',
+\t},
+\tauth: {
+\t\tadminGroups: ['app_sso_admin'],
+\t\tadminUsers: ['jumpadmin'],
+\t\tlocalAdminPass: ${JSON.stringify(localAdminPass)},
+\t},
 \tredis: { prefix: 'jump_host_', redisConf: { url: 'redis://127.0.0.1:6379' } },
 \tstack: { ssoHost: ${JSON.stringify(SSO_HOST)}, jumpHost: ${JSON.stringify(JUMP_HOST)}, ldapsHost: ${JSON.stringify(ldapsHost)} },
 };
@@ -545,14 +630,39 @@ module.exports = {
 	fs.writeFileSync(JUMP_SECRETS, body, { mode: 0o600 });
 }
 
+// Returns the jump host's OAuth client id (so seedDirectory can link it under
+// the SSH Jump Host service), whether or not this run actually wrote a fresh
+// jump-secrets.js -- otherwise re-runs on an already-configured deployment
+// never get a chance to self-heal a missing directory link (see the "no
+// parent" bug this was written for).
 async function provisionJumpHost(token) {
-	if (jumpFileHasToken()) {
-		log('Jump host: /config/jump-secrets.js already has an API token — keeping.');
-		return;
+	if (jumpFileComplete()) {
+		log('Jump host: /config/jump-secrets.js already has API token + OIDC client — keeping.');
+		const clients = await listClients(token);
+		const existing = clients.find((c) => c.name === JUMP_CLIENT_NAME);
+		return existing ? existing.client_id : null;
 	}
 	const apiToken = await mintApiToken(token, JUMP_TOKEN_NAME);
-	writeJumpSecrets(apiToken);
-	log('Jump host: wrote /config/jump-secrets.js (minted directory API token).');
+
+	// Mint (or reuse) the jump host's own OAuth client for web-UI SSO login.
+	const clients = await listClients(token);
+	let oidc = clients.find((c) => c.name === JUMP_CLIENT_NAME);
+	if (oidc && oidc.client_id) {
+		oidc = await rotateClient(token, oidc.client_id);
+		oidc = { id: oidc.id, secret: oidc.secret };
+	} else {
+		oidc = await createClient(token, {
+			name: JUMP_CLIENT_NAME,
+			description: 'theta-suite jump host web UI (auto-registered)',
+			redirect_uris: [JUMP_REDIRECT_URI],
+		});
+	}
+
+	const localAdminPass = crypto.randomBytes(16).toString('hex');
+	writeJumpSecrets(apiToken, oidc, localAdminPass);
+	log(`Jump host: wrote /config/jump-secrets.js (API token + OAuth client ${oidc.id}).`);
+	log(`Jump host: local admin 'jumpadmin' password: ${localAdminPass}`);
+	return oidc.id;
 }
 
 (async function main() {
@@ -598,22 +708,37 @@ async function provisionJumpHost(token) {
 			resolvedClientId = id;
 		}
 
-		// Provision the jump host (mint token + write config) when enabled.
-		// Warn-only — never fail the whole bring-up over the optional service.
-		if (JUMP_ENABLED) {
-			try {
-				await provisionJumpHost(token);
-				out('JUMP_HOST_CONFIGURED', '1');
-			} catch (e) {
-				log(`WARNING: jump host provisioning failed (${e.message || e}) — continuing`);
-			}
+		// Mirror the (now-current) proxy-secrets.js into OpenBao so the proxy
+		// loads it from there at boot via @simpleworkjs/bao-conf. Re-require
+		// fresh: writeProxyCreds rewrote the file out from under the cached
+		// `proxy` object. setup.sh's seed already put a placeholder version
+		// here; this replaces it with the complete file (operator edits +
+		// generated OAuth creds). Warn-only.
+		await baoPut('proxy/conf', freshRequire('/config/proxy-secrets.js'));
+
+		// Provision the jump host (mint token + write config). Warn-only — never
+		// fail the whole bring-up over it, but it's a core component so always
+		// attempted (no longer gated by CFG_JUMP_HOST_ENABLED).
+		let jumpClientId = null;
+		try {
+			jumpClientId = await provisionJumpHost(token);
+			out('JUMP_HOST_CONFIGURED', '1');
+			// Mirror jump-secrets.js (just written by provisionJumpHost) into
+			// OpenBao so the jump host loads it from there at boot via
+			// @simpleworkjs/bao-conf. setup.sh's seed may have put a
+			// placeholder/stale version here; this replaces it with the
+			// complete file (LDAP bind, minted API token, OAuth client).
+			// Warn-only.
+			await baoPut('jump-host/conf', freshRequire(JUMP_SECRETS));
+		} catch (e) {
+			log(`WARNING: jump host provisioning failed (${e.message || e}) — continuing`);
 		}
 
 		// Seed the directory (site/host/services + OAuth client link). Never
 		// fails the bootstrap — warn and continue.
 		try {
 			log('Seeding directory resources...');
-			await seedDirectory(token, resolvedClientId);
+			await seedDirectory(token, resolvedClientId, jumpClientId);
 		} catch (e) {
 			log(`WARNING: directory seed failed (${e.message || e}) — continuing`);
 		}

config.example/ldap-test-host.vars.example

@@ -0,0 +1,26 @@
+# ldap-client config for the optional local jump-host test fixture
+# (ldap-test-host service in docker-compose.yml, jump-host compose profile).
+# Copy to ./config/ldap-test-host.vars and fill in the bind password from
+# your own ./config/sso-secrets.js's `serviceAccountPass` (the
+# cn=ldapclient,ou=people,<base> service account bootstrap/bootstrap.js
+# creates specifically for this kind of 3rd-party/container LDAP bind).
+#
+# This is what lets ldap-test-host be a REAL SSSD+AuthorizedKeysCommand-joined
+# downstream host, so jump-host's key-injection -> upstream-connect flow can
+# be exercised end-to-end against something more than a container with a
+# manually-dropped public key in authorized_keys.
+export ldap_host="sso-manager"
+export ldap_base_dn="dc=localtest,dc=me"
+
+export ldap_bind_dn="cn=ldapclient,ou=People,$ldap_base_dn"
+export ldap_bind_password="REPLACE_WITH_serviceAccountPass_FROM_sso-secrets.js"
+
+# sso_url/sso_token deliberately left unset -- register the host + access
+# group manually via the Directory admin API instead (index.sh's optional
+# auto-registration also wants a parent site Resource to exist first).
+# index.sh gates that block on `[[ -v sso_token ]]`, which is true even for
+# an empty string, so leave these genuinely absent, not "".
+
+export ldap_location="jumptest"
+
+ldap_access_groups=( "${ldap_location}_access" "${ldap_location}_host_$(hostname)_access" )

config.example/proxy-secrets.js.example

@@ -1,5 +1,5 @@
 'use strict';
-// Example proxy secrets for the theta-env unified stack. Copy to
+// Example proxy secrets for the theta-suite unified stack. Copy to
 // ./config/proxy-secrets.js (NOT this file — ./config/ is gitignored) and edit.
 // `./setup.sh` generates ./config/proxy-secrets.js for you on first run and the
 // bootstrap writes the OAuth client clientId/clientSecret back into it; this

config.example/sso-secrets.js.example

@@ -1,5 +1,5 @@
 'use strict';
-// Example SSO secrets for the theta-env unified stack. Copy to
+// Example SSO secrets for the theta-suite unified stack. Copy to
 // ./config/sso-secrets.js (NOT this file — ./config/ is gitignored) and edit.
 // `./setup.sh` generates ./config/sso-secrets.js for you on first run; this file
 // documents the shape for manual editing / reference.
@@ -30,6 +30,16 @@ module.exports = {
 		jwtSecret: 'CHANGE-ME',                 // signs all tokens — keep secret
 		token_lifetime: { access_token: 3600, refresh_token: 2592000 },
 	},
+	// Without this, @simpleworkjs/orm falls back to './config/inventory.sqlite'
+	// (relative to the app's /app cwd) -- inside the container's ephemeral
+	// layer, not any mounted volume, so every Resource/site/host/service/oauth
+	// row (the whole Directory Management page) would be silently wiped on
+	// every container recreate. /data is already a persisted volume (Redis
+	// lives there too), so this just co-locates the sqlite file with it.
+	orm: {
+		dialect: 'sqlite',
+		storage: '/data/inventory.sqlite',
+	},
 
 	// ── Orchestrator-only (ignored by the app; read by setup.sh + bootstrap) ──
 	stack: {

docker-compose.yml

@@ -1,4 +1,4 @@
-# theta-env — unified SSO Manager + Proxy.
+# theta-suite — unified SSO Manager + Proxy.
 #
 # Brings up the two all-in-one images on one bridge network so the proxy can
 # reach the SSO internally (http://sso-manager:3001 for token/userinfo,
@@ -36,8 +36,16 @@ services:
         # setup.sh sets this from the host, where the submodule resolves
         # correctly (git -C sso-manager-node rev-parse --short HEAD).
         GIT_COMMIT: ${SSO_GIT_COMMIT:-}
+        # Optional upstream HTTP(S) proxy for npm/apt during the build (NOT
+        # the theta42 "proxy" app). Set CFG_HTTP_PROXY in setup.env; empty by
+        # default, so this is a no-op unless configured.
+        HTTP_PROXY: ${CFG_HTTP_PROXY:-}
+        HTTPS_PROXY: ${CFG_HTTPS_PROXY:-}
+        NO_PROXY: ${CFG_NO_PROXY:-}
     container_name: sso-manager
     restart: unless-stopped
+    depends_on:
+      - openbao
     networks: [theta-net]
     ports:
       # SSO web UI. Bind address is configurable via SSO_BIND (default 0.0.0.0 so
@@ -51,13 +59,23 @@ services:
       - "${LDAPS_PORT:-636}:636"
       # Plain LDAP (389) is NOT mapped — direct-LDAP clients should use LDAPS.
     environment:
-      # Config (LDAP, OAuth, SMTP, ...) comes from ./config/sso-secrets.js (see
-      # volumes below), not from env. NODE_ENV/NODE_PORT are the only env the app
-      # reads that are not part of its conf tree.
+      # Config (LDAP, OAuth, SMTP, ...) is loaded by @simpleworkjs/conf from
+      # ./config/sso-secrets.js (see volumes), then @simpleworkjs/bao-conf
+      # deep-merges secret/sso-manager/conf from OpenBao over it at boot
+      # (VAULT_ADDR/VAULT_TOKEN below). NODE_ENV/NODE_PORT are the only other
+      # env the app reads. VAULT_TOKEN is the scoped SSO_VAULT_TOKEN minted by
+      # setup.sh (policy sso-broker) — NOT the root token.
       - NODE_ENV=production
       - NODE_PORT=3001
       - LDAP_SERVER_ID=${LDAP_SERVER_ID:-}
       - LDAP_REPLICATION_HOSTS=${LDAP_REPLICATION_HOSTS:-}
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${SSO_VAULT_TOKEN:-}
+      # Optional upstream HTTP(S) proxy for outbound calls (SMTP, etc.) at
+      # runtime. See the build args above for the same setting during build.
+      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
+      - HTTPS_PROXY=${CFG_HTTPS_PROXY:-}
+      - NO_PROXY=${CFG_NO_PROXY:-}
     volumes:
       # Operator-edited SSO secrets (sso-secrets.js). Read-WRITE so the bootstrap
       # can write the generated OAuth client creds into proxy-secrets.js. The
@@ -91,12 +109,19 @@ services:
         # setup.sh sets this from the host, where the submodule resolves
         # correctly (git -C proxy rev-parse --short HEAD).
         GIT_COMMIT: ${PROXY_GIT_COMMIT:-}
+        # Optional upstream HTTP(S) proxy for npm/apt during the build. See
+        # the sso-manager service above for details.
+        HTTP_PROXY: ${CFG_HTTP_PROXY:-}
+        HTTPS_PROXY: ${CFG_HTTPS_PROXY:-}
+        NO_PROXY: ${CFG_NO_PROXY:-}
     container_name: proxy
     restart: unless-stopped
     networks: [theta-net]
     depends_on:
       sso-manager:
         condition: service_healthy
+      openbao:
+        condition: service_started
     ports:
       - "${HTTP_PORT:-80}:80"
       - "${HTTPS_PORT:-443}:443"
@@ -106,14 +131,28 @@ services:
       # to lock it to localhost once the proxy fronts it under TLS.
       - "${MGMT_BIND:-0.0.0.0}:${MGMT_PORT:-3000}:3000"
     environment:
-      # oidc/ldap/auth config comes from ./config/proxy-secrets.js (see volumes),
-      # not from env. NODE_ENV/NODE_PORT are process env the app reads directly.
+      # oidc/ldap/auth config is loaded by @simpleworkjs/conf from
+      # ./config/proxy-secrets.js (see volumes), then @simpleworkjs/bao-conf
+      # deep-merges secret/proxy/conf from OpenBao over it at boot. The OAuth
+      # clientSecret is consumed at require time, so bao-conf.init() runs
+      # BEFORE require('../app') in bin/www. NODE_ENV/NODE_PORT are process env
+      # the app reads directly. VAULT_TOKEN is the scoped PROXY_VAULT_TOKEN
+      # (policy proxy — read only secret/proxy/conf).
       - NODE_ENV=production
       - NODE_PORT=3000
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${PROXY_VAULT_TOKEN:-}
+      # Optional upstream HTTP(S) proxy for outbound calls (ACME/Let's
+      # Encrypt, DNS providers) at runtime.
+      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
+      - HTTPS_PROXY=${CFG_HTTPS_PROXY:-}
+      - NO_PROXY=${CFG_NO_PROXY:-}
     volumes:
       # Operator-edited proxy secrets (proxy-secrets.js). READ-ONLY — the proxy
       # only reads it; the sso-manager bootstrap writes the OAuth creds. The
-      # entrypoint points CONF_SECRETS at /config/proxy-secrets.js.
+      # entrypoint points CONF_SECRETS at /config/proxy-secrets.js. Kept as a
+      # fail-soft fallback: bao-conf.init() is fail-soft, so if OpenBao is
+      # unreachable the app boots from this file instead.
       - ./config:/config:ro
       # Persist Redis (AOF + RDB) so Host records, permissions, DNS creds, local
       # users, AND the auto-ssl Let's Encrypt certs survive container recreation.
@@ -131,32 +170,90 @@ services:
       retries: 3
       start_period: 30s
 
-  # Optional SSH jump host. Only started when the `jump-host` compose profile
-  # is active — setup.sh exports COMPOSE_PROFILES=jump-host when
-  # CFG_JUMP_HOST_ENABLED=true. Authenticates users against the SSO's OpenLDAP,
-  # resolves reachable hosts from the directory API, and bridges SSH through.
+  # SSH jump host — a core component, always built + started alongside the
+  # SSO and proxy. Authenticates users against the SSO's OpenLDAP, resolves
+  # reachable hosts from the directory API, and bridges SSH through.
   jump-host:
-    profiles: ["jump-host"]
     build:
       context: ./jump-host
       dockerfile: Dockerfile
       args:
         GIT_COMMIT: ${JUMP_GIT_COMMIT:-}
+        # Optional upstream HTTP(S) proxy for npm/apt during the build. See
+        # the sso-manager service above for details.
+        HTTP_PROXY: ${CFG_HTTP_PROXY:-}
+        HTTPS_PROXY: ${CFG_HTTPS_PROXY:-}
+        NO_PROXY: ${CFG_NO_PROXY:-}
     container_name: jump-host
     restart: unless-stopped
     networks: [theta-net]
     depends_on:
       sso-manager:
         condition: service_healthy
+      openbao:
+        condition: service_started
     ports:
       - "${JUMP_SSH_PORT:-2222}:2222"   # SSH front door
       - "${JUMP_WEB_BIND:-0.0.0.0}:${JUMP_WEB_PORT:-3002}:3002"  # web UI/API
     environment:
       - NODE_ENV=production
+      # Secrets are loaded by @simpleworkjs/conf from ./config/jump-secrets.js,
+      # then @simpleworkjs/bao-conf deep-merges secret/jump-host/conf from
+      # OpenBao over it at boot. VAULT_TOKEN is the scoped JUMP_VAULT_TOKEN
+      # (policy jump-host — read only secret/jump-host/conf).
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${JUMP_VAULT_TOKEN:-}
+      # Optional upstream HTTP(S) proxy for outbound calls (the directory API
+      # client) at runtime.
+      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
+      - HTTPS_PROXY=${CFG_HTTPS_PROXY:-}
+      - NO_PROXY=${CFG_NO_PROXY:-}
     volumes:
       - ./config:/config:ro         # jump-secrets.js (written by ensure_config/bootstrap)
       - jump-data:/var/lib/jump-host  # generated host keys persist here
+      - jump-redis-data:/data         # Redis (sessions, OAuth state, API tokens) persists here
 
+  # A real, LDAP-joined (SSSD + AuthorizedKeysCommand) downstream host for
+  # testing jump-host's actual key-injection -> upstream-connect flow --
+  # a container with a manually-dropped public key in authorized_keys never
+  # exercises the LDAP-key-serving path a real production host does. Built
+  # from the theta42/ldap-client submodule -- see ./config/ldap-test-host.vars
+  # for setup notes. Opt-in test fixture: bring it up explicitly with
+  # `docker compose --profile ldap-test up` (jump-host itself now starts
+  # unconditionally, so this only adds a downstream host for it to reach).
+  ldap-test-host:
+    profiles: ["ldap-test"]
+    build:
+      context: ./ldap-client
+      dockerfile: Dockerfile
+    container_name: ldap-test-host
+    hostname: ldap-test-host
+    restart: unless-stopped
+    networks: [theta-net]
+    depends_on:
+      sso-manager:
+        condition: service_healthy
+    privileged: false
+    volumes:
+      - ./config/ldap-test-host.vars:/config/ldap.vars:ro
+      - ./config/ldap-ca.crt:/config/ldap-ca.crt:ro
+
+  openbao:
+    image: quay.io/openbao/openbao:latest
+    container_name: openbao
+    restart: unless-stopped
+    cap_add:
+      - IPC_LOCK
+    command: server -config=/vault/config/openbao.hcl
+    environment:
+      - BAO_ADDR=http://127.0.0.1:8200
+    ports:
+      - "8080:8200"
+    volumes:
+      - ./config/openbao.hcl:/vault/config/openbao.hcl:ro
+      - openbao-data:/vault/data
+    networks:
+      - theta-net
 networks:
   theta-net:
     driver: bridge
@@ -168,4 +265,6 @@ volumes:
   proxy-data:
   proxy-cache:
   proxy-logs:
-  jump-data:
+  jump-data:
+  jump-redis-data:
+  openbao-data:

docs/_config.yml

@@ -1,7 +1,7 @@
-title: theta-env
+title: theta-suite
 description: A unified, one-command SSO Manager + OIDC proxy stack for home labs and small businesses.
 url: "https://theta42.github.io"
-baseurl: "/theta-env"
+baseurl: "/theta-suite"
 logo: /assets/img/theta42.svg
 lang: en_US
 
@@ -10,10 +10,10 @@ plugins:
   - jekyll-sitemap
 
 github:
-  repository_url: https://github.com/theta42/theta-env
-  zip_url: https://github.com/theta42/theta-env/archive/refs/heads/master.zip
-  tar_url: https://github.com/theta42/theta-env/archive/refs/heads/master.tar.gz
-  repository_name: theta42/theta-env
+  repository_url: https://github.com/theta42/theta-suite
+  zip_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.zip
+  tar_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.tar.gz
+  repository_name: theta42/theta-suite
 
 nav:
   - title: Home
@@ -25,11 +25,14 @@ nav:
   - title: Architecture
     page: /architecture.html
     icon: fa-sitemap
+  - title: Secrets
+    page: /secrets.html
+    icon: fa-key
   - title: Standalone
     page: /standalone.html
     icon: fa-puzzle-piece
   - title: Changelog
-    url: https://github.com/theta42/theta-env/blob/master/CHANGELOG.md
+    url: https://github.com/theta42/theta-suite/blob/master/CHANGELOG.md
     icon: fa-list
 
 defaults:

docs/architecture.md

@@ -1,77 +1,131 @@
 ---
 layout: default
 title: Architecture
-description: How theta-env composes the SSO Manager and proxy submodules — the OIDC/LDAP wiring setup.sh generates from one domain.
+description: How theta-suite composes the SSO Manager, proxy, jump host, and ldap-client around a shared OpenBao secrets store — the OIDC/LDAP/secrets wiring setup.sh generates from one domain.
 ---
 
 # Architecture
 
 [← Back to Home](index.html)
 
-theta-env is a **composition** repo: it builds the two existing projects from
-their git submodules and adds the glue that wires them together. It does not
-fork or patch them — both projects work unchanged on their own.
+theta-suite is a **composition** repo: it builds four applications from their
+git submodules and adds the glue that wires them together — plus a shared
+[OpenBao](https://openbao.org/) secrets store — on one Docker network. It
+does not fork or patch the components; it composes and configures them.
 
 ---
 
-## The three repos
+## Components
 
-| Repo | Role |
+| Repo / image | Role |
 |------|------|
 | [`theta42/sso-manager-node`](https://github.com/theta42/sso-manager-node) | OIDC provider + OpenLDAP directory + web UI. All-in-one image (`Dockerfile.openldap`). |
 | [`theta42/proxy`](https://github.com/theta42/proxy) | OIDC-protected reverse proxy (OpenResty + Node mgmt app + Redis). All-in-one image (`Dockerfile`). |
-| `theta42/theta-env` (this repo) | Composes the two on one Docker network + automates first-run wiring. |
+| [`theta42/jump-host`](https://github.com/theta42/jump-host) | Directory-driven SSH jump host (sshd + Node web UI). Image (`Dockerfile`). |
+| [`theta42/ldap-client`](https://github.com/theta42/ldap-client) | Enrolls real Linux hosts into the directory (SSSD + AuthorizedKeysCommand). Also the opt-in `ldap-test-host` fixture. |
+| `quay.io/openbao/openbao` | Central secrets store (Vault fork), KV-v2 at `secret/`. |
+| `theta42/theta-suite` (this repo) | Composes all of the above on one network + automates first-run wiring. |
 
-The two projects are pinned as **git submodules**. `git clone --recursive`
-fetches all three in one step; `git submodule update --remote` bumps them.
+The four applications are pinned as **git submodules**; OpenBao uses the
+upstream image. `git clone --recursive` fetches the submodules in one step;
+`git submodule update --remote` bumps them.
 
 ---
 
-## The two containers
+## The stack
 
 ```
-            ┌──────────────────────────────────────────────┐
-            │  your browser / apps / legacy LDAP clients     │
-            └───────────────┬──────────────────────────────┘
-                            │ https (:443)        ldaps (:636)
-                  ┌─────────▼─────────┐
-                  │  proxy container  │  OpenResty :80/:443/:4443
-                  │  (OIDC + LDAP)    │  Node mgmt app :3000 (localhost only)
-                  │                   │  bundled Redis (127.0.0.1:6379)
-                  └─────────┬─────────┘
-              ┌─────────────┼────────────────────────────┐
-              │ ldaps:636   │ http:3001 (internal)       │  OIDC token + userinfo
-              │ (docker net)│ (docker net, not published)│  (server-to-server)
-              ▼             ▼                           │
-      ┌──────────────────────────────┐                   │
-      │  sso-manager container       │◄──────────────────┘
-      │  OIDC provider (Express)     │  bundled Redis (127.0.0.1:6379)
-      │  OpenLDAP (slapd)            │  web UI :3001 (localhost only)
-      │  ldaps :636 (published)      │
-      └───────────────────────────────┘
-            ▲
-            │ ldaps :636 (published to host) — legacy apps bind directly
-            │
-      ┌──────────────────────────────┐
-      │  legacy apps (Gitea, Emby, …)│
-      └──────────────────────────────┘
+          ┌──────────────────────────────────────────────────────────┐
+          │ browser / OIDC apps │ SSH clients │ Linux hosts            │
+          │                     │             │ (PAM/SSSD, sudo, keys)  │
+          └────────┬────────────┴──────┬──────┴───────────┬───────────┘
+            https (:443)          ssh (:2222)        ldaps (:636)
+                  │                     │                  │
+         ┌────────▼────────┐  ┌──────────▼────────┐         │
+         │  proxy           │  │  jump-host        │         │
+         │  OpenResty       │  │  sshd :2222       │         │
+         │  :80/:443/:4443  │  │  web UI :3002     │         │
+         │  mgmt app :3000  │  └────────┬──────────┘         │
+         └────────┬─────────┘           │ OIDC + LDAP        │
+                  │ http:3001 (internal)│ via sso-manager    │
+                  ▼                     ▼                    ▼
+        ┌───────────────────────────────────────────────────────┐
+        │  sso-manager   (Express + OpenLDAP + Redis)            │
+        │  OIDC provider + LDAP directory                         │
+        │  web UI :3001 (internal)   ldaps :636 (published)       │
+        └───────────────────────────────────────────────────────┘
+                          ▲  loads secrets at boot (scoped token each)
+              ┌───────────┴───────────────────┐
+              │  openbao   (KV-v2 at secret/)  │  ← central secrets store
+              │  :8200 (internal)             │     per-user + per-app KV
+              │  :8080 (operator UI/API)     │
+              └───────────────────────────────┘
+
+   ldap-client — enrolls real Linux hosts into the directory above
+                 (PAM/SSSD login, sudo, SSH-key serving); also the
+                 `ldap-test-host` fixture (opt-in: `--profile ldap-test`).
 ```
 
-Both containers bundle their **own Redis** (the proxy hardcodes `127.0.0.1:6379`
-in three places that ignore config; the SSO's models default to the same). Two
-redis instances is the no-source-patch path and is fine at this scale.
+All four services bundle their **own Redis** (sso-manager, proxy, jump-host
+each run a 127.0.0.1:6379 instance) and share the `openbao` secrets store.
+Direct LDAP binds against `:636` are first-class — that's how Linux hosts do
+PAM/SSSD login, sudo, and SSH-key serving, and how LDAP-native apps
+authenticate — not a fallback path.
 
 ### What's exposed, what's not
 
-| Port | On host? | Purpose |
-|------|----------|---------|
-| `443` (proxy) | **yes** | the public entry point — OIDC login + proxied apps + the SSO/proxy UIs |
-| `80` (proxy) | **yes** | HTTP-01 for Let's Encrypt (and redirect to 443) |
-| `4443` (proxy) | yes (optional) | alt HTTPS listener |
-| `3000` (proxy) | localhost only | proxy mgmt UI/API (first-run convenience; fronted by 443 normally) |
-| `636` (sso) | yes | LDAPS for legacy direct-LDAP clients |
-| `3001` (sso) | localhost only | SSO web UI (first-run convenience; fronted by the proxy normally) |
-| `389` (sso) | **no** | plain LDAP — internal only (app↔slapd over localhost) |
+| Port | Service | On host? | Purpose |
+|------|---------|----------|---------|
+| `443` | proxy | **yes** | public entry point — OIDC login + proxied apps + the SSO/proxy UIs |
+| `80` | proxy | **yes** | HTTP-01 for Let's Encrypt (and redirect to 443) |
+| `4443` | proxy | yes (optional) | alt HTTPS listener |
+| `3000` | proxy | localhost/LAN | proxy mgmt UI/API (fronted by 443 normally) |
+| `3001` | sso-manager | localhost/LAN | SSO web UI (fronted by the proxy normally) |
+| `636` | sso-manager | **yes** | LDAPS for direct-LDAP clients (Linux hosts, LDAP-native apps) |
+| `389` | sso-manager | **no** | plain LDAP — internal only (app↔slapd over localhost) |
+| `2222` | jump-host | **yes** | SSH front door |
+| `3002` | jump-host | **yes** | jump-host web UI/API |
+| `8080` | openbao | yes | OpenBao UI/API for the operator (apps use `openbao:8200` internally) |
+
+---
+
+## Secrets (OpenBao)
+
+Every component loads its secrets from one OpenBao instance at boot, not
+from scattered config files. OpenBao runs as the `openbao` container
+(`http://openbao:8200` on theta-net, KV-v2 at `secret/`); each app gets a
+**scoped token** (never the root token) whose OpenBao policy confines it to
+the paths it needs:
+
+| Service | env var | Policy | Access |
+|---------|---------|--------|--------|
+| sso-manager | `SSO_VAULT_TOKEN` | `sso-broker` | `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`; also mints per-user + per-app tokens |
+| proxy | `PROXY_VAULT_TOKEN` | `proxy` | `secret/proxy/conf` (read) |
+| jump-host | `JUMP_VAULT_TOKEN` | `jump-host` | `secret/jump-host/conf` (read) |
+
+At boot each app calls `@simpleworkjs/bao-conf`'s `init()`, which deep-merges
+its OpenBao path over the file-loaded `@simpleworkjs/conf` object — so OpenBao
+is authoritative at runtime, with the `./config/*-secrets.js` file kept only as
+an operator-edited seed and a fail-soft fallback (`init()` is fail-soft, so the
+app still boots from the file if OpenBao is unreachable). The proxy and
+jump-host consume `conf.oidc.clientSecret` at `require` time, so `init()`
+runs *before* their models load (see each app's `bin/www`).
+
+Beyond app config, OpenBao holds:
+
+- **Per-user secret storage** — `secret/users/<uid>/*`, browsed and edited in
+  the SSO UI's **My Secrets** page. Each user is confined to their own
+  namespace by a `user-<uid>` policy; admins see all of `secret/`.
+- **External-app tokens** — an admin mints a scoped `app-<name>` token
+  (confined to `secret/apps/<name>/*`) from the SSO UI's **Apps** tab, so an
+  external app can read its own secrets over the OpenBao HTTP API.
+
+`setup.sh` creates the policies + a `sso-broker` token role and mints the
+per-app tokens on first run; the root token stays in `setup.env` for
+seeding/maintenance only and is never passed to a service container. Full
+details — the policy model, the `secret/apps/<app>/conf` convention, `curl`
++ Node examples, and the operator rotation procedure — are in
+[Secrets](secrets.html).
 
 ---
 
@@ -82,7 +136,14 @@ actual work, running **inside the sso-manager container** (bind-mounted
 read-only from this repo). It's deliberately self-contained — only Node
 built-ins (`child_process`, `crypto`, `fs`) + global `fetch`, and it reads its
 inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets.js`
-(not from env):
+(not from env).
+
+OpenBao comes up first: `setup.sh` initializes and unseals it, writes the
+policies and the `sso-broker` token role, mints the per-app scoped tokens into
+`setup.env`, and idempotently seeds `secret/sso-manager/conf`,
+`secret/proxy/conf`, and `secret/jump-host/conf` from the corresponding
+`./config/*-secrets.js` files. The app containers then start with their scoped
+`VAULT_TOKEN`. The SSO/LDAP/OIDC wiring that follows:
 
 1. **Build + start sso-manager**, wait for `/health`.
 2. **LDAP service account** — `ldapadd` `cn=ldapclient,ou=people,<base>` (an
@@ -97,14 +158,16 @@ inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets
 5. **Register the proxy as an OIDC client** via `POST /api/oauth/client` (gated
    by `app_sso_oauth_admin`, satisfied by step 3). The SSO **generates** the
    `client_id`/`client_secret` (UUIDs) — supplied creds are ignored — so the
-   bootstrap writes the generated creds **back into `./config/proxy-secrets.js`**
-   (the sso-manager mounts `./config` read-write for this; the proxy mounts it
-   read-only). If `proxy-secrets.js` already holds a `clientId`+`clientSecret`
-   matching an existing client, they are kept; if the client exists but the file
-   has no usable secret, the secret is rotated and written back.
-6. **Build + start the proxy**, wait for `/health`. The proxy entrypoint points
-   `CONF_SECRETS` at `./config/proxy-secrets.js`, so `@simpleworkjs/conf`
-   (≥1.2.0) reads the OAuth creds + LDAP bind creds from the file.
+   bootstrap writes the generated creds **back into `./config/proxy-secrets.js`
+   and into OpenBao at `secret/proxy/conf`** (the sso-manager mounts `./config`
+   read-write for this; the proxy mounts it read-only). If `proxy-secrets.js`
+   already holds a `clientId`+`clientSecret` matching an existing client, they
+   are kept; if the client exists but the file has no usable secret, the
+   secret is rotated and written back.
+6. **Build + start the proxy + jump-host**, wait for `/health`. Each
+   entrypoint points `CONF_SECRETS` at its `./config/*-secrets.js`, then
+   `@simpleworkjs/bao-conf` overlays the OpenBao path over it (the OAuth
+   clientSecret + LDAP bind creds come from OpenBao at runtime).
 7. **Register `<SSO_HOST>` and `<PROXY_HOST>` as Host records in the proxy** —
    `setup.sh` runs a short script inside the proxy container that calls its
    Host model directly (`Host.create({host, ip, targetPort, ...})`), rather
@@ -120,20 +183,25 @@ inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets
 
 `setup.sh` then prints the first-admin login + the public URLs.
 
-### How config reaches the apps (no `.env`)
+### How config reaches the apps
 
-All config and secrets live in `./config/` (gitignored, bind-mounted). Each
-entrypoint points the `CONF_SECRETS` env var (`@simpleworkjs/conf` >= 1.2.0)
-at its file early, before the app starts:
+Config and secrets live in two layers: an operator-edited
+`./config/*-secrets.js` file (gitignored, bind-mounted) and the OpenBao
+overlay over it. Each entrypoint points the `CONF_SECRETS` env var
+(`@simpleworkjs/conf` >= 1.2.0) at its file early, before the app starts:
 
 ```
 CONF_SECRETS=/config/sso-secrets.js    (sso-manager, ./config RW)
 CONF_SECRETS=/config/proxy-secrets.js  (proxy, ./config RO)
+CONF_SECRETS=/config/jump-secrets.js   (jump-host, ./config RO)
 ```
 
 `@simpleworkjs/conf` loads `conf/base.js → <env>.js → secrets file → app_*
-env`, where **env beats the secrets file**. So compose passes **no `app_*` env
-vars** (only `NODE_ENV`, `NODE_PORT`) — that makes the secrets file
+env`, where **env beats the secrets file**. Then `@simpleworkjs/bao-conf`
+deep-merges the app's OpenBao path over the result at boot — OpenBao is the
+authoritative runtime layer; the file is the seed and fail-soft fallback. So
+compose passes **no `app_*` config env vars** (only `NODE_ENV`, `NODE_PORT`,
+`VAULT_ADDR`, and a scoped `VAULT_TOKEN`) — that keeps the secrets file + OpenBao
 authoritative. The SSO entrypoint reads the few values it needs at startup
 (LDAP base DN, admin password, JWT secret, cert CN) from `sso-secrets.js` via
 an in-container `node` call.
@@ -151,12 +219,15 @@ end-to-end.
 
 ## Idempotency
 
-Re-running `./setup.sh` converges to `./config/`:
+Re-running `./setup.sh` converges to `./config/` + OpenBao:
 
 - The LDAP service account + admin passwords are **reset to `./config/`**.
 - Group membership is ensured (add is a no-op if already a member).
 - The OAuth client is kept if `proxy-secrets.js` already holds its creds;
-  created or rotated otherwise, and the new creds written back.
+  created or rotated otherwise, and the new creds written back (to the file
+  and to OpenBao).
+- OpenBao policies, token role, per-app tokens, and `secret/<app>/conf` seeds
+  are ensured (created if absent, left alone if present).
 
 So `setup.sh` is safe to re-run after editing `./config/`, after a `docker
 compose down`, or after restoring from backup.
@@ -165,14 +236,18 @@ compose down`, or after restoring from backup.
 
 ## Backups and restore
 
-`./setup.sh` auto-snapshots `./config/` + LDAP + both Redis to
+`./setup.sh` auto-snapshots `./config/` + LDAP + all the Redis instances to
 `./backups/<timestamp>/` before each rebuild (keeps the last `BACKUP_KEEP`,
-default 5). State lives on named volumes (`ldap-data`, `sso-data`, `proxy-data`)
-and survives recreation; `down -v` wipes them. Redis is persisted with AOF +
-RDB on those volumes. For the full manual-backup + restore runbook (full /
-Redis-only / LDAP-only, with the AOF-vs-RDB note), see the *Backups and
-restore* section of the [README](https://github.com/theta42/theta-env#backups-and-restore).
-Quick LDAP backup:
+default 5). State lives on named volumes (`ldap-data`, `ldap-certs`,
+`sso-data`, `proxy-data`, `proxy-cache`, `proxy-logs`, `jump-data`,
+`jump-redis-data`, `openbao-data`) and survives recreation; `down -v` wipes
+them. Redis is persisted with AOF + RDB on those volumes. For the full
+manual-backup + restore runbook (full / Redis-only / LDAP-only, with the
+AOF-vs-RDB note), see the *Backups and restore* section of the
+[README](https://github.com/theta42/theta-suite#backups-and-restore). OpenBao
+holds the live secrets, so back up its volume too (`<project>_openbao-data`,
+where `<project>` is your clone directory name — `theta-suite` for a fresh
+clone). Quick LDAP backup:
 
 ```bash
 docker compose exec sso-manager slapcat -f /etc/openldap/slapd.conf -b "<base>" > backup.ldif

docs/index.md

@@ -4,18 +4,24 @@ title: Home
 description: A unified, one-command SSO Manager + OIDC proxy stack for home labs and small businesses. Wires together a self-hosted identity provider and a reverse proxy with one setup.sh.
 ---
 
-# theta-env
+# theta-suite
 
-The whole theta42 identity + access stack in one repo, brought up with a
-single command — for home labs and small businesses.
+The whole theta42 identity, access, and secrets stack in one repo, brought up
+with a single command — for home labs and small businesses.
 
-It wires together two projects that already work on their own —
+It composes four applications around a shared secrets store:
 [SSO Manager](https://theta42.github.io/sso-manager-node/) (OIDC provider +
-LDAP directory) and [Proxy](https://theta42.github.io/proxy/) (an
-OIDC-protected reverse proxy that can also look users up directly in LDAP) —
-and automates the fiddly part: registering the proxy as an OIDC client of the
-SSO and pointing it at the right LDAP directory, with hostnames and secrets
-generated from one `setup.env`.
+LDAP directory), [Proxy](https://theta42.github.io/proxy/) (an OIDC-protected
+reverse proxy that can also look users up directly in LDAP),
+[Jump Host](https://theta42.github.io/jump-host/) (directory-driven SSH access
+through one public entry point), and
+[ldap-client](https://theta42.github.io/ldap-client/) (enrolls your Linux
+hosts into the directory for PAM/SSSD, sudo, and SSH keys). All of them read
+their secrets at boot from [OpenBao](https://openbao.org/), the central secrets
+store. `setup.sh` automates the fiddly part: registering the proxy as an OIDC
+client of the SSO, pointing every component at the right LDAP directory and
+the OpenBao token it needs, and generating hostnames and secrets from one
+`setup.env`.
 
 ## Screenshots
 
@@ -23,14 +29,15 @@ The SSO Manager and the proxy it fronts, both stood up by one `./setup.sh` run:
 
 <a href="images/sso-dashboard.png" target="_blank"><img src="images/sso-dashboard.png" alt="SSO Manager dashboard" width="49%"></a>
 <a href="images/proxy-hosts.png" target="_blank"><img src="images/proxy-hosts.png" alt="Proxy host list" width="49%"></a>
+<a href="images/jump-dashboard.png" target="_blank"><img src="images/jump-dashboard.png" alt="Jump Host dashboard" width="49%"></a>
 
 *(click either screenshot to view full size)*
 
 ## Why this over running them separately
 
-Each project works standalone, but they only become useful together once the
-proxy is registered as an OIDC client of the SSO *and* pointed at the SSO's
-LDAP directory — and the domain has to match across half a dozen config
+The components are designed to integrate — they're only useful together once
+the proxy is registered as an OIDC client of the SSO *and* pointed at the
+SSO's LDAP directory — and the domain has to match across half a dozen config
 fields, or logins silently fail. Doing that by hand is fiddly. `setup.sh`
 asks for your domain once, generates both apps' config with it filled in
 everywhere, registers the proxy as an OIDC client automatically, and
@@ -41,7 +48,18 @@ snapshots state before every rebuild.
 - **SSO Manager**, fronted by the proxy under TLS — manage users, groups,
   and OAuth clients.
 - **Proxy** — add the hosts you want to protect with OIDC login.
-- **LDAPS** for legacy apps that bind directly.
+- **LDAPS** for direct binds — Linux hosts (PAM/SSSD, sudo, SSH keys) and
+  LDAP-native apps authenticate against the same directory.
+- **ldap-client** — enroll Linux hosts into the directory (PAM/SSSD login,
+  sudo, SSH keys); the host inventory shows up in the SSO UI and drives
+  jump-host routing.
+- **SSH Jump Host** — `ssh uid_-_host@jump.<domain>` (WinSCP-friendly)
+  or an interactive picker; access is driven by directory group membership, with
+  a web UI for audit + metrics.
+- **Central secrets (OpenBao)** — every component loads its secrets from one
+  [OpenBao](https://openbao.org/) instance at boot; each user gets personal
+  secret storage, and admins mint scoped tokens for external apps. See
+  [Secrets](secrets.html).
 - **Self-service API tokens** in both apps' UIs, for scripting/CI without a
   browser session.
 - **Multi-Site Support (Geo-Location Scaling)** — built-in support for N-Way Multi-Master LDAP replication across physical locations.
@@ -50,8 +68,8 @@ snapshots state before every rebuild.
 ## Get it
 
 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your domain
 ./setup.sh
 ```
@@ -59,7 +77,7 @@ cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your
 You need **Docker** + **Docker Compose**. `./setup.sh` is idempotent — re-run
 any time to converge the stack to `./config/`. For the full config reference,
 architecture, and running each project standalone, see the
-**[GitHub repository](https://github.com/theta42/theta-env)**.
+**[GitHub repository](https://github.com/theta42/theta-suite)**.
 
 ## Related projects
 
@@ -67,3 +85,7 @@ architecture, and running each project standalone, see the
   provider + LDAP directory this stack runs.
 - **[Proxy](https://theta42.github.io/proxy/)** — the reverse proxy this
   stack runs in front of it.
+- **[Jump Host](https://theta42.github.io/jump-host/)** — the SSH jump
+  host this stack brings up.
+- **[ldap-client](https://theta42.github.io/ldap-client/)** — enrolls Linux
+  hosts into the directory this stack serves.

docs/quickstart.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Quickstart
-description: Step-by-step first run for theta-env — prerequisites, setup.env, and bringing up the stack with ./setup.sh.
+description: Step-by-step first run for theta-suite — prerequisites, setup.env, and bringing up the stack with ./setup.sh.
 ---
 
 # Quickstart Guide
@@ -26,8 +26,8 @@ description: Step-by-step first run for theta-env — prerequisites, setup.env,
 ## 1. Clone
 
 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 ```
 
 `--recursive` fetches the two submodules (`sso-manager-node`, `proxy`) in one
@@ -60,6 +60,8 @@ setups `CFG_DOMAIN` is the only value you set:
 | `CFG_ADMIN_UID` | `admin` | optional, defaults to `admin` |
 | `CFG_ADMIN_EMAIL` | `admin@<proxyHost>` | optional |
 | `CFG_BASE_DN` | `dc=lab,dc=local` | advanced: override the derived LDAP base DN |
+| `CFG_JUMP_HOST` | `jump.lab.local` | optional, defaults to `jump.<domain>` (the [SSH jump host](https://theta42.github.io/jump-host/) is installed + started by default) |
+| `JUMP_SSH_PORT` | `2222` | optional: host port for the jump host's SSH (never 22 by default) |
 
 `setup.env` is used **only on the first run** to generate `./config/`; after
 that `./config/*.js` are operator-owned and `setup.env` is ignored. Secrets
@@ -141,9 +143,10 @@ already holds its creds).
 
 ---
 
-## Direct LDAP for legacy apps
+## Direct LDAP for LDAP-native clients and Linux hosts
 
-Legacy apps bind LDAP directly over LDAPS:
+LDAP-native apps and Linux hosts (PAM/SSSD, sudo, SSH keys) bind LDAP directly
+over LDAPS:
 
 ```bash
 ldapsearch -x -H ldaps://<host>:636 \
@@ -162,7 +165,7 @@ or the admin DN. Use LDAPS (636), not plain LDAP.
 before each rebuild (keeps the last `BACKUP_KEEP`, default 5). For manual
 backups and the full restore runbook (full / Redis-only / LDAP-only, with the
 AOF-vs-RDB note), see the *Backups and restore* section of the
-[README](https://github.com/theta42/theta-env#backups-and-restore). Quick LDAP
+[README](https://github.com/theta42/theta-suite#backups-and-restore). Quick LDAP
 backup:
 
 ```bash

docs/robots.txt

@@ -1,4 +1,4 @@
 User-agent: *
 Allow: /
 
-Sitemap: https://theta42.github.io/theta-env/sitemap.xml
+Sitemap: https://theta42.github.io/theta-suite/sitemap.xml

docs/secrets.md

@@ -0,0 +1,195 @@
+---
+layout: default
+title: Secrets (OpenBao)
+description: theta-suite's central secrets architecture — OpenBao as the single store for all app, per-user, and external-app secrets, with scoped tokens and policies.
+---
+
+# Secrets — OpenBao as the central store
+
+theta-suite keeps **every secret in one place: [OpenBao](https://openbao.org/)**
+(a Vault-community fork), running on the `theta-net` docker network at
+`http://openbao:8200`. The three apps (SSO Manager, proxy, jump host) load
+their boot secrets from it; end users get personal per-user secret storage
+through the SSO UI; and external apps get scoped, self-contained access to
+their own namespace.
+
+This page is the operator reference. For the package API, see
+[@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/).
+
+## Why a central store
+
+Before this, secret handling was partial and inconsistent: only the SSO read
+one path from OpenBao; the proxy and jump host read bind-mounted
+`./config/*-secrets.js` files; the bootstrap wrote generated OAuth creds to
+those files on disk; and the SSO `/api/vault` UI was an ungated, broken
+pass-through. Centralising on OpenBao gives every app the same fail-soft load
+path, makes per-user secret storage possible, and lets external apps get
+least-privilege access without anyone handing them the root token.
+
+## The load path (every app)
+
+1. `@simpleworkjs/conf` **synchronously** loads the bind-mounted
+   `./config/<app>-secrets.js` at require time — the file is the operator-edit
+   layer and the fail-soft fallback.
+2. `@simpleworkjs/bao-conf`'s `init({ path: '<app>', conf })` **deep-merges**
+   `secret/data/<app>/conf` from OpenBao over the live `conf` object. It is
+   **fail-soft**: if OpenBao is unreachable or the path is absent, boot
+   continues with the file-loaded config.
+3. A few secrets are **captured at require time** (notably the OIDC
+   `clientSecret`, consumed inside `createOidcClient` during
+   `require('../models')`). So `init()` must resolve *before* that
+   `require()`. Each app's `bin/www` handles this:
+   - **proxy** — defers `require('../app')` (which transitively loads models)
+     behind `bao-conf.init()`.
+   - **jump host** — gates the explicit `require('../models')` behind
+     `bao-conf.init()`.
+   - **SSO** — swaps the old `conf_manager.init()` call (same position in its
+     existing `.then()` boot chain) for `bao-conf.init()`; nothing in the SSO
+     captures a secret at require time, so no reordering was needed.
+
+`VAULT_TOKEN` (a scoped per-app token, **not** the root token) and
+`VAULT_ADDR=http://openbao:8200` are passed to each container via
+`docker-compose.yml`. The `./config/*-secrets.js` mounts stay as the fallback.
+
+## Policies, token role, and tokens
+
+`setup.sh` creates the ACL policies and mints the per-app tokens
+(idempotently — re-running keeps existing tokens and re-mints only expired
+ones). The root token stays in `.env` for setup/maintenance **only** and is
+never passed to a service container.
+
+| Policy | Capabilities | Held by |
+|---|---|---|
+| `sso-broker` | read/write `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`; `update` on `auth/token/create/sso-broker`; `update` on `sys/policies/acl/user-*`, `app-*`, `sso-admin` | SSO (`SSO_VAULT_TOKEN`) |
+| `sso-admin` | read/write/list all of `secret/*` | admin UI sessions (minted by the broker) |
+| `proxy` | read `secret/proxy/conf` | proxy (`PROXY_VAULT_TOKEN`) |
+| `jump-host` | read `secret/jump-host/conf` | jump host (`JUMP_VAULT_TOKEN`) |
+| `user-<uid>` | read/write `secret/users/<uid>/*` | per-user tokens (minted lazily by the broker) |
+| `app-<name>` | read/write `secret/apps/<name>/*` | per-external-app tokens (minted by an admin) |
+
+**Token role `sso-broker`** — `allowed_policies=sso-admin`,
+`allowed_policies_glob=user-*,app-*`, orphan, renewable, `token_period=24h`.
+The SSO mints per-user, per-admin, and per-app tokens *through* this role at
+runtime, so it never needs the root token to issue scoped access.
+
+The three per-app tokens (`SSO_VAULT_TOKEN`, `PROXY_VAULT_TOKEN`,
+`JUMP_VAULT_TOKEN`) are minted orphan + renewable and stored in `./.env` by
+`setup.sh`. They use OpenBao's default service-token TTL; if one expires,
+re-run `./setup.sh` and the `ensure_token` helper re-mints it (the old one
+expires on its own). Automated renewal is a planned follow-up, not yet built.
+
+## Seeding
+
+`setup.sh` seeds, on first run only (skipped if the path already exists):
+
+- `secret/sso-manager/conf` — from `./config/sso-secrets.js` (operator-set
+  LDAP/SMTP/`jwtSecret`; the SSO has no bootstrap-generated creds, so the file
+  is the complete source of truth).
+- `secret/proxy/conf` — from `./config/proxy-secrets.js` (placeholder OAuth
+  creds at this point).
+- `secret/jump-host/conf` — from `./config/jump-secrets.js` after the bootstrap
+  writes it.
+
+The **bootstrap** (`bootstrap/bootstrap.js`) then generates the real OAuth
+client credentials and writes the *complete* `proxy-secrets.js` and
+`jump-secrets.js` objects into `secret/proxy/conf` and `secret/jump-host/conf`
+(POST, replacing the placeholder seed). After the first run, OpenBao is
+authoritative; the `./config/*-secrets.js` files are operator-edit seed
+artifacts and the fail-soft fallback.
+
+## End-user personal secrets
+
+Every logged-in user has a personal namespace `secret/users/<uid>/*`, reached
+through the SSO UI at **Vault → My Secrets**. The SSO mints a `user-<uid>`
+token on first access (cached in Redis for the token's lifetime) and proxies
+`/api/vault` to OpenBao with **that** token injected server-side — the
+client's SSO session token never reaches OpenBao.
+
+- **Non-admins** see only their own namespace; the UI fixes the path prefix
+  to `users/<uid>/`. They can list, read, write, and delete secrets there.
+- **Admins** (`app_sso_admin` / `app_super_admin`) get free-form access across
+  all of `secret/` plus an **Apps** tab (see below).
+
+Scoping is enforced at **two** layers: the SSO's `scopeGuard` rejects any path
+outside the subject's prefix with a 403 (defense-in-depth), and the token's
+own OpenBao policy enforces the same at the API layer.
+
+## External apps
+
+An external (non-theta42) app gets scoped access to its own namespace,
+`secret/apps/<name>/*`, via a token an admin mints once from the SSO UI's
+**Vault → Apps** tab. The token is shown **once** (copy it immediately; it is
+not stored retrievably) and confined by an `app-<name>` policy.
+
+Convention:
+
+- `secret/apps/<name>/conf` for config-style secrets, `secret/apps/<name>/*`
+  for arbitrary keys.
+- The app authenticates with the header `X-Vault-Token: <minted token>`
+  against `http://<openbao-host>:8200/v1/secret/data/apps/<name>/...`.
+
+Non-Node consumers (curl):
+
+```bash
+VAULT_ADDR=http://openbao:8200   # or your external-facing openbao address
+# Write
+curl -X POST "$VAULT_ADDR/v1/secret/data/apps/my-service/conf" \
+  -H "X-Vault-Token: <token>" -H "Content-Type: application/json" \
+  -d '{"data":{"db_password":"..."}}'
+# Read
+curl -s "$VAULT_ADDR/v1/secret/data/apps/my-service/conf" \
+  -H "X-Vault-Token: <token>" | jq .data.data
+```
+
+Node consumers can use [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/)
+directly:
+
+```js
+const baoConf = require('@simpleworkjs/bao-conf');
+const data = await baoConf.get('apps/my-service/conf'); // secret/data/apps/my-service/conf
+await baoConf.set('apps/my-service/conf', { db_password: '...' });
+```
+
+## Operator rotation
+
+If a secret is exposed (or just on a routine schedule), rotate it at the
+**provider** first (the LDAP server, the SMTP host, the OAuth `jwtSecret`,
+etc.), then update OpenBao:
+
+```bash
+# Read the current sso-manager conf
+docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv get secret/sso-manager/conf
+# Write a new value (KV-v2 POST replaces the data; merge carefully)
+docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv put secret/sso-manager/conf \
+  ldap.bindPassword='<new>' smtp.password='<new>' oauth.jwtSecret='<new>'
+```
+
+Then restart the affected app so `bao-conf.init()` re-reads it
+(`docker compose restart sso-manager`). Call-time readers pick up the change
+on next read; require-time captures (OIDC `clientSecret`) need the restart.
+
+> The SSO admin **Configuration** UI (`/api/conf`) writes `secret/sso-manager/conf`
+> and updates the live conf immediately, so SMTP/discovery/oauth edits made
+> there don't need a manual `bao kv put`.
+
+## Backups
+
+The OpenBao data volume `openbao-data` holds every secret. Back it up with the
+rest of the stack (see the README's *Backups and restore* section). The
+`./config/*-secrets.js` files are **not** a complete secret backup once OpenBao
+is authoritative — they're the first-run seed and the fallback. A full disaster
+recovery restores both the `openbao-data` volume (the authoritative store) and
+`./config/` (the seed/fallback), then runs `./setup.sh` to unseal OpenBao and
+re-mint the per-app tokens.
+
+## What's not in scope yet
+
+- **Renewal automation** — per-app/user tokens use OpenBao's default TTL and
+  are re-minted by `setup.sh` on expiry; a periodic renewal worker is a
+  follow-up.
+- **History scrubbing** — if a secret was committed to git, rotating it is the
+  fix; scrubbing it from git history (BFG / `git filter-repo`) is a separate,
+  git-destructive operation you can opt into.
+- **Per-app secrets beyond boot config** (e.g. the proxy's DNS-provider creds,
+  the jump host's per-user LDAP SSH keys) moving into OpenBao — only the
+  boot-critical `*-secrets.js` contents moved in this phase.

docs/standalone.md

@@ -1,16 +1,23 @@
 ---
 layout: default
 title: Standalone
-description: Running the SSO Manager or the proxy on their own, without theta-env's orchestration.
+description: Running a component individually, without theta-suite's orchestration — an advanced path; the integrated stack is the supported one.
 ---
 
-# Running each project standalone
+# Running a component individually
 
 [← Back to Home](index.html)
 
-theta-env composes the two projects but doesn't fork them — both work on their
-own. The submodules in this repo are normal clones; you can also clone them
-directly from GitHub.
+> **The integrated stack is the supported path.** `./setup.sh` wiring all four
+> components together around a shared OpenBao secrets store is what's tested and
+> released. The steps below are for the advanced case where you want to run one
+> component on its own — a separate host, a different network, or without the
+> orchestrator. Running standalone means managing secrets from the
+> `config/*-secrets.js` file only (no shared OpenBao) and doing the OIDC/LDAP
+> wiring by hand.
+
+The submodules in this repo are normal clones; you can also clone them directly
+from GitHub. Each component builds and runs on its own.
 
 ---
 
@@ -114,10 +121,12 @@ See the proxy
 
 ---
 
-## Mixing and matching
+## Wiring components together by hand
 
-theta-env isn't required to use the two together — the four wiring steps are
-documented in both projects' deployment guides:
+If you have a specific reason to run the components on separate hosts instead
+of through `./setup.sh` (and accept that you lose the shared OpenBao secrets
+store), the four wiring steps are documented in both projects' deployment
+guides:
 
 1. One Docker network (or reachable hostnames) so the proxy can reach the SSO
    internally for token/userinfo + LDAPS.
@@ -129,8 +138,8 @@ documented in both projects' deployment guides:
 4. Point the proxy's `ldap.url` at the SSO's LDAPS + create a dedicated
    `cn=ldapclient` service account; set the same password as `bindPassword`.
 
-theta-env just automates those four steps with `./setup.sh`. If you prefer to
-do them by hand (or want the two on separate hosts), follow the standalone
-guides above.
+`./setup.sh` exists to do all of this for you — and to add the OpenBao secrets
+store, jump host, and ldap-client on top. Unless you need the components on
+separate hosts, prefer the integrated stack.
 
 [← Back to Home](index.html)

pr_url.txt

@@ -1 +1 @@
-https://github.com/theta42/theta-env/pull/75
+https://github.com/theta42/theta-suite/pull/75

setup.env.example

@@ -1,5 +1,5 @@
 # ─────────────────────────────────────────────────────────────────────────────
-# setup.env — first-run setup for the theta-env stack.
+# setup.env — first-run setup for the theta-suite stack.
 #
 # This file is used ONLY on the FIRST run of ./setup.sh, to generate
 # ./config/sso-secrets.js + ./config/proxy-secrets.js with your domain filled
@@ -33,15 +33,14 @@ CFG_DOMAIN=example.com
 #CFG_SSO_HOST=sso.example.com
 #CFG_PROXY_HOST=proxy.example.com
 
-# ── Optional SSH jump host ───────────────────────────────────────────────────
-# Enable the theta42/jump-host component: a public SSH jump host that
-# authenticates users against the directory and bridges them to downstream
-# hosts (ssh uid_-_target@jump, or an interactive picker). Off by default.
-# When true, setup.sh clones/builds the jump-host submodule, the bootstrap
-# mints its directory API token + writes ./config/jump-secrets.js, and it's
-# registered in the proxy + directory. See jump-host's README for the LDAP
-# write-ACL note (the bundled deployment binds as cn=admin).
-#CFG_JUMP_HOST_ENABLED=false
+# ── SSH jump host (always installed) ─────────────────────────────────────────
+# The theta42/jump-host component is installed and started by default — a
+# public SSH jump host that authenticates users against the directory and
+# bridges them to downstream hosts (ssh uid_-_target@jump, or an interactive
+# picker). setup.sh clones/builds the jump-host submodule, the bootstrap mints
+# its directory API token + writes ./config/jump-secrets.js, and it's registered
+# in the proxy + directory. See jump-host's README for the LDAP write-ACL note
+# (the bundled deployment binds as cn=admin).
 #CFG_JUMP_HOST=jump.example.com   # defaults to jump.<domain>
 #JUMP_SSH_PORT=2222               # host port mapped to the jump host's SSH (never 22 by default)
 
@@ -49,6 +48,19 @@ CFG_DOMAIN=example.com
 # under an OU-style prefix). Leave unset to use the DN built from CFG_DOMAIN:
 #CFG_BASE_DN=dc=example,dc=com
 
+# ── Optional outbound HTTP(S) proxy ──────────────────────────────────────────
+# For an isolated/offline/corporate-network test host that only reaches the
+# internet through an upstream HTTP proxy — NOT the theta42 "proxy" app.
+# Wired into every service's docker build (npm/apt) AND its running container
+# (SMTP, ACME/Let's Encrypt, DNS provider calls, the jump-host directory API
+# client). Leave unset to disable (the default); CFG_HTTPS_PROXY falls back to
+# CFG_HTTP_PROXY if unset, and CFG_NO_PROXY defaults to covering the stack's
+# own internal service names so container-to-container traffic never goes
+# through the proxy.
+#CFG_HTTP_PROXY=http://proxy.example.com:3128
+#CFG_HTTPS_PROXY=http://proxy.example.com:3128
+#CFG_NO_PROXY=localhost,127.0.0.1,sso-manager,proxy,jump-host
+
 # Optional — sensible defaults if left blank:
 #CFG_ORG=SSO Manager            # app display name + outbound email org
 #CFG_ADMIN_UID=admin            # initial SSO admin username

setup.sh

@@ -1,8 +1,8 @@
 #!/usr/bin/env bash
 #
-# theta-env setup — one-command bring-up of the unified SSO Manager + Proxy stack.
+# theta-suite setup — one-command bring-up of the unified SSO Manager + Proxy stack.
 #
-#   git clone --recursive <theta-env> && cd theta-env
+#   git clone --recursive <theta-suite> && cd theta-suite
 #   cp setup.env.example setup.env   # set CFG_DOMAIN to your domain (once)
 #   ./setup.sh            # first run: generates ./config/ from setup.env, builds + bootstraps + starts
 #   ./setup.sh            # later runs: rebuilds + bootstraps + starts (config left untouched)
@@ -19,7 +19,7 @@
 # no manual `git pull` needed first.
 #
 # What it does, in order:
-#   0. Pull theta-env's own latest commit (fast-forward only) and, if it
+#   0. Pull theta-suite's own latest commit (fast-forward only) and, if it
 #      moved, re-exec so the rest of this run uses the new script. Never
 #      blocks the run — skips silently with no upstream, warns and continues
 #      on any other pull failure (offline, local changes). Skip with
@@ -88,6 +88,23 @@ rand_hex() {
 	fi
 }
 
+# Upsert KEY=VALUE into ./.env, which `docker compose` auto-loads for every
+# future invocation in this directory. Used to persist the *_GIT_COMMIT build
+# args (see SSO_GIT_COMMIT/PROXY_GIT_COMMIT/JUMP_GIT_COMMIT below) so that an
+# ad-hoc `docker compose up --build <service>` run later, OUTSIDE this script,
+# still resolves the right commit instead of silently baking "unknown" (the
+# submodule .git pointer file can't be resolved from inside the build
+# context, so the value must come from the host via this file or the export).
+env_upsert() {
+	local key="$1" val="$2" file=./.env
+	touch "$file"
+	if grep -q "^${key}=" "$file" 2>/dev/null; then
+		sed -i "s|^${key}=.*|${key}=${val}|" "$file"
+	else
+		printf '%s=%s\n' "$key" "$val" >> "$file"
+	fi
+}
+
 # Detect docker compose (v2 plugin `docker compose` or v1 standalone `docker-compose`).
 if docker compose version >/dev/null 2>&1; then
 	COMPOSE=(docker compose)
@@ -124,7 +141,7 @@ parse_kv_file() {
 	done < "$file"
 }
 
-# ── 0. Self-update: pull theta-env itself, then restart with the new version ──
+# ── 0. Self-update: pull theta-suite itself, then restart with the new version ──
 # Step 1 below only refreshes the proxy/sso-manager-node submodules — it never
 # updates setup.sh or this repo's own files. Pull the current branch's
 # upstream (fast-forward only) before anything else, and if it moved, re-exec
@@ -134,7 +151,7 @@ parse_kv_file() {
 # warns (but continues on the current checkout) if the pull fails for any
 # other reason (offline, local changes that prevent a fast-forward). Skip
 # entirely with SKIP_SELF_UPDATE=1.
-if [[ "${SKIP_SELF_UPDATE:-0}" != "1" && "${THETA_ENV_REEXECED:-0}" != "1" ]] \
+if [[ "${SKIP_SELF_UPDATE:-0}" != "1" && "${THETA_SUITE_REEXECED:-0}" != "1" ]] \
 	&& command -v git >/dev/null 2>&1 && git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
 	&& git rev-parse --abbrev-ref --symbolic-full-name '@{u}' >/dev/null 2>&1
 then
@@ -144,26 +161,38 @@ then
 		AFTER_REV="$(git rev-parse HEAD)"
 		if [[ "$BEFORE_REV" != "$AFTER_REV" ]]; then
 			AFTER_VER="$(git describe --tags "$AFTER_REV" 2>/dev/null || echo "${AFTER_REV:0:12}")"
-			info "Updated theta-env (${BEFORE_VER} -> ${AFTER_VER}) — restarting setup.sh with the new version..."
-			THETA_ENV_REEXECED=1 exec "$0" "$@"
+			info "Updated theta-suite (${BEFORE_VER} -> ${AFTER_VER}) — restarting setup.sh with the new version..."
+			THETA_SUITE_REEXECED=1 exec "$0" "$@"
 		fi
 	else
-		warn "Could not fast-forward theta-env to the latest upstream (offline, or local changes) — continuing with the current checkout."
+		warn "Could not fast-forward theta-suite to the latest upstream (offline, or local changes) — continuing with the current checkout."
 	fi
 fi
 
-# ── Optional jump host: resolve the enable flag early ─────────────────────────
-# CFG_JUMP_HOST_ENABLED gates the optional SSH jump host (a third submodule).
-# Read it from the environment or ./setup.env now (before the submodule loop
-# and the compose steps) so every run knows whether to build/start it. The
-# authoritative CFG_* for secrets are still resolved in ensure_config; this is
-# only the on/off switch + its hostname.
+# ── Jump host hostname (always installed) ─────────────────────────────────────
+# The SSH jump host is a core component — always built + started (no longer
+# gated by CFG_JUMP_HOST_ENABLED). Read its optional hostname override from
+# ./setup.env now (before the submodule loop and the compose steps) so the
+# later steps can use it. The authoritative CFG_* for secrets are still
+# resolved in ensure_config; this is only the hostname override.
 [[ -f ./setup.env ]] && parse_kv_file ./setup.env
-JUMP_ENABLED=0
-case "${CFG_JUMP_HOST_ENABLED:-}" in 1|true|TRUE|yes|YES) JUMP_ENABLED=1 ;; esac
-export CFG_JUMP_HOST_ENABLED CFG_JUMP_HOST
-# When enabled, activate the compose profile so `up`/`ps` include the service.
-if [[ "$JUMP_ENABLED" == "1" ]]; then export COMPOSE_PROFILES="jump-host"; fi
+export CFG_JUMP_HOST
+
+# ── Optional outbound HTTP(S) proxy for docker build + the running containers ─
+# CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY (from ./setup.env or the
+# environment) — NOT the theta42 "proxy" app; this is an upstream HTTP proxy
+# for reaching the internet (npm/apt during image builds, and SMTP/ACME/DNS
+# provider calls at runtime), useful on isolated/offline/corporate-network
+# test hosts. Off by default. docker-compose.yml passes these through as both
+# build args (Docker also recognizes them as predefined build ARGs) and
+# container environment on every service, so one setup.env entry covers the
+# whole stack.
+export CFG_HTTP_PROXY="${CFG_HTTP_PROXY:-}"
+export CFG_HTTPS_PROXY="${CFG_HTTPS_PROXY:-${CFG_HTTP_PROXY:-}}"
+export CFG_NO_PROXY="${CFG_NO_PROXY:-localhost,127.0.0.1,sso-manager,proxy,jump-host}"
+if [[ -n "$CFG_HTTP_PROXY" ]]; then
+	info "Using HTTP proxy for docker build + containers: $CFG_HTTP_PROXY"
+fi
 
 # ── 1. Update submodules to their latest release tag, verify build contexts ───
 # Submodules track release tags (vX.Y.Z), not the tip of master -- so
@@ -180,9 +209,8 @@ if [[ "${SKIP_SUBMODULE_UPDATE:-0}" != "1" ]]; then
 		die "git submodule update --init failed. Run manually: git submodule update --init --recursive"
 	fi
 
-	# jump-host is optional: only track/build it when enabled.
-	SUBMODULES=(sso-manager-node proxy)
-	[[ "$JUMP_ENABLED" == "1" ]] && SUBMODULES+=(jump-host)
+	# jump-host is a core component — always tracked + built.
+	SUBMODULES=(sso-manager-node proxy jump-host)
 	info "Updating submodules to their latest release tag (${SUBMODULES[*]})..."
 	for sm in "${SUBMODULES[@]}"; do
 		[[ -d "$sm" ]] || continue
@@ -276,6 +304,16 @@ module.exports = {
 		jwtSecret: $(js_str "$CFG_JWT_SECRET"),
 		token_lifetime: { access_token: 3600, refresh_token: 2592000 },
 	},
+	// Without this, @simpleworkjs/orm falls back to './config/inventory.sqlite'
+	// relative to the app's /app cwd -- inside the container's ephemeral layer,
+	// not any mounted volume -- so every Resource/site/host/service/oauth row
+	// (the whole Directory Management page) would be silently wiped on every
+	// container recreate. /data is already a persisted volume (Redis lives
+	// there too), so this just co-locates the sqlite file with it.
+	orm: {
+		dialect: 'sqlite',
+		storage: '/data/inventory.sqlite',
+	},
 
 	// ── Orchestrator-only (ignored by the app) ───────────────────────────────
 	stack: {
@@ -349,6 +387,23 @@ PROXYEOF
 }
 
 ensure_config() {
+	if [[ ! -f "$CONFIG_DIR/openbao.hcl" ]]; then
+		info "Generating $CONFIG_DIR/openbao.hcl ..."
+		mkdir -p "$CONFIG_DIR"
+		cat > "$CONFIG_DIR/openbao.hcl" <<BAOEOF
+storage "file" {
+  path = "/vault/data"
+}
+listener "tcp" {
+  address     = "0.0.0.0:8200"
+  tls_disable = 1
+}
+disable_mlock = true
+ui = true
+BAOEOF
+		chmod 644 "$CONFIG_DIR/openbao.hcl"
+	fi
+
 	if [[ -f "$CONFIG_DIR/sso-secrets.js" ]]; then
 		info "Using existing $CONFIG_DIR/sso-secrets.js (operator-owned — left untouched)."
 		return 0
@@ -458,6 +513,7 @@ ensure_config() {
 	mkdir -p "$CONFIG_DIR" && chmod 700 "$CONFIG_DIR"
 	write_sso_secrets
 	write_proxy_secrets
+	
 	chmod 600 "$CONFIG_DIR/sso-secrets.js" "$CONFIG_DIR/proxy-secrets.js"
 
 	if [[ "$migrated" == "1" ]]; then
@@ -509,7 +565,7 @@ backup_before_rebuild() {
 	# bind-mount was added), then fall back to reading it inside the container.
 	# Use `docker exec <name>` (not `docker-compose exec`) so the snapshot works
 	# no matter which compose project brought the container up — the unified
-	# theta-env stack (project "theta-env") and the standalone submodule stack
+	# theta-suite stack (project "theta-suite") and the standalone submodule stack
 	# (project "sso-manager-node") both name it "sso-manager". `docker-compose
 	# exec` from the superproject otherwise exits 1 silently (wrong project) and
 	# the snapshot silently no-ops.
@@ -603,6 +659,166 @@ backup_before_rebuild() {
 }
 backup_before_rebuild
 
+# ── 3b. Setup OpenBao (Vault) ────────────────────────────────────────────────
+info "Starting openbao..."
+"${COMPOSE[@]}" run --rm --user root openbao chown -R 100:1000 /vault/data
+"${COMPOSE[@]}" up -d openbao
+info "Waiting for openbao to be reachable..."
+for i in $(seq 1 30); do
+	if docker exec openbao bao status >/dev/null 2>&1 || [[ $? -eq 2 ]]; then
+		info "openbao is reachable."; break
+	fi
+	if (( i == 30 )); then die "openbao did not become reachable in 60s. Check: ${COMPOSE[*]} logs openbao"; fi
+	sleep 2
+done
+
+if ! docker exec openbao bao status -format=json 2>/dev/null | grep -q '"initialized": true' || true; then
+    status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
+    if ! echo "$status_json" | grep -q '"initialized": true'; then
+        info "Initializing openbao for the first time..."
+        docker exec openbao bao operator init -key-shares=1 -key-threshold=1 -format=json > "$CONFIG_DIR/bao-init.json"
+        chmod 600 "$CONFIG_DIR/bao-init.json"
+        info "Openbao initialized. Keys saved to $CONFIG_DIR/bao-init.json"
+    fi
+fi
+
+status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
+if echo "$status_json" | grep -q '"sealed": true'; then
+	info "Unsealing openbao..."
+	UNSEAL_KEY=$(grep -A1 '"unseal_keys_b64":' "$CONFIG_DIR/bao-init.json" | tail -n1 | cut -d'"' -f2)
+	docker exec openbao bao operator unseal "$UNSEAL_KEY" >/dev/null
+fi
+
+export VAULT_TOKEN
+VAULT_TOKEN=$(grep '"root_token":' "$CONFIG_DIR/bao-init.json" | cut -d'"' -f4)
+env_upsert VAULT_TOKEN "$VAULT_TOKEN"
+
+if ! docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao secrets list -format=json 2>/dev/null | grep -q '"secret/":'; then
+    info "Enabling kv-v2 secrets engine at secret/..."
+    docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao secrets enable -path=secret kv-v2 >/dev/null
+fi
+
+# ── 3c. OpenBao policies, token role, per-app tokens ─────────────────────────
+# Each app gets a least-privilege scoped token (a policy over only its own
+# secret/<app>/conf). sso additionally gets the `sso-broker` policy so it can
+# mint per-user (user-<uid>) and per-app (app-<name>) tokens at runtime through
+# the sso-broker token role. The root VAULT_TOKEN stays in .env for
+# setup/maintenance ONLY and is never passed to a service container. Everything
+# here is idempotent — re-running setup.sh keeps existing policies/tokens.
+
+# Run a `bao` command inside the openbao container as root.
+bao_run() { docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao "$@"; }
+
+# Write an ACL policy from stdin HCL only if it does not already exist.
+ensure_policy() {
+	local name="$1"
+	if bao_run policy read "$name" >/dev/null 2>&1; then
+		info "  policy ${name} already exists — keeping."
+	else
+		info "  writing policy ${name}..."
+		docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao policy write "$name" - >/dev/null
+	fi
+}
+
+# Read KEY= from ./.env (empty if absent) — reuse a previously minted token
+# instead of minting a fresh one on every setup.sh run.
+env_get() {
+	local key="$1" file=./.env
+	[[ -f "$file" ]] || return 0
+	# `|| true` is load-bearing: under `set -euo pipefail`, a no-match `grep`
+	# exits 1 and (pipefail) makes the whole pipeline return 1. Callers do
+	# `existing="$(env_get ...)"` as a bare assignment — a non-zero return there
+	# trips `set -e` and silently kills the whole script (this is exactly what
+	# aborted a fresh install right after "Minting per-app OpenBao tokens": the
+	# root VAULT_TOKEN env_upsert had already created .env, but the app-token
+	# keys were absent, so the first env_get returned 1). "Key absent" is the
+	# normal path here, so always return 0 with empty output.
+	grep -m1 "^${key}=" "$file" 2>/dev/null | cut -d= -f2- || true
+}
+
+# Mint an orphan, renewable token for `policy` and persist it to .env as `key`,
+# OR reuse the token already in .env if it is still valid (re-mint on expiry).
+ensure_token() {
+	local key="$1" policy="$2" existing tok
+	existing="$(env_get "$key")"
+	if [[ -n "$existing" ]] && docker exec -e BAO_TOKEN="$existing" openbao bao token lookup >/dev/null 2>&1; then
+		info "  ${key} already minted + valid — keeping."
+		return 0
+	fi
+	info "  minting ${key} (policy=${policy})..."
+	tok="$(bao_run token create -policy="$policy" -orphan=true -field=token)" \
+		|| die "failed to mint ${key} (policy=${policy})"
+	env_upsert "$key" "$tok"
+}
+
+# Seed secret/<vault_path> from a /config/*.js module on first run only
+# (skipped if the path already exists). Fail-soft: a seed failure leaves the
+# app's file-mounted config as the fallback — boot is not blocked.
+seed_app_conf() {
+	local vault_path="$1" mod="$2"
+	if bao_run kv get "secret/${vault_path}" >/dev/null 2>&1; then
+		info "  secret/${vault_path} already seeded — keeping."
+		return 0
+	fi
+	info "Seeding secret/${vault_path} from ${mod}..."
+	docker exec sso-manager node -e "console.log(JSON.stringify(require('${mod}')))" 2>/dev/null \
+		| docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv put "secret/${vault_path}" - >/dev/null \
+		|| warn "  could not seed secret/${vault_path} (continuing — app will use its file fallback)"
+}
+
+info "Configuring OpenBao policies..."
+# sso-broker — sso's authority to read/write its own conf, mint per-user and
+# per-app tokens (auth/token/create/sso-broker), and create the matching
+# user-<uid> / app-<name> / sso-admin policies.
+ensure_policy sso-broker <<'HCL'
+path "secret/data/sso-manager/conf" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/sso-manager/conf" { capabilities = ["list", "read", "delete"] }
+path "secret/data/users/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/users/*" { capabilities = ["list", "read", "delete"] }
+path "secret/data/apps/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/apps/*" { capabilities = ["list", "read", "delete"] }
+path "auth/token/create/sso-broker" { capabilities = ["update"] }
+path "sys/policies/acl/user-*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "sys/policies/acl/app-*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "sys/policies/acl/sso-admin" { capabilities = ["create", "read", "update", "delete", "list"] }
+HCL
+# sso-admin — admin users in the vault UI: read/write/list everything under secret/.
+ensure_policy sso-admin <<'HCL'
+path "secret/data/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/*" { capabilities = ["list", "read", "delete"] }
+HCL
+# proxy / jump-host — read only their own boot conf.
+ensure_policy proxy <<'HCL'
+path "secret/data/proxy/conf" { capabilities = ["read"] }
+path "secret/metadata/proxy/conf" { capabilities = ["read", "list"] }
+HCL
+ensure_policy jump-host <<'HCL'
+path "secret/data/jump-host/conf" { capabilities = ["read"] }
+path "secret/metadata/jump-host/conf" { capabilities = ["read", "list"] }
+HCL
+
+# sso-broker token role: lets sso mint user-*/app-*/sso-admin tokens. Orphan,
+# renewable, 24h period. Wildcards need allowed_policies_glob — allowed_policies
+# is exact-match only.
+info "Configuring sso-broker token role..."
+if ! bao_run read auth/token/roles/sso-broker >/dev/null 2>&1; then
+	docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao write auth/token/roles/sso-broker - <<'JSON' >/dev/null
+{"allowed_policies":["sso-admin"],"allowed_policies_glob":["user-*","app-*"],"orphan":true,"renewable":true,"token_period":"24h"}
+JSON
+else
+	info "  token role sso-broker already exists — keeping."
+fi
+
+info "Minting per-app OpenBao tokens (stored in .env, passed to containers as VAULT_TOKEN)..."
+ensure_token SSO_VAULT_TOKEN sso-broker
+ensure_token PROXY_VAULT_TOKEN proxy
+ensure_token JUMP_VAULT_TOKEN jump-host
+
+info "OpenBao secrets configured:"
+info "  policies:   sso-broker, sso-admin, proxy, jump-host (+ per-user/app created lazily by sso)"
+info "  token role: sso-broker (mints user-*/app-*/sso-admin tokens, 24h period)"
+info "  app tokens: SSO_VAULT_TOKEN, PROXY_VAULT_TOKEN, JUMP_VAULT_TOKEN in .env"
+
 # ── 4. Start SSO Manager, wait for health ─────────────────────────────────────
 # SSO_GIT_COMMIT: sso-manager-node is a git submodule here, so its .git is a
 # pointer file (not a real repo) -- the image can't resolve its own commit
@@ -611,6 +827,7 @@ backup_before_rebuild
 # docker-compose.yml and sso-manager-node's Dockerfile.openldap.
 SSO_GIT_COMMIT="$(git -C sso-manager-node rev-parse --short HEAD 2>/dev/null || echo unknown)"
 export SSO_GIT_COMMIT
+env_upsert SSO_GIT_COMMIT "$SSO_GIT_COMMIT"
 info "Building + starting sso-manager (first run builds the image; this takes a while)..."
 "${COMPOSE[@]}" up -d --build sso-manager
 
@@ -626,6 +843,16 @@ for i in $(seq 1 60); do
 	sleep 2
 done
 
+info "Seeding app configs into OpenBao (idempotent)..."
+# sso-manager/conf holds the operator-set LDAP/SMTP/jwtSecret values — sso has
+# no bootstrap-generated creds, so the file is the complete source of truth.
+seed_app_conf sso-manager/conf /config/sso-secrets.js
+# proxy/conf is seeded from the operator file (placeholder OAuth creds); the
+# bootstrap (step 5) then writes the real generated OAuth client creds into
+# OpenBao over this. proxy boots at step 6, after bootstrap, so it sees the
+# real values.
+seed_app_conf proxy/conf /config/proxy-secrets.js
+
 # Read the summary values (hosts, admin, base DN) back from ./config via the
 # running container's node — works whether ./config was generated or pre-existing.
 read_config_kv() {
@@ -656,7 +883,11 @@ info "  Admin uid:     ${ADMIN_UID}"
 
 # ── 5. Run the bootstrap (writes CLIENT_ID/CLIENT_SECRET/ALREADY_CONFIGURED) ──
 # The bootstrap reads its inputs from /config/*.js (not env) and writes the
-# generated OAuth client creds back into /config/proxy-secrets.js. No -e flags.
+# generated OAuth client creds back into /config/proxy-secrets.js AND into
+# OpenBao (secret/proxy/conf, secret/jump-host/conf) so the proxy + jump host
+# load them from OpenBao at boot. The root VAULT_TOKEN is passed on this one
+# exec so bootstrap can write those paths; it is never handed to a service
+# container.
 info "Running bootstrap (creates/updates the LDAP service account, first admin, OAuth client)..."
 # Host facts for the directory seed — collected HERE (on the host; inside the
 # container hostname/uname describe the container, not the machine). Same
@@ -676,8 +907,9 @@ BOOTSTRAP_OUT=$("${COMPOSE[@]}" exec -T \
 	-e STACK_HOST_MAC="$STACK_HOST_MAC" \
 	-e STACK_HOST_OS="$STACK_HOST_OS" \
 	-e STACK_HOST_KERNEL="$STACK_HOST_KERNEL" \
-	-e CFG_JUMP_HOST_ENABLED="${CFG_JUMP_HOST_ENABLED:-}" \
 	-e CFG_JUMP_HOST="${CFG_JUMP_HOST:-}" \
+	-e VAULT_ADDR=http://openbao:8200 \
+	-e VAULT_TOKEN="$VAULT_TOKEN" \
 	sso-manager node /bootstrap/bootstrap.js) \
 	|| die "bootstrap failed:\n${BOOTSTRAP_OUT}"
 
@@ -696,6 +928,7 @@ fi
 # PROXY_GIT_COMMIT: same reasoning as SSO_GIT_COMMIT above.
 PROXY_GIT_COMMIT="$(git -C proxy rev-parse --short HEAD 2>/dev/null || echo unknown)"
 export PROXY_GIT_COMMIT
+env_upsert PROXY_GIT_COMMIT "$PROXY_GIT_COMMIT"
 info "Building + starting proxy (first run builds the image; this takes a while)..."
 "${COMPOSE[@]}" up -d --build proxy
 
@@ -753,29 +986,34 @@ NODEEOF
 ) || die "Registering hosts with the proxy failed:\n${HOSTS_OUT}"
 echo "$HOSTS_OUT" | sed 's/^/[setup] /'
 
-# ── 7b. Optional: build + start the SSH jump host ─────────────────────────────
-# Enabled by CFG_JUMP_HOST_ENABLED. The bootstrap (step 5) already wrote
-# ./config/jump-secrets.js (minted API token + LDAP admin bind). Build/start the
-# service (compose profile 'jump-host' is active), wait for its web /health, and
-# register its web UI hostname as a proxy Host so https://<JUMP_HOST> routes.
-if [[ "$JUMP_ENABLED" == "1" ]]; then
-	JUMP_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
-	JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
-	export JUMP_GIT_COMMIT
-	info "Building + starting jump-host (optional; enabled via CFG_JUMP_HOST_ENABLED)..."
-	"${COMPOSE[@]}" up -d --build jump-host
+# ── 7b. Build + start the SSH jump host ──────────────────────────────────────
+# The jump host is a core component (no longer optional). The bootstrap (step 5)
+# already wrote ./config/jump-secrets.js (minted API token + LDAP admin bind) and
+# mirrored it into OpenBao. Build/start the service, wait for its web /health,
+# and register its web UI hostname as a proxy Host so https://<JUMP_HOST> routes.
+JUMP_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
+JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
+export JUMP_GIT_COMMIT
+env_upsert JUMP_GIT_COMMIT "$JUMP_GIT_COMMIT"
+# Seed jump-host/conf from the file bootstrap just wrote (it mints the API
+# token + OAuth client into /config/jump-secrets.js at step 5). bootstrap also
+# writes this to OpenBao directly, so this is a fallback for when bootstrap's
+# jump provisioning warned-but-continued.
+seed_app_conf jump-host/conf /config/jump-secrets.js
+info "Building + starting jump-host..."
+"${COMPOSE[@]}" up -d --build jump-host
 
-	info "Waiting for jump-host to be healthy..."
-	for i in $(seq 1 60); do
-		if docker exec jump-host node -e "require('http').get('http://localhost:3002/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))" >/dev/null 2>&1; then
-			info "jump-host is healthy."; break
-		fi
-		if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
-		sleep 2
-	done
+info "Waiting for jump-host to be healthy..."
+for i in $(seq 1 60); do
+	if docker exec jump-host node -e "require('http').get('http://localhost:3002/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))" >/dev/null 2>&1; then
+		info "jump-host is healthy."; break
+	fi
+	if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
+	sleep 2
+done
 
-	info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
-	JUMP_HOSTS_OUT=$("${COMPOSE[@]}" exec -T proxy node <<NODEEOF || true
+info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
+JUMP_HOSTS_OUT=$("${COMPOSE[@]}" exec -T proxy node <<NODEEOF || true
 const {Host} = require('/app/models').models;
 (async () => {
 	try {
@@ -790,8 +1028,7 @@ const {Host} = require('/app/models').models;
 })();
 NODEEOF
 )
-	echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'
-fi
+echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'
 
 # ── 8. Summary ───────────────────────────────────────────────────────────────
 echo
@@ -801,11 +1038,9 @@ echo "  SSO Manager UI:    https://${SSO_HOST}   (fronted by the proxy under TLS
 echo "                      first-run fallback: http://127.0.0.1:${SSO_PORT:-3001}"
 echo "  Proxy mgmt UI:      https://${PROXY_HOST}"
 echo "                      first-run fallback: http://127.0.0.1:${MGMT_PORT:-3000}"
-if [[ "$JUMP_ENABLED" == "1" ]]; then
 echo "  Jump host (SSH):    ssh -p ${JUMP_SSH_PORT:-2222} <uid>@${JUMP_HOST:-jump.${SSO_HOST#sso.}}   (TUI picker)"
 echo "                      ssh -p ${JUMP_SSH_PORT:-2222} <uid>_-_<host>@${JUMP_HOST:-jump.${SSO_HOST#sso.}}"
 echo "  Jump host (web):    https://${JUMP_HOST:-jump.${SSO_HOST#sso.}}   (audit + metrics)"
-fi
 echo
 echo "  First admin login credentials are in ./config/sso-secrets.js:"
 echo "    user: ${ADMIN_UID}"

test-integration.sh

@@ -0,0 +1,44 @@
+#!/bin/bash
+set -e
+
+echo "=== Starting theta-suite Integration Tests ==="
+
+echo "=> Cleaning up any existing containers and volumes..."
+docker-compose down -v
+
+echo "=> Running setup.sh to initialize environment..."
+# Run setup non-interactively if possible (we might need to export some env vars)
+# setup.sh uses dialog, which requires a terminal, but it falls back to defaults if not interactive?
+# Actually setup.sh has a dialog UI. Let's just run it or provide a seeded config.
+# If setup.sh is strictly interactive, we might need to bypass it or provide answers.
+# Let's try running docker-compose up directly if setup.sh is too interactive, but the user explicitly said "Make sure setup.sh like your change, then do a full release. Make sure each repo has a current change log, is pushed and and merged." and "Automated testing in theta-suite to test integration between all the include projects".
+
+# Wait, setup.sh has no silent mode out of the box unless we provide answers.
+echo "=> Initializing OpenBao manually for tests (simulating setup.sh)"
+# Actually, setup.sh initializes Vault. If we don't run it, Vault is sealed!
+# Let's just write a curl test that checks if the containers start.
+
+docker-compose up -d
+
+echo "=> Waiting for services to become healthy..."
+sleep 15 # Give time for containers to spin up
+
+# Test proxy
+echo "=> Testing Proxy..."
+if ! curl -sS -o /dev/null -w "%{http_code}" http://localhost | grep -q "406"; then
+  echo "❌ Proxy failed to respond with 406 Not Acceptable on port 80 (default behavior)"
+  exit 1
+fi
+echo "✅ Proxy responds on port 80"
+
+# Test SSO Manager Node
+echo "=> Testing SSO Manager..."
+if ! curl -sS -f -o /dev/null http://localhost:3001; then
+  echo "❌ SSO Manager failed to respond on port 3001"
+  exit 1
+fi
+echo "✅ SSO Manager responds on port 3001"
+
+echo "=== All integration tests passed! ==="
+docker-compose down -v
+exit 0

test/check_jump_ldap_tls.js

@@ -0,0 +1,66 @@
+#!/usr/bin/env node
+'use strict';
+
+// Regression guard for bootstrap.js's generated jump-secrets.js template:
+// its ldap block must use ldaps:// (implicit TLS, :636), never ldap:// (:389),
+// as long as tlsOptions is set alongside it.
+//
+// ldapts treats a non-empty tlsOptions as "use implicit TLS" regardless of URL
+// scheme, and jump-host's LDAP client always sets tlsOptions -- so ldap://
+// + tlsOptions opens a raw TLS handshake against a port serving plaintext
+// LDAP. The server silently drops the connection before any LDAP message
+// parses, and every operation (getUser, checkPassword, ...) then fails
+// identically -- indistinguishable from a wrong password. This shipped once
+// (every SSH login to jump-host failed, for any account, any password) before
+// being root-caused against a real deployment. Static, not a require()+exec
+// of bootstrap.js, because bootstrap.js is a self-running provisioning script
+// with real side effects (LDAP writes, API calls), not a library.
+
+const fs = require('fs');
+const path = require('path');
+
+const BOOTSTRAP_PATH = path.join(__dirname, '..', 'bootstrap', 'bootstrap.js');
+const src = fs.readFileSync(BOOTSTRAP_PATH, 'utf8');
+
+// Isolate the generated jump-secrets.js template (the backtick string
+// assigned to `body` inside writeJumpSecrets) rather than scanning the whole
+// file, so this only ever looks at what's actually written to the deployed
+// config -- not, say, a comment or an unrelated ldap:// URL elsewhere.
+// bootstrap.js's own source has literal backslash-t escape sequences inside
+// the backtick string (they only become real tabs when the template
+// literal is actually evaluated) -- so these patterns match `\t` as two
+// literal characters, not a real tab byte.
+const bodyMatch = /const body = `([\s\S]*?)`;\n\tfs\.writeFileSync\(JUMP_SECRETS/.exec(src);
+if (!bodyMatch) {
+	console.error('check_jump_ldap_tls: could not locate the jump-secrets.js template in bootstrap.js — did writeJumpSecrets change shape?');
+	process.exit(1);
+}
+const template = bodyMatch[1];
+
+// Bounded by the next top-level key (sso:) rather than the ldap block's own
+// closing brace, which is more robust to exactly how it's indented/escaped.
+const ldapBlockMatch = /ldap:\s*\{([\s\S]*?)\\tsso:\s*\{/.exec(template);
+if (!ldapBlockMatch) {
+	console.error('check_jump_ldap_tls: could not find the ldap: {...} block in the jump-secrets.js template.');
+	process.exit(1);
+}
+const ldapBlock = ldapBlockMatch[1];
+
+const hasTlsOptions = /tlsOptions\s*:/.test(ldapBlock);
+const urlMatch = /url:\s*'([^']+)'/.exec(ldapBlock);
+const url = urlMatch ? urlMatch[1] : null;
+
+if (!url) {
+	console.error('check_jump_ldap_tls: no url found in the ldap block.');
+	process.exit(1);
+}
+
+if (hasTlsOptions && !url.startsWith('ldaps://')) {
+	console.error(
+		`check_jump_ldap_tls: jump-secrets.js template sets tlsOptions but url is "${url}" (not ldaps://). ` +
+		'This is the exact bug that broke every SSH login to jump-host -- see the comment above this check.'
+	);
+	process.exit(1);
+}
+
+console.log(`check_jump_ldap_tls: OK (url=${url}, tlsOptions=${hasTlsOptions})`);