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>
v1.29.0: jump host is core + fix fresh-install setup.sh abort (#125 )
2026-08-01 18:46:10 -04:00 · 2026-08-01 13:48:28 -04:00 · 2026-08-01 12:55:32 -04:00 · 2026-08-01 12:54:56 -04:00 · 2026-08-01 11:14:39 -04:00 · 2026-08-01 11:13:51 -04:00
27 changed files with 1833 additions and 315 deletions
@@ -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.
@@ -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
@@ -5,8 +5,12 @@
 config/
 backups/
-# Legacy .env / proxy.env (no longer used — config is in ./config/). Still
+# .env: NOT app config (that's ./config/, generated by setup.sh) — this is
-# ignored in case a migrated deployment hasn't deleted them yet.
+# 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
@@ -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
@@ -2,14 +2,619 @@
 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
@@ -71,14 +676,14 @@ 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-env stack
+`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-env side.
+No `setup.sh`, compose, or config change on the theta-suite side.
 ## [1.5.0] - 2026-07-26
@@ -132,7 +737,7 @@ sso-manager-node 1.5.0:
 - `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-env 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.
+- 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:
@@ -155,7 +760,7 @@ proxy 1.4.0:
 - 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-env 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.
+- 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:
@@ -178,7 +783,7 @@ jump-host 1.3.0:
 - `#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-env 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.
+- 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
@@ -276,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.
@@ -357,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
@@ -387,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`.
@@ -431,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.
@@ -571,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
@@ -607,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)
@@ -642,23 +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.4.0...HEAD
+[Unreleased]: https://github.com/theta42/theta-suite/compare/v1.4.0...HEAD
-[1.4.0]: https://github.com/theta42/theta-env/compare/v1.3.7...v1.4.0
+[1.4.0]: https://github.com/theta42/theta-suite/compare/v1.3.7...v1.4.0
-[1.1.17]: https://github.com/theta42/theta-env/compare/v1.1.16...v1.1.17
+[1.1.17]: https://github.com/theta42/theta-suite/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.16]: https://github.com/theta42/theta-suite/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.15]: https://github.com/theta42/theta-suite/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.14]: https://github.com/theta42/theta-suite/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.13]: https://github.com/theta42/theta-suite/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.12]: https://github.com/theta42/theta-suite/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.11]: https://github.com/theta42/theta-suite/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.10]: https://github.com/theta42/theta-suite/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.9]: https://github.com/theta42/theta-suite/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.8]: https://github.com/theta42/theta-suite/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.7]: https://github.com/theta42/theta-suite/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.6]: https://github.com/theta42/theta-suite/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.5]: https://github.com/theta42/theta-suite/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.4]: https://github.com/theta42/theta-suite/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.3]: https://github.com/theta42/theta-suite/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.2]: https://github.com/theta42/theta-suite/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.1]: https://github.com/theta42/theta-suite/compare/v1.1.0...v1.1.1
-[1.1.0]: https://github.com/theta42/theta-env/releases/tag/v1.1.0
+[1.1.0]: https://github.com/theta42/theta-suite/releases/tag/v1.1.0
@@ -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);
+All four load their secrets from OpenBao at boot; `setup.sh` automates the
-this repo just composes them and automates the first-run glue so they find each
+first-run glue so they find each other and the secrets store.
 other.
-**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
+## Configuration
-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
+`setup.sh` automates the first-run glue between subprojects:
-config fields or logins silently fail with `Invalid Credentials`. Doing that by
+- Asks for your domain once (in `setup.env`) and fills it in across all config files.
-hand is fiddly and easy to get wrong. `setup.sh` asks for your domain once (in
+- Registers the proxy as an OIDC client of the SSO.
-`setup.env`), generates both config files with it filled in everywhere, registers
+- 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.
-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.
+**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
+- **636** (LDAPS) — for direct-LDAP clients on other machines (Linux hosts
-  directly over the network. The proxy itself reaches LDAP over the internal
+  via PAM/SSSD, LDAP-native apps). The proxy itself reaches LDAP over the
-  Docker network, so you do **not** need to expose 636 for the stack to work.
+  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
+git clone --recursive https://github.com/theta42/theta-suite.git
-cd theta-env
+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),
+Secrets live in **OpenBao** (a Vault fork, container `openbao:8200` on
-read by each app's `@simpleworkjs/conf` via the `CONF_SECRETS` env var, which
+`theta-net`), the single authoritative store. Each app loads them at boot with
-the entrypoint points at the mounted file:
+[@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
+domain is entered — see *Quickstart*) with random secrets, seeds them into
-`.env` / `proxy.env`** — edit `./config/*.js` directly. Compose only interpolates
+OpenBao, and mints scoped per-app tokens (`SSO_VAULT_TOKEN` /
-port defaults (`SSO_PORT`, `HTTP_PORT`, etc.), which you can override on the
+`PROXY_VAULT_TOKEN` / `JUMP_VAULT_TOKEN`) into `./.env`. There is **no
-command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See `config.example/` for the
+`.env` / `proxy.env`** for app config — edit `./config/*.js` directly (and
-full annotated shape, and each submodule's `secrets.js.example`.
+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
+- **Direct LDAP for LDAP-native clients and Linux hosts**: bind to
-  `cn=admin,<base>` (admin) or `cn=ldapclient,ou=people,<base>` (read-only
+  `ldaps://<host>:636` as `cn=admin,<base>` (admin) or
-  service account the bootstrap created). Use LDAPS, not plain LDAP.
+  `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)
@@ -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) {
@@ -230,7 +275,7 @@ async function listClients(token) {
 }
 async function createClient(token, opts) {
-	const o = opts || { name: CLIENT_NAME, description: 'theta-env proxy (auto-registered)', redirect_uris: [REDIRECT_URI] };
+	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' },
@@ -334,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
@@ -419,10 +464,11 @@ async function seedDirectory(token, clientId) {
 		subType: 'openresty',
 	});
-	// Optional SSH jump host service.
+	// SSH jump host service (core component — always registered).
-	if (/^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '')) {
+	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',
@@ -430,19 +476,21 @@ async function seedDirectory(token, clientId) {
 		});
 	}
-	// Link the proxy's OAuth client (Resource-backed since sso-manager 1.3.0)
+	// Link an OAuth client (Resource-backed since sso-manager 1.3.0) under its
-	// under its service, if it appears in the directory and isn't linked yet.
+	// owning service, if it appears in the directory and isn't linked yet.
-	if (clientId) {
+	async function linkOauthClient(id, parent, label) {
-		const oauthRes = resources.find((r) => r.id === clientId);
+		if (!id || !parent) return;
-		if (oauthRes) {
+		const oauthRes = resources.find((r) => r.id === id);
-			const edges = ((await dirGet(token, 'edges')).results) || [];
+		if (!oauthRes) return;
-			const linked = edges.some((e) => e.childId === clientId);
+		const edges = ((await dirGet(token, 'edges')).results) || [];
-			if (!linked) {
+		const linked = edges.some((e) => e.childId === id);
-				await dirPost(token, 'edges', { parentId: psvc.id, childId: clientId, relation: 'oauth' });
+		if (!linked) {
-				log(`  directory: linked OAuth client under 'proxy'`);
+			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
@@ -475,16 +523,16 @@ function writeProxyCreds(id, secret) {
 	}
 }
-// ── 6. Optional: provision the SSH jump host ────────────────────────────────
+// ── 6. Provision the SSH jump host ─────────────────────────────────────────
-// When CFG_JUMP_HOST_ENABLED=true, the jump host needs: a directory API token
+// The jump host is a core component (always provisioned). It needs: a directory
-// (to resolve which hosts a user may reach), an LDAP bind account that can
+// API token (to resolve which hosts a user may reach), an LDAP bind account
-// WRITE the sshPublicKey attribute (it injects its own key on first use), and
+// that can WRITE the sshPublicKey attribute (it injects its own key on first
-// a config file it reads. We write /config/jump-secrets.js deriving LDAP/site
+// use), and a config file it reads. We write /config/jump-secrets.js deriving
-// from sso-secrets.js + a freshly minted API token. The bundled jump host
+// LDAP/site from sso-secrets.js + a freshly minted API token. The bundled jump
-// binds as cn=admin (already able to write sshPublicKey) — hardened bare-metal
+// host binds as cn=admin (already able to write sshPublicKey) — hardened
-// deployments should use a scoped account + attribute ACL instead (see the
+// bare-metal deployments should use a scoped account + attribute ACL instead
-// jump-host README). Idempotent: skips if the file already has a real token.
+// (see the jump-host README). Idempotent: skips if the file already has a real
-const JUMP_ENABLED = /^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '');
+// 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';
@@ -495,7 +543,7 @@ 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();
@@ -520,14 +568,23 @@ 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}`)},
@@ -573,10 +630,17 @@ 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 (jumpFileComplete()) {
 		log('Jump host: /config/jump-secrets.js already has API token + OIDC client — keeping.');
-		return;
+		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);
@@ -589,7 +653,7 @@ async function provisionJumpHost(token) {
 	} else {
 		oidc = await createClient(token, {
 			name: JUMP_CLIENT_NAME,
-			description: 'theta-env jump host web UI (auto-registered)',
+			description: 'theta-suite jump host web UI (auto-registered)',
 			redirect_uris: [JUMP_REDIRECT_URI],
 		});
 	}
@@ -598,6 +662,7 @@ async function provisionJumpHost(token) {
 	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() {
@@ -643,22 +708,37 @@ async function provisionJumpHost(token) {
 			resolvedClientId = id;
 		}
-		// Provision the jump host (mint token + write config) when enabled.
+		// Mirror the (now-current) proxy-secrets.js into OpenBao so the proxy
-		// Warn-only — never fail the whole bring-up over the optional service.
+		// loads it from there at boot via @simpleworkjs/bao-conf. Re-require
-		if (JUMP_ENABLED) {
+		// fresh: writeProxyCreds rewrote the file out from under the cached
-			try {
+		// `proxy` object. setup.sh's seed already put a placeholder version
-				await provisionJumpHost(token);
+		// here; this replaces it with the complete file (operator edits +
-				out('JUMP_HOST_CONFIGURED', '1');
+		// generated OAuth creds). Warn-only.
-			} catch (e) {
+		await baoPut('proxy/conf', freshRequire('/config/proxy-secrets.js'));
-				log(`WARNING: jump host provisioning failed (${e.message || e}) — continuing`);
+
-			}
+		// 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`);
 		}
@@ -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" )
@@ -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
@@ -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: {
@@ -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
+      # Config (LDAP, OAuth, SMTP, ...) is loaded by @simpleworkjs/conf from
-      # volumes below), not from env. NODE_ENV/NODE_PORT are the only env the app
+      # ./config/sso-secrets.js (see volumes), then @simpleworkjs/bao-conf
-      # reads that are not part of its conf tree.
+      # 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),
+      # oidc/ldap/auth config is loaded by @simpleworkjs/conf from
-      # not from env. NODE_ENV/NODE_PORT are process env the app reads directly.
+      # ./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
+  # SSH jump host — a core component, always built + started alongside the
-  # is active — setup.sh exports COMPOSE_PROFILES=jump-host when
+  # SSO and proxy. Authenticates users against the SSO's OpenLDAP, resolves
-  # CFG_JUMP_HOST_ENABLED=true. Authenticates users against the SSO's OpenLDAP,
+  # reachable hosts from the directory API, and bridges SSH through.
  # 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:
@@ -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
+  repository_url: https://github.com/theta42/theta-suite
-  zip_url: https://github.com/theta42/theta-env/archive/refs/heads/master.zip
+  zip_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.zip
-  tar_url: https://github.com/theta42/theta-env/archive/refs/heads/master.tar.gz
+  tar_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.tar.gz
-  repository_name: theta42/theta-env
+  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:
@@ -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
+theta-suite is a **composition** repo: it builds four applications from their
-their git submodules and adds the glue that wires them together. It does not
+git submodules and adds the glue that wires them together — plus a shared
-fork or patch them — both projects work unchanged on their own.
+[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`
+The four applications are pinned as **git submodules**; OpenBao uses the
-fetches all three in one step; `git submodule update --remote` bumps them.
+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 / direct LDAP clients     │
+          │ browser / OIDC apps │ SSH clients │ Linux hosts            │
-            └───────────────┬──────────────────────────────┘
+          │                     │             │ (PAM/SSSD, sudo, keys)  │
-                            │ https (:443)        ldaps (:636)
+          └────────┬────────────┴──────┬──────┴───────────┬───────────┘
-                  ┌─────────▼─────────┐
+            https (:443)          ssh (:2222)        ldaps (:636)
-                  │  proxy container  │  OpenResty :80/:443/:4443
+                  │                     │                  │
-                  │  (OIDC + LDAP)    │  Node mgmt app :3000 (localhost only)
+         ┌────────▼────────┐  ┌──────────▼────────┐         │
-                  │                   │  bundled Redis (127.0.0.1:6379)
+         │  proxy           │  │  jump-host        │         │
-                  └─────────┬─────────┘
+         │  OpenResty       │  │  sshd :2222       │         │
-              ┌─────────────┼────────────────────────────┐
+         │  :80/:443/:4443  │  │  web UI :3002     │         │
-              │ ldaps:636   │ http:3001 (internal)       │  OIDC token + userinfo
+         │  mgmt app :3000  │  └────────┬──────────┘         │
-              │ (docker net)│ (docker net, not published)│  (server-to-server)
+         └────────┬─────────┘           │ OIDC + LDAP        │
-              ▼             ▼                           │
+                  │ http:3001 (internal)│ via sso-manager    │
-      ┌──────────────────────────────┐                   │
+                  ▼                     ▼                    ▼
-      │  sso-manager container       │◄──────────────────┘
+        ┌───────────────────────────────────────────────────────┐
-      │  OIDC provider (Express)     │  bundled Redis (127.0.0.1:6379)
+        │  sso-manager   (Express + OpenLDAP + Redis)            │
-      │  OpenLDAP (slapd)            │  web UI :3001 (localhost only)
+        │  OIDC provider + LDAP directory                         │
-      │  ldaps :636 (published)      │
+        │  web UI :3001 (internal)   ldaps :636 (published)       │
-      └───────────────────────────────┘
+        └───────────────────────────────────────────────────────┘
-            ▲
+                          ▲  loads secrets at boot (scoped token each)
-            │ ldaps :636 (published to host) — legacy apps bind directly
+              ┌───────────┴───────────────────┐
-            │
+              │  openbao   (KV-v2 at secret/)  │  ← central secrets store
-      ┌──────────────────────────────┐
+              │  :8200 (internal)             │     per-user + per-app KV
-      │  legacy apps (Gitea, Emby, …)│
+              │  :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`
+All four services bundle their **own Redis** (sso-manager, proxy, jump-host
-in three places that ignore config; the SSO's models default to the same). Two
+each run a 127.0.0.1:6379 instance) and share the `openbao` secrets store.
-redis instances is the no-source-patch path and is fine at this scale.
+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 |
+| Port | Service | On host? | Purpose |
-|------|----------|---------|
+|------|---------|----------|---------|
-| `443` (proxy) | **yes** | the public entry point — OIDC login + proxied apps + the SSO/proxy UIs |
+| `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) |
+| `80` | proxy | **yes** | HTTP-01 for Let's Encrypt (and redirect to 443) |
-| `4443` (proxy) | yes (optional) | alt HTTPS listener |
+| `4443` | proxy | yes (optional) | alt HTTPS listener |
-| `3000` (proxy) | localhost only | proxy mgmt UI/API (first-run convenience; fronted by 443 normally) |
+| `3000` | proxy | localhost/LAN | proxy mgmt UI/API (fronted by 443 normally) |
-| `636` (sso) | yes | LDAPS for legacy direct-LDAP clients |
+| `3001` | sso-manager | localhost/LAN | SSO web UI (fronted by the proxy normally) |
-| `3001` (sso) | localhost only | SSO web UI (first-run convenience; fronted by the proxy normally) |
+| `636` | sso-manager | **yes** | LDAPS for direct-LDAP clients (Linux hosts, LDAP-native apps) |
-| `389` (sso) | **no** | plain LDAP — internal only (app↔slapd over localhost) |
+| `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`**
+   bootstrap writes the generated creds **back into `./config/proxy-secrets.js`
-   (the sso-manager mounts `./config` read-write for this; the proxy mounts it
+   and into OpenBao at `secret/proxy/conf`** (the sso-manager mounts `./config`
-   read-only). If `proxy-secrets.js` already holds a `clientId`+`clientSecret`
+   read-write for this; the proxy mounts it read-only). If `proxy-secrets.js`
-   matching an existing client, they are kept; if the client exists but the file
+   already holds a `clientId`+`clientSecret` matching an existing client, they
-   has no usable secret, the secret is rotated and written back.
+   are kept; if the client exists but the file has no usable secret, the
-6. **Build + start the proxy**, wait for `/health`. The proxy entrypoint points
+   secret is rotated and written back.
-   `CONF_SECRETS` at `./config/proxy-secrets.js`, so `@simpleworkjs/conf`
+6. **Build + start the proxy + jump-host**, wait for `/health`. Each
-   (≥1.2.0) reads the OAuth creds + LDAP bind creds from the file.
+   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
+Config and secrets live in two layers: an operator-edited
-entrypoint points the `CONF_SECRETS` env var (`@simpleworkjs/conf` >= 1.2.0)
+`./config/*-secrets.js` file (gitignored, bind-mounted) and the OpenBao
-at its file early, before the app starts:
+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
+env`, where **env beats the secrets file**. Then `@simpleworkjs/bao-conf`
-vars** (only `NODE_ENV`, `NODE_PORT`) — that makes the secrets file
+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`)
+default 5). State lives on named volumes (`ldap-data`, `ldap-certs`,
-and survives recreation; `down -v` wipes them. Redis is persisted with AOF +
+`sso-data`, `proxy-data`, `proxy-cache`, `proxy-logs`, `jump-data`,
-RDB on those volumes. For the full manual-backup + restore runbook (full /
+`jump-redis-data`, `openbao-data`) and survives recreation; `down -v` wipes
-Redis-only / LDAP-only, with the AOF-vs-RDB note), see the *Backups and
+them. Redis is persisted with AOF + RDB on those volumes. For the full
-restore* section of the [README](https://github.com/theta42/theta-env#backups-and-restore).
+manual-backup + restore runbook (full / Redis-only / LDAP-only, with the
-Quick LDAP backup:
+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
@@ -4,20 +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
+The whole theta42 identity, access, and secrets stack in one repo, brought up
-single command — for home labs and small businesses.
+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
+LDAP directory), [Proxy](https://theta42.github.io/proxy/) (an OIDC-protected
-OIDC-protected reverse proxy that can also look users up directly in LDAP) —
+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
+[Jump Host](https://theta42.github.io/jump-host/) (directory-driven SSH access
-SSO and pointing it at the right LDAP directory, with hostnames and secrets
+through one public entry point), and
-generated from one `setup.env`. An optional third component, the
+[ldap-client](https://theta42.github.io/ldap-client/) (enrolls your Linux
-[Jump Host](https://theta42.github.io/jump-host/), adds directory-driven SSH
+hosts into the directory for PAM/SSSD, sudo, and SSH keys). All of them read
-access to your machines through one public entry point.
+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
@@ -31,9 +35,9 @@ The SSO Manager and the proxy it fronts, both stood up by one `./setup.sh` run:
 ## Why this over running them separately
-Each project works standalone, but they only become useful together once the
+The components are designed to integrate — they're only useful together once
-proxy is registered as an OIDC client of the SSO *and* pointed at the SSO's
+the proxy is registered as an OIDC client of the SSO *and* pointed at the
-LDAP directory — and the domain has to match across half a dozen config
+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
@@ -46,9 +50,16 @@ snapshots state before every rebuild.
 - **Proxy** — add the hosts you want to protect with OIDC login.
 - **LDAPS** for direct binds — Linux hosts (PAM/SSSD, sudo, SSH keys) and
  LDAP-native apps authenticate against the same directory.
- **SSH Jump Host** *(optional)* — `ssh uid_-_host@jump.<domain>` (WinSCP-friendly)
+- **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. Enable with `CFG_JUMP_HOST_ENABLED=true`.
+  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.
@@ -57,8 +68,8 @@ snapshots state before every rebuild.
 ## Get it
 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
+git clone --recursive https://github.com/theta42/theta-suite.git
-cd theta-env
+cd theta-suite
 cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your domain
 ./setup.sh
 ```
@@ -66,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
@@ -74,5 +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 optional SSH jump
+- **[Jump Host](https://theta42.github.io/jump-host/)** — the SSH jump
-  host this stack can bring up (`CFG_JUMP_HOST_ENABLED=true`).
+  host this stack brings up.
 - **[ldap-client](https://theta42.github.io/ldap-client/)** — enrolls Linux
  hosts into the directory this stack serves.
@@ -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
+git clone --recursive https://github.com/theta42/theta-suite.git
-cd theta-env
+cd theta-suite
 ```
 `--recursive` fetches the two submodules (`sso-manager-node`, `proxy`) in one
@@ -60,8 +60,7 @@ 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_ENABLED` | `true` | optional: bring up the [SSH jump host](https://theta42.github.io/jump-host/) (default off) |
+| `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) |
 | `CFG_JUMP_HOST` | `jump.lab.local` | optional, defaults to `jump.<domain>` |
 | `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
@@ -144,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 \
@@ -165,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
@@ -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
@@ -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.
@@ -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
+> **The integrated stack is the supported path.** `./setup.sh` wiring all four
-own. The submodules in this repo are normal clones; you can also clone them
+> components together around a shared OpenBao secrets store is what's tested and
-directly from GitHub.
+> 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
+If you have a specific reason to run the components on separate hosts instead
-documented in both projects' deployment guides:
+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
+`./setup.sh` exists to do all of this for you — and to add the OpenBao secrets
-do them by hand (or want the two on separate hosts), follow the standalone
+store, jump host, and ldap-client on top. Unless you need the components on
-guides above.
+separate hosts, prefer the integrated stack.
 [← Back to Home](index.html)
@@ -1 +1 @@
-https://github.com/theta42/theta-env/pull/75
+https://github.com/theta42/theta-suite/pull/75
@@ -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 ───────────────────────────────────────────────────
+# ── SSH jump host (always installed) ─────────────────────────────────────────
-# Enable the theta42/jump-host component: a public SSH jump host that
+# The theta42/jump-host component is installed and started by default — a
-# authenticates users against the directory and bridges them to downstream
+# public SSH jump host that authenticates users against the directory and
-# hosts (ssh uid_-_target@jump, or an interactive picker). Off by default.
+# bridges them to downstream hosts (ssh uid_-_target@jump, or an interactive
-# When true, setup.sh clones/builds the jump-host submodule, the bootstrap
+# picker). setup.sh clones/builds the jump-host submodule, the bootstrap mints
-# mints its directory API token + writes ./config/jump-secrets.js, and it's
+# its directory API token + writes ./config/jump-secrets.js, and it's registered
-# registered in the proxy + directory. See jump-host's README for the LDAP
+# in the proxy + directory. See jump-host's README for the LDAP write-ACL note
-# write-ACL note (the bundled deployment binds as cn=admin).
+# (the bundled deployment binds as cn=admin).
 #CFG_JUMP_HOST_ENABLED=false
 #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
@@ -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..."
+			info "Updated theta-suite (${BEFORE_VER} -> ${AFTER_VER}) — restarting setup.sh with the new version..."
-			THETA_ENV_REEXECED=1 exec "$0" "$@"
+			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 ─────────────────────────
+# ── Jump host hostname (always installed) ─────────────────────────────────────
-# CFG_JUMP_HOST_ENABLED gates the optional SSH jump host (a third submodule).
+# The SSH jump host is a core component — always built + started (no longer
-# Read it from the environment or ./setup.env now (before the submodule loop
+# gated by CFG_JUMP_HOST_ENABLED). Read its optional hostname override from
-# and the compose steps) so every run knows whether to build/start it. The
+# ./setup.env now (before the submodule loop and the compose steps) so the
-# authoritative CFG_* for secrets are still resolved in ensure_config; this is
+# later steps can use it. The authoritative CFG_* for secrets are still
-# only the on/off switch + its hostname.
+# resolved in ensure_config; this is only the hostname override.
 [[ -f ./setup.env ]] && parse_kv_file ./setup.env
-JUMP_ENABLED=0
+export CFG_JUMP_HOST
-case "${CFG_JUMP_HOST_ENABLED:-}" in 1|true|TRUE|yes|YES) JUMP_ENABLED=1 ;; esac
+
-export CFG_JUMP_HOST_ENABLED CFG_JUMP_HOST
+# ── Optional outbound HTTP(S) proxy for docker build + the running containers ─
-# When enabled, activate the compose profile so `up`/`ps` include the service.
+# CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY (from ./setup.env or the
-if [[ "$JUMP_ENABLED" == "1" ]]; then export COMPOSE_PROFILES="jump-host"; fi
+# 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.
+	# jump-host is a core component — always tracked + built.
-	SUBMODULES=(sso-manager-node proxy)
+	SUBMODULES=(sso-manager-node proxy jump-host)
 	[[ "$JUMP_ENABLED" == "1" ]] && SUBMODULES+=(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 ─────────────────────────────
+# ── 7b. Build + start the SSH jump host ──────────────────────────────────────
-# Enabled by CFG_JUMP_HOST_ENABLED. The bootstrap (step 5) already wrote
+# The jump host is a core component (no longer optional). The bootstrap (step 5)
-# ./config/jump-secrets.js (minted API token + LDAP admin bind). Build/start the
+# already wrote ./config/jump-secrets.js (minted API token + LDAP admin bind) and
-# service (compose profile 'jump-host' is active), wait for its web /health, and
+# mirrored it into OpenBao. Build/start the service, wait for its web /health,
-# register its web UI hostname as a proxy Host so https://<JUMP_HOST> routes.
+# 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_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
+JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
-	JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
+export JUMP_GIT_COMMIT
-	export JUMP_GIT_COMMIT
+env_upsert JUMP_GIT_COMMIT "$JUMP_GIT_COMMIT"
-	info "Building + starting jump-host (optional; enabled via CFG_JUMP_HOST_ENABLED)..."
+# Seed jump-host/conf from the file bootstrap just wrote (it mints the API
-	"${COMPOSE[@]}" up -d --build jump-host
+# 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..."
+info "Waiting for jump-host to be healthy..."
-	for i in $(seq 1 60); do
+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
+	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
+		info "jump-host is healthy."; break
-		fi
+	fi
-		if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
+	if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
-		sleep 2
+	sleep 2
-	done
+done
-	info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
+info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
-	JUMP_HOSTS_OUT=$("${COMPOSE[@]}" exec -T proxy node <<NODEEOF || true
+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] /'
+echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'
 fi
 # ── 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}"
@@ -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
@@ -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})`);
Author	SHA1	Message	Date
wmantly	3287777b9b	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>	2026-08-01 18:46:10 -04:00
wmantly	5ef3e3fa8c	v1.29.0: jump host is core + fix fresh-install setup.sh abort (#125 ) Two fresh-install fixes and promote the SSH jump host from opt-in to core. setup.sh: fix silent abort after "Minting per-app OpenBao tokens". env_get's grep\|cut pipeline returns non-zero under set -euo pipefail when .env exists (created by the root VAULT_TOKEN env_upsert) but an app-token key is absent (the normal first-run state); the unguarded existing assignment from env_get then tripped set -e and killed the script before minting any token. env_get now always returns 0 (\|\| true). Reproduced + verified under the exact condition. jump host is no longer optional: - docker-compose.yml: drop profiles jump-host from the jump-host service (always started); rename the opt-in test fixture profile jump-host to ldap-test. - setup.sh: SUBMODULES always includes jump-host; build/start/register/summary no longer guarded by JUMP_ENABLED; drop the COMPOSE_PROFILES export. - bootstrap.js: jump provisioning + directory record run unconditionally. - setup.env.example/docs: drop optional/CFG_JUMP_HOST_ENABLED wording. Co-authored-by: Claude <noreply@anthropic.com>	2026-08-01 13:48:28 -04:00
wmantly	a1ea2d458e	Merge pull request #124 from theta42/feature/openbao-secrets v1.28.0: OpenBao as the central secrets store for the stack	2026-08-01 12:55:32 -04:00
wmantly	f7df04c2f0	v1.28.0: OpenBao as the central secrets store for the stack theta-env orchestration: - setup.sh: idempotent OpenBao policies (sso-broker, sso-admin, proxy, jump-host), sso-broker token role (allowed_policies_glob user-/app-, 24h), mint scoped SSO/PROXY/JUMP_VAULT_TOKEN (orphan, .env reuse), seed_app_conf seeds secret/{sso-manager,proxy,jump-host}/conf. Bootstrap exec passes root VAULT_ADDR/VAULT_TOKEN for seeding. Root token never reaches a service container. shellcheck -S warning clean. - docker-compose.yml: VAULT_ADDR + VAULT_TOKEN env for sso/proxy/jump; proxy/jump depends_on openbao service_started. - bootstrap/bootstrap.js: baoPut() writes generated OAuth creds to secret/proxy/conf + secret/jump-host/conf (OpenBao authoritative). - docs/secrets.md (new): full secrets architecture. README + nav updated. Submodule bumps: - sso-manager-node -> v1.16.0 (OpenBao broker + vault UI + remediation) - proxy -> v1.13.1 (via v1.13.0: OpenBao boot) - jump-host -> v1.14.1 (via v1.14.0: OpenBao boot) - ldap-client unchanged Co-Authored-By: Claude <noreply@anthropic.com>	2026-08-01 12:54:56 -04:00
wmantly	3277972037	Merge pull request #123 from theta42/release-v1.27.2 Release v1.27.2	2026-08-01 11:14:39 -04:00
wmantly	0c7593cc59	Bump proxy to v1.12.1	2026-08-01 11:13:51 -04:00
wmantly	ec625f7cb0	Merge pull request #122 from theta42/release-v1.27.1 Release v1.27.1	2026-08-01 10:27:38 -04:00
wmantly	2a6c7775c9	Bump sso-manager-node to v1.15.2, add integration tests	2026-08-01 10:26:59 -04:00
wmantly	010ff037ce	Merge pull request #121 from theta42/release-v1.27.0 Release v1.27.0	2026-08-01 02:45:44 -04:00
wmantly	f8f1961b30	Bump sso-manager-node to v1.15.0 and update CHANGELOG for v1.27.0	2026-08-01 02:44:50 -04:00
wmantly	49dee5c477	Merge pull request #120 from theta42/release-v1.26.0 Release v1.26.0: OpenBao production ready	2026-08-01 02:18:03 -04:00
wmantly	1a832d068e	Fix shellcheck warning SC2155	2026-08-01 02:17:29 -04:00
wmantly	60ae421cb2	Release v1.26.0: OpenBao production ready	2026-08-01 02:16:33 -04:00
wmantly	90e95bfece	Merge pull request #119 from theta42/release-v1.25.0 Release v1.25.0	2026-08-01 01:41:00 -04:00
wmantly	144e97d0e1	Release v1.25.0	2026-08-01 01:40:28 -04:00
wmantly	9dc2de7818	Merge pull request #118 from theta42/release/v1.24.0 Release v1.24.0 - UI polish across all components	2026-07-31 14:45:03 -04:00
wmantly	a959b331ae	Release v1.24.0 - UI polish across all components Bumps submodules to their latest releases: - jump-host v1.13.0: Title changed to 'SSO Manager', TUI picker with ANSI colors - sso-manager-node v1.13.0: Profile/catalog page redesign, SSH key column fix - proxy v1.11.0: Table-based list views, auto-refresh groups	2026-07-31 14:43:56 -04:00
wmantly	b64083f008	Merge pull request #117 from theta42/release/v1.23.0 Release v1.23.0 - UI polish across all components	2026-07-31 14:08:45 -04:00
wmantly	a2fa7a7fc7	Release v1.23.0 - UI polish across all components Bumps submodules to their latest releases: - jump-host v1.13.0: Title changed to 'SSO Manager' - sso-manager-node v1.13.0: Directory page cleanup, users list key column fix - proxy v1.11.0: Table-based list views, auto-refresh groups	2026-07-31 14:08:00 -04:00
wmantly	6d6aea6011	Merge pull request #116 from theta42/release/v1.22.0 Release v1.22.0 - UI enhancements across all components	2026-07-31 14:01:31 -04:00
wmantly	43e3c79880	Release v1.22.0 - UI enhancements across all components Bumps submodules to their latest releases: - jump-host v1.12.0: TUI picker colors, dashboard/audit page styling - sso-manager-node v1.12.0: Profile page tabs, catalog page redesign - proxy v1.10.0: Table-based list views, form validation improvements	2026-07-31 13:52:13 -04:00
wmantly	8b549c3315	Release v1.22.0 - UI enhancements across all components Bumps submodules to their latest releases: - jump-host v1.12.0: TUI picker colors, dashboard/audit page styling - sso-manager-node v1.12.0: Profile page tabs, catalog page redesign - proxy v1.10.0: Table-based list views, form validation improvements Full changelog entries embedded in each submodule.	2026-07-31 12:57:57 -04:00
wmantly	f25a684eb2	Merge pull request #115 from theta42/release/1.21.0 Release 1.21.0: sso-manager-node v1.11.0, ldap-client v1.1.1	2026-07-31 01:31:25 -04:00
wmantly	87d06441c7	Release 1.21.0: sso-manager-node v1.11.0, ldap-client v1.1.1 Bumps the SSO to the release that closes the end-user half of the directory (catalog, self-service access requests, admin access visibility) and adds nested LDAP groups, and ldap-client to the release that makes SSSD resolve that nesting on hosts pointed at a server without the nestgroup overlay. Operational note: the SSO image now compiles OpenLDAP from a pinned master commit, because nestgroup exists only on master -- no 2.6.x release ships it. That makes the image slower to build, and master's LMDB 1.0.0 cannot read the 0.9.x on-disk format from 2.6.x (or vice versa), so moving an existing /var/lib/ldap onto this image is a slapcat/slapadd reload rather than a restart. There is a TODO to drop the from-source stage once nestgroup ships in a release; the entrypoint already probes for it and the app keys off app_ldap__nestedGroupsServerSide, so that swap needs no other changes. jump-host and proxy pointers are deliberately unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 01:30:32 -04:00
wmantly	cf1591cdaa	Merge pull request #114 from theta42/release/1.20.0 Release 1.20.0: bump submodules for cross-app super admin; persist GIT_COMMIT to .env	2026-07-30 12:08:25 -04:00
wmantly	d4154cfec6	Release 1.20.0: bump submodules for cross-app super admin; persist GIT_COMMIT to .env - Bump jump-host, ldap-client, proxy, sso-manager-node submodules to their new tags (cross-app app_super_admin group, jump-host's app_jump_admin, ldap-client's SSH host access for super admins). - setup.sh: new env_upsert helper persists SSO_GIT_COMMIT/PROXY_GIT_COMMIT/ JUMP_GIT_COMMIT into ./.env (docker compose's auto-loaded env file) so an ad-hoc single-service rebuild outside a full setup.sh run still bakes the right commit hash instead of "unknown".	2026-07-30 12:07:12 -04:00
wmantly	6e411160a6	Merge pull request #113 from theta42/release/1.19.0 Release 1.19.0: bump submodules, add ldap-test-host fixture	2026-07-30 09:54:15 -04:00
wmantly	e25d112787	Release 1.19.0: bump submodules, add ldap-test-host fixture sso-manager-node -> v1.9.0, proxy -> v1.8.0, jump-host -> v1.10.2, ldap-client -> v1.0.0 (new)	2026-07-30 09:53:39 -04:00
wmantly	3b5f3423c8	Merge pull request #112 from theta42/feat/jump-host-test-fixture Add ldap-test-host: a real LDAP-joined downstream host for testing jump-host	2026-07-30 09:48:39 -04:00
wmantly	084c8fdfb3	Add ldap-test-host: a real LDAP-joined downstream host for testing jump-host New optional service (jump-host compose profile) built from the new theta42/ldap-client submodule: a genuinely SSSD + AuthorizedKeysCommand LDAP-joined host, not a container with a manually-dropped public key in authorized_keys. Lets jump-host's actual key-injection -> upstream-connect flow be exercised end-to-end against the local dev stack's own LDAP. Verified: real SSH login through jump-host's uid_-_target grammar, live key injection into LDAP, and ldap-test-host serving that key via AuthorizedKeysCommand -- both via the SSH CLI and WinSCP. config.example/ldap-test-host.vars.example documents the one field an operator fills in (the ldapclient service account's bind password, already generated by bootstrap.js as serviceAccountPass) -- the rest points at this stack's own local LDAP by default.	2026-07-30 09:47:54 -04:00
wmantly	f2e924bf58	Merge pull request #111 from theta42/release/1.18.0 Release 1.18.0: bump submodules for API-token UI unification	2026-07-28 21:28:33 -04:00
wmantly	7c0fbd959f	Release 1.18.0: bump submodules for API-token UI unification sso-manager-node -> v1.8.3, proxy -> v1.7.0, jump-host -> v1.10.1	2026-07-28 21:27:59 -04:00
wmantly	e1cb855529	Bump sso-manager-node to v1.8.1, proxy to v1.6.0 (#110 ) Host modal standardization (tabs onto app.modal, footer, linkable URL) plus two DOM-rebuild-timing autocomplete-datalist bugs fixed in both apps.	2026-07-28 19:10:33 -04:00
wmantly	51e9e5e42f	Bump jump-host to v1.9.0 (Quick Jump UI, audit failDetail) (#109 )	2026-07-28 18:17:56 -04:00
wmantly	e27439e491	Persist Directory data (Resource/site/host/service/oauth) + bump sso-manager-node to v1.8.0 (#108 ) sso-manager's Directory data had no persistent volume at all: @simpleworkjs/orm falls back to './config/inventory.sqlite' (relative to /app) when conf.orm isn't set, which lives in the container's ephemeral layer -- every container recreate silently wiped every site/host/service/oauth-client resource and their relationships. setup.sh's generated sso-secrets.js now sets orm.storage=/data/inventory.sqlite, co-located with the already-persisted sso-data volume (same one Redis uses). Verified live: migrated the running stack's existing Directory data to /data, force-recreated the container, and confirmed all 8 resources survived. Also bumps sso-manager-node to v1.8.0 (resource modal standardization: tabs, footer with created/updated-by metadata, linkable /directory/:slug URLs, a new Children tab, and site-slug-prefixed auto-created LDAP groups).	2026-07-28 17:51:08 -04:00
wmantly	cf8c5c9a04	Bump jump-host to v1.8.1 (#107 )	2026-07-28 15:58:42 -04:00
wmantly	c7c0aa8cf5	Persist jump-host's Redis data across rebuilds (#106 ) Companion to theta42/jump-host#18: that PR turns on Redis persistence (AOF + RDB) at /data, but without a volume mount, persistence-within-the- container is pointless -- docker rm -f (which every real rebuild uses, per this repo's own documented docker-compose-v1 recreate quirk) throws the container's whole filesystem away regardless. Adds jump-redis-data:/data, matching proxy-data's existing role for the same package (lua-resty-auto-ssl also relies on Redis persistence, via its own volume). Verified: minted a jump-host API token, force-recreated the container, confirmed the token still worked afterward. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 15:47:21 -04:00
wmantly	538b939f9e	Merge pull request #105 from theta42/release/1.13.0 Bump sso-manager-node to v1.7.0, proxy to v1.5.3, jump-host to v1.8.0	2026-07-28 14:18:01 -04:00
wmantly	d61e661099	Bump sso-manager-node to v1.7.0, proxy to v1.5.3, jump-host to v1.8.0 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 14:17:21 -04:00
wmantly	81046a186f	Merge pull request #104 from theta42/fix/jump-oauth-directory-parent Fix: theta-jump OAuth client had no parent in the directory	2026-07-28 13:07:52 -04:00
wmantly	ab9d9301f0	Fix: theta-jump OAuth client had no parent in the directory seedDirectory() only ever linked ONE OAuth client -- whatever id was passed in, which was always the proxy's (resolvedClientId). jump-host's own OAuth client (minted by provisionJumpHost) was never passed through, so it was created but never got a ResourceEdge to the "SSH Jump Host" service resource -- it just showed up in the Directory with no parent. provisionJumpHost now returns the jump client's id (looking it up even on the "already configured" early-return path, so existing deployments self-heal on the next setup.sh run instead of needing this fixed only for fresh installs), and seedDirectory takes it as a third argument, linking it under the jump-host service the same way the proxy's client is linked under the proxy service. Also fixed live on the affected deployment via the directory-admin API (created the missing edge directly) rather than waiting for a rebuild. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 12:53:51 -04:00
wmantly	ffc8af562a	Merge pull request #103 from theta42/release/1.12.0 Bump sso-manager-node to v1.6.3	2026-07-28 01:06:33 -04:00
wmantly	a308fc8bbc	Bump sso-manager-node to v1.6.3 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 01:06:01 -04:00
wmantly	b6c8fe5a89	Merge pull request #102 from theta42/release/1.11.0 Bump sso-manager-node to v1.6.2, proxy to v1.5.2, jump-host to v1.7.1	2026-07-28 00:23:38 -04:00
wmantly	b1cfaa1046	Bump sso-manager-node to v1.6.2, proxy to v1.5.2, jump-host to v1.7.1 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 00:23:01 -04:00
wmantly	2f0e291b29	Merge pull request #101 from theta42/test/jump-ldap-tls-check Add a static consistency check for jump-host's generated LDAP config	2026-07-27 22:42:25 -04:00
wmantly	db2db5095b	Add a static consistency check for jump-host's generated LDAP config Regression guard for bootstrap.js's jump-secrets.js template: its ldap block must use ldaps:// (implicit TLS, :636), not 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 this exact combination broke every SSH login to jump-host (any account, any password) before being root-caused against a real deployment. Static (parses bootstrap.js as text), not a require()+exec of it -- bootstrap.js is a self-running provisioning script with real side effects (LDAP writes, live API calls), not a library, so there's nothing safe to import and call in CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 21:15:47 -04:00
wmantly	79f1f62318	Merge pull request #100 from theta42/release/1.10.0 Bump jump-host to v1.7.0; release notes for the ldaps:// fix	2026-07-27 20:31:04 -04:00
wmantly	d8717fd613	Bump jump-host to v1.7.0; release notes for the ldaps:// fix Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 20:30:36 -04:00
wmantly	f8a213a3bf	Merge pull request #99 from theta42/fix/jump-host-ldap-tls Fix jump-host SSH login: point it at ldaps://, not ldap://	2026-07-27 20:11:28 -04:00
wmantly	f90d319eeb	Fix jump-host SSH login: point it at ldaps://, not ldap:// jump-secrets.js's ldap.url was 'ldap://sso-manager:389' with tlsOptions set. ldapts treats a non-empty tlsOptions as "use implicit TLS" regardless of URL scheme, so every LDAP connection from jump-host opened a raw TLS handshake against sso-manager's plaintext-LDAP port — slapd dropped the connection before any LDAP message parsed (visible in slapd.log as "connection lost" right after ACCEPT, no BIND ever logged). Every SSH login failed with a generic "Permission denied" for any account, any password — indistinguishable from a wrong credential. Root-caused by building a local theta-env stack, restarting jump-host with edited config, and calling userLdap.getUser/checkPassword directly inside the container: got "Client network socket disconnected before secure TLS connection was established" instead of a vague auth failure. Switching to ldaps://sso-manager:636 (already exposed by the same container, already what tlsOptions was meant for) fixes it — verified getUser/checkPassword succeed and a real SSH login authenticates. Companion defensive fix: simpleworkjs/ldap#1 (rejects this exact ldap://+tlsOptions combination going forward, for proxy/sso too). Existing deployments must edit their own ./config/jump-secrets.js (this template only affects fresh bootstraps) — see the PR description. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 20:10:58 -04:00
wmantly	27ab105325	Merge pull request #98 from theta42/release/1.9.0 Bump sso-manager-node to v1.6.1, proxy to v1.5.1	2026-07-27 17:47:02 -04:00
wmantly	5aaec1b18a	Bump sso-manager-node to v1.6.1, proxy to v1.5.1 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 17:46:26 -04:00
wmantly	8c7648781e	Merge pull request #97 from theta42/feature/http-proxy-support Add optional upstream HTTP(S) proxy support for the docker stack	2026-07-27 14:42:15 -04:00
wmantly	46815e681c	Add optional upstream HTTP(S) proxy support for the docker stack CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY in setup.env (all optional, unset by default) get wired into every service's docker build (npm/apt) and running container (SMTP, ACME/Let's Encrypt, DNS provider calls, the jump-host directory API client) as HTTP_PROXY/HTTPS_PROXY/ NO_PROXY. Useful for isolated/offline/corporate-network test hosts that only reach the internet through an upstream proxy — distinct from the theta42 "proxy" app itself. CFG_NO_PROXY defaults to the stack's own internal service names so container-to-container traffic never routes through the proxy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 14:41:38 -04:00
`@@ -1 +1 @@`
	`https://github.com/theta42/theta-env/pull/75`	`https://github.com/theta42/theta-suite/pull/75`