Merge pull request #128 from theta42/release-v1.31.0

v1.31.0: roll up submodules to latest (sso v1.17.1 + ldap-client v1.23.0)
release: bump submodules to latest tags (v1.31.0)
2026-08-01 21:26:55 -04:00 · 2026-08-01 21:26:13 -04:00 · 2026-08-01 20:50:20 -04:00 · 2026-08-01 20:33:21 -04:00 · 2026-08-01 18:46:10 -04:00 · 2026-08-01 13:48:28 -04:00
21 changed files with 673 additions and 299 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,6 +1,6 @@
 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, plus a static
 # consistency check on the config bootstrap.js generates for jump-host
@@ -2,12 +2,253 @@

 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.31.0] - 2026-08-01
+
+Roll-up release: bumps the composed submodules to their latest tags so a fresh
+`git clone` + `./setup.sh` deploys the SSO Manager plugin system, the `/conf`
+SMTP/OAuth secret masking, and the ldap-client changelog. `proxy` (v1.13.1) and
+`jump-host` (v1.14.1) were already at latest and are unchanged.
+
+### Changed (submodule gitlinks)
+- **sso-manager-node**: `v1.16.1` → `v1.17.1` (the plugin system shipped in
+  v1.17.0, plus the v1.17.1 `/conf` secret-masking hardening).
+- **ldap-client**: `v1.1.1` → `v1.23.0` — a CHANGELOG-only release (the new
+  `CHANGELOG.md` documenting v1.1.0/v1.0.0; **no code change** — the "UI polish"
+  tag message is misleading, the v1.1.1…v1.23.0 diff is `CHANGELOG.md` only).
+
+### Deploy
+Operators upgrading from a prior release:
+1. `git pull` and `git submodule update --init --recursive` (or a fresh clone).
+2. Re-run `./setup.sh` — this is **required** if you haven't yet applied the
+   v1.30.1 `sso-broker` OpenBao policy grant for `secret/plugins/*` (idempotent;
+   it grants the existing `SSO_VAULT_TOKEN` access live, so plugin-secrets
+   storage works).
+3. `docker compose build && docker compose up -d`. Existing
+   `conf.discovery.plugins` setups auto-migrate into `PluginInstance` rows +
+   OpenBao secrets on first boot of sso v1.17.x.
+
+### Bundled submodule release notes
+
+#### sso-manager-node v1.17.0 — real plugin system (loadable instances + OpenBao secrets)
+
+## [1.17.0] - 2026-08-01
+
+A real **plugin system**: the half-built discovery plugins (statically
+configured in `sso-secrets.js`, only toggleable for cron/enabled) become
+**configurable, loadable/unloadable plugin instances** you manage from a
+dedicated **Plugins** page and the `/api/plugins` API, with multiple runtime
+copies of each type and per-instance secrets stored in OpenBao.
+
+### Added
+- **Plugin instances** — a new `PluginInstance` ORM model
+  (`nodejs/models/plugin_instance.js`, Sequelize) is the registry of
+  configured, scheduled plugin copies. Each has a `pluginType`, a unique
+  `slug` (the discovery source name), a cron schedule, an `enabled` flag
+  (load/unload), non-secret `config` (JSON), and last-run bookkeeping. Multiple
+  instances of the same type are supported.
+- **Plugin registry** (`nodejs/services/plugin_registry.js`) — generalizes the
+  one-shot discovery-plugin scan in `scheduler.js`. Plugin types are modules
+  under `nodejs/plugins/<category>/<type>.js` exporting a manifest
+  (`type`, `category`, `name`, `description`, `configSchema`, `validate`,
+  `run`/`discover`). Exposes `getTypes`, `getModule`, `splitConfig` (secret vs
+  non-secret), `mask`, and required-field helpers for the UI/API.
+- **Per-instance secrets in OpenBao** (`nodejs/utils/plugin_secrets.js`) —
+  `configSchema` fields flagged `secret:true` (e.g. a Proxmox `tokenSecret`,
+  UniFi `password`) are stored at `secret/plugins/<instance-id>/conf`, never in
+  the DB. The UI only ever sees masked (`********`) values. Plugins run
+  in-process (BullMQ workers), so they need no OpenBao token of their own — the
+  SSO reads/writes via the `sso-broker` token. **Requires theta-suite ≥ v1.30.1**
+  for the `sso-broker` policy grant on `secret/plugins/*`; the API fails-soft
+  with a clear error if absent.
+- **`/api/plugins` API** (`nodejs/routes/api_plugins.js`, replaces the old
+  `routes/plugins.js`) — `GET /types`, list/get/create/update/update-secrets/
+  test/load/unload/run/delete/runs. Admin-only
+  (`app_sso_admin` / `app_sso_directory_admin` / `app_super_admin`).
+- **Plugins page** (`/plugins`, `views/plugins.ejs`) + nav entry — instance
+  table with New/Edit/Edit-Secrets/Test/Run-now/Load/Unload/Delete, config forms
+  rendered from each type's `configSchema`.
+- **`validate`** ("Test" button) on the built-in Proxmox/UniFi/Nmap plugins.
+
+### Changed
+- `services/scheduler.js` now schedules from the `PluginInstance` table instead
+  of static `conf.discovery.plugins` + a Redis override hash. Each instance owns
+  a stable BullMQ JobScheduler id (`plugin:<instanceId>`) so load/unload
+  upsert/remove one schedule without disturbing the rest. Discovery plugins
+  reconcile results under the instance's `slug`.
+- The three discovery plugins (`plugins/discovery/{proxmox,unifi,nmap}.js`)
+  gained manifests (`configSchema`, `validate`, `run` alias). `nmap`'s
+  `targetRange` is non-secret; Proxmox `tokenSecret` and UniFi `password` are
+  secret.
+- The `/plugins` page route renders the page instead of redirecting to
+  `/directory`; the **Agents & Scheduler** tab was removed from `/directory`
+  (plugins are now managed on the Plugins page). The `/docs/agents` link is
+  aliased to `/docs/plugins`.
+- `docs/plugins.md`, `docs/vault.md`, `docs/_config.yml` (nav), and `API.md`
+  (Plugin Endpoints section) document the new system.
+
+### Legacy migration
+On first boot of v1.17.0, if the `PluginInstance` table is empty **and**
+`conf.discovery.plugins` has entries, one instance per configured type is seeded
+automatically (secret fields copied into OpenBao). After that the static
+config is ignored — manage plugins from the UI/API. Idempotent (guarded by the
+empty-table check).
+
+### Prerequisite
+**theta-suite ≥ v1.30.1** — re-run `./setup.sh` after upgrading so the
+`sso-broker` OpenBao policy is granted `secret/plugins/*`. Without it, storing
+plugin secrets fails with a clear error.
+
+
+#### sso-manager-node v1.17.1 — mask SMTP/OAuth secrets + leave-blank-to-keep on /conf
+
+## [1.17.1] - 2026-08-01
+
+Hardens the **runtime SMTP/OAuth secret handling** on the `/conf` admin page to
+match the plugin-secrets discipline: the SMTP password and OAuth JWT secret are
+no longer returned in cleartext by `GET /api/conf` or round-tripped through the
+form. They remain saved in OpenBao at `secret/sso-manager/conf` at runtime
+(unchanged) — only how they're surfaced to the admin changes.
+
+### Changed
+- **`GET /api/conf`** now masks `smtp.pass` and `oauth.jwtSecret` to `********`
+  (was: returned in cleartext). Non-secret fields (host, port, user, from,
+  secure, issuer, token lifetimes) are returned as before.
+- **`POST /api/conf`** now treats a blank or `********` secret-field submission
+  as "keep the current stored value" — so an admin editing the From address or
+  token lifetimes no longer has to re-enter (or leak) the SMTP password / JWT
+  secret. Only a genuinely new, non-blank value overwrites. The preserved values
+  are re-applied to live `conf` immediately, as before.
+- **`/conf` page** (`views/conf.ejs`): the Password and JWT Secret fields carry
+  a "leave unchanged to keep the current value stored in OpenBao" hint; the page
+  copy notes secret fields are masked. No JSON-textarea editing is involved —
+  SMTP is and remains configured through structured form fields.
+
+### Notes
+- SMTP (and OAuth) config was **already** saved to OpenBao at runtime before
+  this release (via `POST /api/conf` → `baoConf.set('sso-manager/conf')`, and
+  overlaid back at boot by `bao-conf.init`). This release closes the
+  cleartext-exposure gap; it does not move the storage path.
+- No theta-suite policy change required — `secret/sso-manager/conf` was already
+  granted to the `sso-broker` policy.
+
+
+#### ldap-client v1.23.0 — CHANGELOG-only (no code change)
+
+Adds a `CHANGELOG.md` documenting v1.1.0 (`app_super_admin` / `app_jump_admin`
+group support in SSSD access filters; the sso/jump-host TLS-validation
+divergence) and v1.0.0 (initial SSSD LDAP auth release). No source changes vs
+v1.1.1; the v1.23.0 tag commit only adds this file.
+
+## [v1.30.1] - 2026-08-01
+
+Prerequisite release for the SSO Manager plugin system (shipped in
+sso-manager-node v1.17.0). Grants the `sso-broker` OpenBao policy access to the
+new per-instance plugin secrets namespace so the SSO can store plugin secrets in
+OpenBao instead of `sso-secrets.js`.
+
+### Changed (theta-suite orchestration)
+- **`setup.sh`**: added `secret/data/plugins/*` (CRUD+list) and
+  `secret/metadata/plugins/*` (list/read/delete) to the `sso-broker` policy
+  HCL. `ensure_policy sso-broker` is idempotent, so re-running `./setup.sh`
+  immediately grants the existing `SSO_VAULT_TOKEN` access to `secret/plugins/*`
+  (policies are evaluated live; the token keeps its id). The SSO side fails-soft
+  with a clear error if this grant is absent.
+- **Docs**: `docs/secrets.md` (new "Plugin secrets" section + `sso-broker`
+  policy row) and `docs/architecture.md` (sso-manager access row) now list
+  `secret/plugins/*`.
+
+> The plugin system itself (configurable plugin instances, load/unload, UI/API,
+> multi-copy, secrets in OpenBao) is in sso-manager-node v1.17.0; theta-suite
+> will bump its submodule gitlink to that release next.
+
+## [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
@@ -18,7 +259,7 @@ 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-env orchestration)
+### 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-*`,
@@ -111,7 +352,7 @@ and exposes a fixed, role-scoped personal-secrets UI.
  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-env stack is unaffected (it always sets a scoped `VAULT_TOKEN`).
+  theta-suite stack is unaffected (it always sets a scoped `VAULT_TOKEN`).

 ##### v1.13.0 — Changed
 - **Secrets now load from OpenBao at boot** via
@@ -136,7 +377,7 @@ and exposes a fixed, role-scoped personal-secrets UI.
  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-env stack is unaffected (it always sets a scoped
+  contract. The theta-suite stack is unaffected (it always sets a scoped
  `VAULT_TOKEN`).

 ##### v1.14.0 — Changed
@@ -507,7 +748,7 @@ 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-env#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.
+- **`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.
@@ -594,14 +835,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

@@ -655,7 +896,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:

@@ -678,7 +919,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:

@@ -701,7 +942,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

@@ -799,12 +1040,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.
@@ -880,7 +1121,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
@@ -910,7 +1151,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`.
@@ -954,7 +1195,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.
@@ -1094,10 +1335,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
@@ -1130,7 +1371,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)
@@ -1165,23 +1406,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
-[1.4.0]: https://github.com/theta42/theta-env/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.16]: https://github.com/theta42/theta-env/compare/v1.1.15...v1.1.16
-[1.1.15]: https://github.com/theta42/theta-env/compare/v1.1.14...v1.1.15
-[1.1.14]: https://github.com/theta42/theta-env/compare/v1.1.13...v1.1.14
-[1.1.13]: https://github.com/theta42/theta-env/compare/v1.1.12...v1.1.13
-[1.1.12]: https://github.com/theta42/theta-env/compare/v1.1.11...v1.1.12
-[1.1.11]: https://github.com/theta42/theta-env/compare/v1.1.10...v1.1.11
-[1.1.10]: https://github.com/theta42/theta-env/compare/v1.1.9...v1.1.10
-[1.1.9]: https://github.com/theta42/theta-env/compare/v1.1.8...v1.1.9
-[1.1.8]: https://github.com/theta42/theta-env/compare/v1.1.7...v1.1.8
-[1.1.7]: https://github.com/theta42/theta-env/compare/v1.1.6...v1.1.7
-[1.1.6]: https://github.com/theta42/theta-env/compare/v1.1.5...v1.1.6
-[1.1.5]: https://github.com/theta42/theta-env/compare/v1.1.4...v1.1.5
-[1.1.4]: https://github.com/theta42/theta-env/compare/v1.1.3...v1.1.4
-[1.1.3]: https://github.com/theta42/theta-env/compare/v1.1.2...v1.1.3
-[1.1.2]: https://github.com/theta42/theta-env/compare/v1.1.1...v1.1.2
-[1.1.1]: https://github.com/theta42/theta-env/compare/v1.1.0...v1.1.1
-[1.1.0]: https://github.com/theta42/theta-env/releases/tag/v1.1.0
+[Unreleased]: https://github.com/theta42/theta-suite/compare/v1.4.0...HEAD
+[1.4.0]: https://github.com/theta42/theta-suite/compare/v1.3.7...v1.4.0
+[1.1.17]: https://github.com/theta42/theta-suite/compare/v1.1.16...v1.1.17
+[1.1.16]: https://github.com/theta42/theta-suite/compare/v1.1.15...v1.1.16
+[1.1.15]: https://github.com/theta42/theta-suite/compare/v1.1.14...v1.1.15
+[1.1.14]: https://github.com/theta42/theta-suite/compare/v1.1.13...v1.1.14
+[1.1.13]: https://github.com/theta42/theta-suite/compare/v1.1.12...v1.1.13
+[1.1.12]: https://github.com/theta42/theta-suite/compare/v1.1.11...v1.1.12
+[1.1.11]: https://github.com/theta42/theta-suite/compare/v1.1.10...v1.1.11
+[1.1.10]: https://github.com/theta42/theta-suite/compare/v1.1.9...v1.1.10
+[1.1.9]: https://github.com/theta42/theta-suite/compare/v1.1.8...v1.1.9
+[1.1.8]: https://github.com/theta42/theta-suite/compare/v1.1.7...v1.1.8
+[1.1.7]: https://github.com/theta42/theta-suite/compare/v1.1.6...v1.1.7
+[1.1.6]: https://github.com/theta42/theta-suite/compare/v1.1.5...v1.1.6
+[1.1.5]: https://github.com/theta42/theta-suite/compare/v1.1.4...v1.1.5
+[1.1.4]: https://github.com/theta42/theta-suite/compare/v1.1.3...v1.1.4
+[1.1.3]: https://github.com/theta42/theta-suite/compare/v1.1.2...v1.1.3
+[1.1.2]: https://github.com/theta42/theta-suite/compare/v1.1.1...v1.1.2
+[1.1.1]: https://github.com/theta42/theta-suite/compare/v1.1.0...v1.1.1
+[1.1.0]: https://github.com/theta42/theta-suite/releases/tag/v1.1.0
@@ -1,9 +1,10 @@
-# theta-env
+# theta-suite

 The whole theta42 identity + access stack in one repo, brought up with a single
 command — for home labs and small businesses.

-It wires together two projects that already work on their own:
+It composes four applications around a shared [OpenBao](https://openbao.org/)
+secrets store, brought up with one command:

 - **[SSO Manager](https://github.com/theta42/sso-manager-node)** — an OIDC
  provider with a built-in LDAP directory (OpenLDAP) and a web UI for managing
@@ -11,12 +12,15 @@ It wires together two projects that already work on their own:
 - **[theta42/proxy](https://github.com/theta42/proxy)** — an OIDC-protected
  reverse proxy (OpenResty) that puts any of your apps behind SSO login and can
  look users up directly in LDAP.
+- **[Jump Host](https://github.com/theta42/jump-host)** — directory-driven SSH
+  access to your machines through one public entry point.
+- **[ldap-client](https://github.com/theta42/ldap-client)** — enrolls Linux
+  hosts into the directory for PAM/SSSD login, sudo, and SSH keys.

-Each project still runs **standalone** (`docker compose up` in its own folder);
-this repo just composes them and automates the first-run glue so they find each
-other.
+All four load their secrets from OpenBao at boot; `setup.sh` automates the
+first-run glue so they find each other and the secrets store.

-**Documentation:** [https://theta42.github.io/theta-env/](https://theta42.github.io/theta-env/)
+**Documentation:** [https://theta42.github.io/theta-suite/](https://theta42.github.io/theta-suite/)

 ## Screenshots

@@ -125,9 +129,10 @@ see browser warnings.)

 Optional extra ports (only if you need them):
 - **4443** — alternate HTTPS listener (e.g. if 443 is taken by something else).
- **636** (LDAPS) — only if a legacy app on another machine binds to LDAP
-  directly over the network. The proxy itself reaches LDAP over the internal
-  Docker network, so you do **not** need to expose 636 for the stack to work.
+- **636** (LDAPS) — for direct-LDAP clients on other machines (Linux hosts
+  via PAM/SSSD, LDAP-native apps). The proxy itself reaches LDAP over the
+  internal Docker network, so you do **not** need to expose 636 for the stack
+  to work.
  **Do not forward 636 to the public internet.** If you need LAN clients to bind
  LDAP, set `CFG_LDAPS_HOST=ldap.internal.example.com` (or `sso-manager` for
  same-host Docker clients) in `setup.env` and use an internal DNS record / cert
@@ -143,8 +148,8 @@ standalone (`docker-compose`) both work.
 ## Quickstart

 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your domain
 ./setup.sh            # first run: generates ./config/ from setup.env, builds + bootstraps + starts
 ```
@@ -233,9 +238,10 @@ override on the command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See
 - **Proxy mgmt UI**: `https://<PROXY_HOST>` — add the Host records you want to
  protect with OIDC. (First-run fallback: `http://<host>:3000`, reachable on the
  LAN by default.)
- **Direct LDAP for legacy apps**: bind to `ldaps://<host>:636` as
-  `cn=admin,<base>` (admin) or `cn=ldapclient,ou=people,<base>` (read-only
-  service account the bootstrap created). Use LDAPS, not plain LDAP.
+- **Direct LDAP for LDAP-native clients and Linux hosts**: bind to
+  `ldaps://<host>:636` as `cn=admin,<base>` (admin) or
+  `cn=ldapclient,ou=people,<base>` (read-only service account the bootstrap
+  created). Use LDAPS, not plain LDAP.

 ### API tokens (personal access tokens)

@@ -346,7 +352,7 @@ docker compose cp proxy:/data/dump.rdb proxy.rdb
 # 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-env_openbao-data:/data -v "$PWD":/backup alpine \
+docker run --rm -v theta-suite_openbao-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/openbao-data.tgz -C /data .
 ```

@@ -398,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
@@ -486,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
@@ -507,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
@@ -275,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' },
@@ -464,9 +464,9 @@ async function seedDirectory(token, clientId, jumpClientId) {
 		subType: 'openresty',
 	});

-	// Optional SSH jump host service.
+	// SSH jump host service (core component — always registered).
 	let jumpSvc = null;
-	if (/^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '')) {
+	{
 		const jumpHost = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
 		jumpSvc = await ensure('service', 'SSH Jump Host', 'jump-host', host.id, {
 			address: jumpHost ? `https://${jumpHost}` : '',
@@ -523,16 +523,16 @@ function writeProxyCreds(id, secret) {
 	}
 }

-// ── 6. Optional: provision the SSH jump host ────────────────────────────────
-// When CFG_JUMP_HOST_ENABLED=true, the jump host needs: a directory API token
-// (to resolve which hosts a user may reach), an LDAP bind account that can
-// WRITE the sshPublicKey attribute (it injects its own key on first use), and
-// a config file it reads. We write /config/jump-secrets.js deriving LDAP/site
-// from sso-secrets.js + a freshly minted API token. The bundled jump host
-// binds as cn=admin (already able to write sshPublicKey) — hardened bare-metal
-// deployments should use a scoped account + attribute ACL instead (see the
-// jump-host README). Idempotent: skips if the file already has a real token.
-const JUMP_ENABLED = /^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '');
+// ── 6. Provision the SSH jump host ─────────────────────────────────────────
+// The jump host is a core component (always provisioned). It needs: a directory
+// API token (to resolve which hosts a user may reach), an LDAP bind account
+// that can WRITE the sshPublicKey attribute (it injects its own key on first
+// use), and a config file it reads. We write /config/jump-secrets.js deriving
+// LDAP/site from sso-secrets.js + a freshly minted API token. The bundled jump
+// host binds as cn=admin (already able to write sshPublicKey) — hardened
+// bare-metal deployments should use a scoped account + attribute ACL instead
+// (see the jump-host README). Idempotent: skips if the file already has a real
+// token.
 const JUMP_HOST = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
 const JUMP_SECRETS = '/config/jump-secrets.js';
 const JUMP_TOKEN_NAME = 'theta-jump-host';
@@ -543,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();
@@ -568,7 +568,7 @@ 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).
@@ -653,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],
 		});
 	}
@@ -716,23 +716,22 @@ async function provisionJumpHost(token) {
 		// generated OAuth creds). Warn-only.
 		await baoPut('proxy/conf', freshRequire('/config/proxy-secrets.js'));

-		// Provision the jump host (mint token + write config) when enabled.
-		// Warn-only — never fail the whole bring-up over the optional service.
+		// 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;
-		if (JUMP_ENABLED) {
-			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`);
-			}
+		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
@@ -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.
@@ -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,
@@ -170,12 +170,10 @@ services:
      retries: 3
      start_period: 30s

-  # Optional SSH jump host. Only started when the `jump-host` compose profile
-  # is active — setup.sh exports COMPOSE_PROFILES=jump-host when
-  # CFG_JUMP_HOST_ENABLED=true. Authenticates users against the SSO's OpenLDAP,
-  # resolves reachable hosts from the directory API, and bridges SSH through.
+  # SSH jump host — a core component, always built + started alongside the
+  # SSO and proxy. Authenticates users against the SSO's OpenLDAP, resolves
+  # reachable hosts from the directory API, and bridges SSH through.
  jump-host:
-    profiles: ["jump-host"]
    build:
      context: ./jump-host
      dockerfile: Dockerfile
@@ -220,11 +218,11 @@ services:
  # 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. Same jump-host profile, so
-  # `docker compose --profile jump-host up` brings up jump-host and a host it
-  # can actually reach together.
+  # 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: ["jump-host"]
+    profiles: ["ldap-test"]
    build:
      context: ./ldap-client
      dockerfile: Dockerfile
@@ -1,7 +1,7 @@
-title: theta-env
+title: theta-suite
 description: A unified, one-command SSO Manager + OIDC proxy stack for home labs and small businesses.
 url: "https://theta42.github.io"
-baseurl: "/theta-env"
+baseurl: "/theta-suite"
 logo: /assets/img/theta42.svg
 lang: en_US

@@ -10,10 +10,10 @@ plugins:
  - jekyll-sitemap

 github:
-  repository_url: https://github.com/theta42/theta-env
-  zip_url: https://github.com/theta42/theta-env/archive/refs/heads/master.zip
-  tar_url: https://github.com/theta42/theta-env/archive/refs/heads/master.tar.gz
-  repository_name: theta42/theta-env
+  repository_url: https://github.com/theta42/theta-suite
+  zip_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.zip
+  tar_url: https://github.com/theta42/theta-suite/archive/refs/heads/master.tar.gz
+  repository_name: theta42/theta-suite

 nav:
  - title: Home
@@ -32,7 +32,7 @@ nav:
    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
-their git submodules and adds the glue that wires them together. It does not
-fork or patch them — both projects work unchanged on their own.
+theta-suite is a **composition** repo: it builds four applications from their
+git submodules and adds the glue that wires them together — plus a shared
+[OpenBao](https://openbao.org/) secrets store — on one Docker network. It
+does not fork or patch the components; it composes and configures them.

 ---

-## The three repos
+## Components

-| Repo | Role |
+| Repo / image | Role |
 |------|------|
 | [`theta42/sso-manager-node`](https://github.com/theta42/sso-manager-node) | OIDC provider + OpenLDAP directory + web UI. All-in-one image (`Dockerfile.openldap`). |
 | [`theta42/proxy`](https://github.com/theta42/proxy) | OIDC-protected reverse proxy (OpenResty + Node mgmt app + Redis). All-in-one image (`Dockerfile`). |
-| `theta42/theta-env` (this repo) | Composes the two on one Docker network + automates first-run wiring. |
+| [`theta42/jump-host`](https://github.com/theta42/jump-host) | Directory-driven SSH jump host (sshd + Node web UI). Image (`Dockerfile`). |
+| [`theta42/ldap-client`](https://github.com/theta42/ldap-client) | Enrolls real Linux hosts into the directory (SSSD + AuthorizedKeysCommand). Also the opt-in `ldap-test-host` fixture. |
+| `quay.io/openbao/openbao` | Central secrets store (Vault fork), KV-v2 at `secret/`. |
+| `theta42/theta-suite` (this repo) | Composes all of the above on one network + automates first-run wiring. |

-The two projects are pinned as **git submodules**. `git clone --recursive`
-fetches all three in one step; `git submodule update --remote` bumps them.
+The four applications are pinned as **git submodules**; OpenBao uses the
+upstream image. `git clone --recursive` fetches the submodules in one step;
+`git submodule update --remote` bumps them.

 ---

-## The two containers
+## The stack

 ```
-            ┌──────────────────────────────────────────────┐
-            │  your browser / apps / direct LDAP clients     │
-            └───────────────┬──────────────────────────────┘
-                            │ https (:443)        ldaps (:636)
-                  ┌─────────▼─────────┐
-                  │  proxy container  │  OpenResty :80/:443/:4443
-                  │  (OIDC + LDAP)    │  Node mgmt app :3000 (localhost only)
-                  │                   │  bundled Redis (127.0.0.1:6379)
-                  └─────────┬─────────┘
-              ┌─────────────┼────────────────────────────┐
-              │ ldaps:636   │ http:3001 (internal)       │  OIDC token + userinfo
-              │ (docker net)│ (docker net, not published)│  (server-to-server)
-              ▼             ▼                           │
-      ┌──────────────────────────────┐                   │
-      │  sso-manager container       │◄──────────────────┘
-      │  OIDC provider (Express)     │  bundled Redis (127.0.0.1:6379)
-      │  OpenLDAP (slapd)            │  web UI :3001 (localhost only)
-      │  ldaps :636 (published)      │
-      └───────────────────────────────┘
-            ▲
-            │ ldaps :636 (published to host) — legacy apps bind directly
-            │
-      ┌──────────────────────────────┐
-      │  legacy apps (Gitea, Emby, …)│
-      └──────────────────────────────┘
+          ┌──────────────────────────────────────────────────────────┐
+          │ browser / OIDC apps │ SSH clients │ Linux hosts            │
+          │                     │             │ (PAM/SSSD, sudo, keys)  │
+          └────────┬────────────┴──────┬──────┴───────────┬───────────┘
+            https (:443)          ssh (:2222)        ldaps (:636)
+                  │                     │                  │
+         ┌────────▼────────┐  ┌──────────▼────────┐         │
+         │  proxy           │  │  jump-host        │         │
+         │  OpenResty       │  │  sshd :2222       │         │
+         │  :80/:443/:4443  │  │  web UI :3002     │         │
+         │  mgmt app :3000  │  └────────┬──────────┘         │
+         └────────┬─────────┘           │ OIDC + LDAP        │
+                  │ http:3001 (internal)│ via sso-manager    │
+                  ▼                     ▼                    ▼
+        ┌───────────────────────────────────────────────────────┐
+        │  sso-manager   (Express + OpenLDAP + Redis)            │
+        │  OIDC provider + LDAP directory                         │
+        │  web UI :3001 (internal)   ldaps :636 (published)       │
+        └───────────────────────────────────────────────────────┘
+                          ▲  loads secrets at boot (scoped token each)
+              ┌───────────┴───────────────────┐
+              │  openbao   (KV-v2 at secret/)  │  ← central secrets store
+              │  :8200 (internal)             │     per-user + per-app KV
+              │  :8080 (operator UI/API)     │
+              └───────────────────────────────┘
+
+   ldap-client — enrolls real Linux hosts into the directory above
+                 (PAM/SSSD login, sudo, SSH-key serving); also the
+                 `ldap-test-host` fixture (opt-in: `--profile ldap-test`).
 ```

-Both containers bundle their **own Redis** (the proxy hardcodes `127.0.0.1:6379`
-in three places that ignore config; the SSO's models default to the same). Two
-redis instances is the no-source-patch path and is fine at this scale.
+All four services bundle their **own Redis** (sso-manager, proxy, jump-host
+each run a 127.0.0.1:6379 instance) and share the `openbao` secrets store.
+Direct LDAP binds against `:636` are first-class — that's how Linux hosts do
+PAM/SSSD login, sudo, and SSH-key serving, and how LDAP-native apps
+authenticate — not a fallback path.

 ### What's exposed, what's not

-| Port | On host? | Purpose |
-|------|----------|---------|
-| `443` (proxy) | **yes** | the public entry point — OIDC login + proxied apps + the SSO/proxy UIs |
-| `80` (proxy) | **yes** | HTTP-01 for Let's Encrypt (and redirect to 443) |
-| `4443` (proxy) | yes (optional) | alt HTTPS listener |
-| `3000` (proxy) | localhost only | proxy mgmt UI/API (first-run convenience; fronted by 443 normally) |
-| `636` (sso) | yes | LDAPS for legacy direct-LDAP clients |
-| `3001` (sso) | localhost only | SSO web UI (first-run convenience; fronted by the proxy normally) |
-| `389` (sso) | **no** | plain LDAP — internal only (app↔slapd over localhost) |
+| Port | Service | On host? | Purpose |
+|------|---------|----------|---------|
+| `443` | proxy | **yes** | public entry point — OIDC login + proxied apps + the SSO/proxy UIs |
+| `80` | proxy | **yes** | HTTP-01 for Let's Encrypt (and redirect to 443) |
+| `4443` | proxy | yes (optional) | alt HTTPS listener |
+| `3000` | proxy | localhost/LAN | proxy mgmt UI/API (fronted by 443 normally) |
+| `3001` | sso-manager | localhost/LAN | SSO web UI (fronted by the proxy normally) |
+| `636` | sso-manager | **yes** | LDAPS for direct-LDAP clients (Linux hosts, LDAP-native apps) |
+| `389` | sso-manager | **no** | plain LDAP — internal only (app↔slapd over localhost) |
+| `2222` | jump-host | **yes** | SSH front door |
+| `3002` | jump-host | **yes** | jump-host web UI/API |
+| `8080` | openbao | yes | OpenBao UI/API for the operator (apps use `openbao:8200` internally) |
+
+---
+
+## Secrets (OpenBao)
+
+Every component loads its secrets from one OpenBao instance at boot, not
+from scattered config files. OpenBao runs as the `openbao` container
+(`http://openbao:8200` on theta-net, KV-v2 at `secret/`); each app gets a
+**scoped token** (never the root token) whose OpenBao policy confines it to
+the paths it needs:
+
+| Service | env var | Policy | Access |
+|---------|---------|--------|--------|
+| sso-manager | `SSO_VAULT_TOKEN` | `sso-broker` | `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`, `secret/plugins/*`; also mints per-user + per-app tokens |
+| proxy | `PROXY_VAULT_TOKEN` | `proxy` | `secret/proxy/conf` (read) |
+| jump-host | `JUMP_VAULT_TOKEN` | `jump-host` | `secret/jump-host/conf` (read) |
+
+At boot each app calls `@simpleworkjs/bao-conf`'s `init()`, which deep-merges
+its OpenBao path over the file-loaded `@simpleworkjs/conf` object — so OpenBao
+is authoritative at runtime, with the `./config/*-secrets.js` file kept only as
+an operator-edited seed and a fail-soft fallback (`init()` is fail-soft, so the
+app still boots from the file if OpenBao is unreachable). The proxy and
+jump-host consume `conf.oidc.clientSecret` at `require` time, so `init()`
+runs *before* their models load (see each app's `bin/www`).
+
+Beyond app config, OpenBao holds:
+
+- **Per-user secret storage** — `secret/users/<uid>/*`, browsed and edited in
+  the SSO UI's **My Secrets** page. Each user is confined to their own
+  namespace by a `user-<uid>` policy; admins see all of `secret/`.
+- **External-app tokens** — an admin mints a scoped `app-<name>` token
+  (confined to `secret/apps/<name>/*`) from the SSO UI's **Apps** tab, so an
+  external app can read its own secrets over the OpenBao HTTP API.
+
+`setup.sh` creates the policies + a `sso-broker` token role and mints the
+per-app tokens on first run; the root token stays in `setup.env` for
+seeding/maintenance only and is never passed to a service container. Full
+details — the policy model, the `secret/apps/<app>/conf` convention, `curl`
+ Node examples, and the operator rotation procedure — are in
+[Secrets](secrets.html).

 ---

@@ -82,7 +136,14 @@ actual work, running **inside the sso-manager container** (bind-mounted
 read-only from this repo). It's deliberately self-contained — only Node
 built-ins (`child_process`, `crypto`, `fs`) + global `fetch`, and it reads its
 inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets.js`
-(not from env):
+(not from env).
+
+OpenBao comes up first: `setup.sh` initializes and unseals it, writes the
+policies and the `sso-broker` token role, mints the per-app scoped tokens into
+`setup.env`, and idempotently seeds `secret/sso-manager/conf`,
+`secret/proxy/conf`, and `secret/jump-host/conf` from the corresponding
+`./config/*-secrets.js` files. The app containers then start with their scoped
+`VAULT_TOKEN`. The SSO/LDAP/OIDC wiring that follows:

 1. **Build + start sso-manager**, wait for `/health`.
 2. **LDAP service account** — `ldapadd` `cn=ldapclient,ou=people,<base>` (an
@@ -97,14 +158,16 @@ inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets
 5. **Register the proxy as an OIDC client** via `POST /api/oauth/client` (gated
   by `app_sso_oauth_admin`, satisfied by step 3). The SSO **generates** the
   `client_id`/`client_secret` (UUIDs) — supplied creds are ignored — so the
-   bootstrap writes the generated creds **back into `./config/proxy-secrets.js`**
-   (the sso-manager mounts `./config` read-write for this; the proxy mounts it
-   read-only). If `proxy-secrets.js` already holds a `clientId`+`clientSecret`
-   matching an existing client, they are kept; if the client exists but the file
-   has no usable secret, the secret is rotated and written back.
-6. **Build + start the proxy**, wait for `/health`. The proxy entrypoint points
-   `CONF_SECRETS` at `./config/proxy-secrets.js`, so `@simpleworkjs/conf`
-   (≥1.2.0) reads the OAuth creds + LDAP bind creds from the file.
+   bootstrap writes the generated creds **back into `./config/proxy-secrets.js`
+   and into OpenBao at `secret/proxy/conf`** (the sso-manager mounts `./config`
+   read-write for this; the proxy mounts it read-only). If `proxy-secrets.js`
+   already holds a `clientId`+`clientSecret` matching an existing client, they
+   are kept; if the client exists but the file has no usable secret, the
+   secret is rotated and written back.
+6. **Build + start the proxy + jump-host**, wait for `/health`. Each
+   entrypoint points `CONF_SECRETS` at its `./config/*-secrets.js`, then
+   `@simpleworkjs/bao-conf` overlays the OpenBao path over it (the OAuth
+   clientSecret + LDAP bind creds come from OpenBao at runtime).
 7. **Register `<SSO_HOST>` and `<PROXY_HOST>` as Host records in the proxy** —
   `setup.sh` runs a short script inside the proxy container that calls its
   Host model directly (`Host.create({host, ip, targetPort, ...})`), rather
@@ -120,20 +183,25 @@ inputs from the bind-mounted `./config/sso-secrets.js` + `./config/proxy-secrets

 `setup.sh` then prints the first-admin login + the public URLs.

-### How config reaches the apps (no `.env`)
+### How config reaches the apps

-All config and secrets live in `./config/` (gitignored, bind-mounted). Each
-entrypoint points the `CONF_SECRETS` env var (`@simpleworkjs/conf` >= 1.2.0)
-at its file early, before the app starts:
+Config and secrets live in two layers: an operator-edited
+`./config/*-secrets.js` file (gitignored, bind-mounted) and the OpenBao
+overlay over it. Each entrypoint points the `CONF_SECRETS` env var
+(`@simpleworkjs/conf` >= 1.2.0) at its file early, before the app starts:

 ```
 CONF_SECRETS=/config/sso-secrets.js    (sso-manager, ./config RW)
 CONF_SECRETS=/config/proxy-secrets.js  (proxy, ./config RO)
+CONF_SECRETS=/config/jump-secrets.js   (jump-host, ./config RO)
 ```

 `@simpleworkjs/conf` loads `conf/base.js → <env>.js → secrets file → app_*
-env`, where **env beats the secrets file**. So compose passes **no `app_*` env
-vars** (only `NODE_ENV`, `NODE_PORT`) — that makes the secrets file
+env`, where **env beats the secrets file**. Then `@simpleworkjs/bao-conf`
+deep-merges the app's OpenBao path over the result at boot — OpenBao is the
+authoritative runtime layer; the file is the seed and fail-soft fallback. So
+compose passes **no `app_*` config env vars** (only `NODE_ENV`, `NODE_PORT`,
+`VAULT_ADDR`, and a scoped `VAULT_TOKEN`) — that keeps the secrets file + OpenBao
 authoritative. The SSO entrypoint reads the few values it needs at startup
 (LDAP base DN, admin password, JWT secret, cert CN) from `sso-secrets.js` via
 an in-container `node` call.
@@ -151,12 +219,15 @@ end-to-end.

 ## Idempotency

-Re-running `./setup.sh` converges to `./config/`:
+Re-running `./setup.sh` converges to `./config/` + OpenBao:

 - The LDAP service account + admin passwords are **reset to `./config/`**.
 - Group membership is ensured (add is a no-op if already a member).
 - The OAuth client is kept if `proxy-secrets.js` already holds its creds;
-  created or rotated otherwise, and the new creds written back.
+  created or rotated otherwise, and the new creds written back (to the file
+  and to OpenBao).
+- OpenBao policies, token role, per-app tokens, and `secret/<app>/conf` seeds
+  are ensured (created if absent, left alone if present).

 So `setup.sh` is safe to re-run after editing `./config/`, after a `docker
 compose down`, or after restoring from backup.
@@ -165,14 +236,18 @@ compose down`, or after restoring from backup.

 ## Backups and restore

-`./setup.sh` auto-snapshots `./config/` + LDAP + both Redis to
+`./setup.sh` auto-snapshots `./config/` + LDAP + all the Redis instances to
 `./backups/<timestamp>/` before each rebuild (keeps the last `BACKUP_KEEP`,
-default 5). State lives on named volumes (`ldap-data`, `sso-data`, `proxy-data`)
-and survives recreation; `down -v` wipes them. Redis is persisted with AOF +
-RDB on those volumes. For the full manual-backup + restore runbook (full /
-Redis-only / LDAP-only, with the AOF-vs-RDB note), see the *Backups and
-restore* section of the [README](https://github.com/theta42/theta-env#backups-and-restore).
-Quick LDAP backup:
+default 5). State lives on named volumes (`ldap-data`, `ldap-certs`,
+`sso-data`, `proxy-data`, `proxy-cache`, `proxy-logs`, `jump-data`,
+`jump-redis-data`, `openbao-data`) and survives recreation; `down -v` wipes
+them. Redis is persisted with AOF + RDB on those volumes. For the full
+manual-backup + restore runbook (full / Redis-only / LDAP-only, with the
+AOF-vs-RDB note), see the *Backups and restore* section of the
+[README](https://github.com/theta42/theta-suite#backups-and-restore). OpenBao
+holds the live secrets, so back up its volume too (`<project>_openbao-data`,
+where `<project>` is your clone directory name — `theta-suite` for a fresh
+clone). Quick LDAP backup:

 ```bash
 docker compose exec sso-manager slapcat -f /etc/openldap/slapd.conf -b "<base>" > backup.ldif
@@ -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
-single command — for home labs and small businesses.
+The whole theta42 identity, access, and secrets stack in one repo, brought up
+with a single command — for home labs and small businesses.

-It wires together two projects that already work on their own —
+It composes four applications around a shared secrets store:
 [SSO Manager](https://theta42.github.io/sso-manager-node/) (OIDC provider +
-LDAP directory) and [Proxy](https://theta42.github.io/proxy/) (an
-OIDC-protected reverse proxy that can also look users up directly in LDAP) —
-and automates the fiddly part: registering the proxy as an OIDC client of the
-SSO and pointing it at the right LDAP directory, with hostnames and secrets
-generated from one `setup.env`. An optional third component, the
-[Jump Host](https://theta42.github.io/jump-host/), adds directory-driven SSH
-access to your machines through one public entry point.
+LDAP directory), [Proxy](https://theta42.github.io/proxy/) (an OIDC-protected
+reverse proxy that can also look users up directly in LDAP),
+[Jump Host](https://theta42.github.io/jump-host/) (directory-driven SSH access
+through one public entry point), and
+[ldap-client](https://theta42.github.io/ldap-client/) (enrolls your Linux
+hosts into the directory for PAM/SSSD, sudo, and SSH keys). All of them read
+their secrets at boot from [OpenBao](https://openbao.org/), the central secrets
+store. `setup.sh` automates the fiddly part: registering the proxy as an OIDC
+client of the SSO, pointing every component at the right LDAP directory and
+the OpenBao token it needs, and generating hostnames and secrets from one
+`setup.env`.

 ## Screenshots

@@ -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
-proxy is registered as an OIDC client of the SSO *and* pointed at the SSO's
-LDAP directory — and the domain has to match across half a dozen config
+The components are designed to integrate — they're only useful together once
+the proxy is registered as an OIDC client of the SSO *and* pointed at the
+SSO's LDAP directory — and the domain has to match across half a dozen config
 fields, or logins silently fail. Doing that by hand is fiddly. `setup.sh`
 asks for your domain once, generates both apps' config with it filled in
 everywhere, registers the proxy as an OIDC client automatically, and
@@ -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
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 cp setup.env.example setup.env     # then edit setup.env: set CFG_DOMAIN to your domain
 ./setup.sh
 ```
@@ -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
-  host this stack can bring up (`CFG_JUMP_HOST_ENABLED=true`).
+- **[Jump Host](https://theta42.github.io/jump-host/)** — the SSH jump
+  host this stack brings up.
+- **[ldap-client](https://theta42.github.io/ldap-client/)** — enrolls Linux
+  hosts into the directory this stack serves.
@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Quickstart
-description: Step-by-step first run for theta-env — prerequisites, setup.env, and bringing up the stack with ./setup.sh.
+description: Step-by-step first run for theta-suite — prerequisites, setup.env, and bringing up the stack with ./setup.sh.
 ---

 # Quickstart Guide
@@ -26,8 +26,8 @@ description: Step-by-step first run for theta-env — prerequisites, setup.env,
 ## 1. Clone

 ```bash
-git clone --recursive https://github.com/theta42/theta-env.git
-cd theta-env
+git clone --recursive https://github.com/theta42/theta-suite.git
+cd theta-suite
 ```

 `--recursive` fetches the two submodules (`sso-manager-node`, `proxy`) in one
@@ -60,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>` |
+| `CFG_JUMP_HOST` | `jump.lab.local` | optional, defaults to `jump.<domain>` (the [SSH jump host](https://theta42.github.io/jump-host/) is installed + started by default) |
 | `JUMP_SSH_PORT` | `2222` | optional: host port for the jump host's SSH (never 22 by default) |

 `setup.env` is used **only on the first run** to generate `./config/`; after
@@ -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
@@ -1,12 +1,12 @@
 ---
 layout: default
 title: Secrets (OpenBao)
-description: theta-env's central secrets architecture — OpenBao as the single store for all app, per-user, and external-app secrets, with scoped tokens and policies.
+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-env keeps **every secret in one place: [OpenBao](https://openbao.org/)**
+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
@@ -60,7 +60,7 @@ 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-broker` | read/write `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`, `secret/plugins/*`; `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`) |
@@ -150,6 +150,31 @@ const data = await baoConf.get('apps/my-service/conf'); // secret/data/apps/my-s
 await baoConf.set('apps/my-service/conf', { db_password: '...' });
 ```

+## Plugin secrets
+
+The SSO Manager's plugin system (configurable plugin instances you create,
+edit, load/unload, and run from the **Plugins** page) stores each instance's
+secrets in its own OpenBao namespace, `secret/plugins/<instance-id>/conf`,
+rather than in the static `sso-secrets.js` `discovery.plugins` block. The
+SSO reads and writes these server-side through the `sso-broker` token (the
+plugin runs in-process as a BullMQ worker, so it needs no token of its own),
+and the admin UI only ever sees masked (`********`) values.
+
+- A **plugin type** is a module under `nodejs/plugins/<category>/<type>.js`
+  exporting a manifest (`configSchema` declares which fields are `secret`).
+- A **plugin instance** is a configured, loadable/unloadable copy of a type,
+  tracked in the `PluginInstance` table; you can have multiple instances of the
+  same type (e.g. two Proxmox endpoints with their own tokens).
+- Non-secret config lives in the DB row; only the `secret:true` field values
+  live in `secret/plugins/<instance-id>/conf`.
+
+Deleting an instance removes both the DB row and its `secret/plugins/<id>/*`
+namespace. Legacy `discovery.plugins` entries in `sso-secrets.js` are migrated
+to instances automatically on the first boot of SSO Manager ≥ v1.17.0 (the
+secret fields are copied into OpenBao at that point). See the SSO Manager
+[plugins docs](https://theta42.github.io/sso-manager-node/plugins.html) for the
+UI/API reference.
+
 ## Operator rotation

 If a secret is exposed (or just on a routine schedule), rotate it at the
@@ -192,4 +217,5 @@ re-mint the per-app tokens.
  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.
+  boot-critical `*-secrets.js` contents moved in this phase. (Plugin instance
+  secrets *are* in OpenBao, at `secret/plugins/<id>/conf` — see above.)
@@ -1,16 +1,23 @@
 ---
 layout: default
 title: Standalone
-description: Running the SSO Manager or the proxy on their own, without theta-env's orchestration.
+description: Running a component individually, without theta-suite's orchestration — an advanced path; the integrated stack is the supported one.
 ---

-# Running each project standalone
+# Running a component individually

 [← Back to Home](index.html)

-theta-env composes the two projects but doesn't fork them — both work on their
-own. The submodules in this repo are normal clones; you can also clone them
-directly from GitHub.
+> **The integrated stack is the supported path.** `./setup.sh` wiring all four
+> components together around a shared OpenBao secrets store is what's tested and
+> released. The steps below are for the advanced case where you want to run one
+> component on its own — a separate host, a different network, or without the
+> orchestrator. Running standalone means managing secrets from the
+> `config/*-secrets.js` file only (no shared OpenBao) and doing the OIDC/LDAP
+> wiring by hand.
+
+The submodules in this repo are normal clones; you can also clone them directly
+from GitHub. Each component builds and runs on its own.

 ---

@@ -114,10 +121,12 @@ See the proxy

 ---

-## Mixing and matching
+## Wiring components together by hand

-theta-env isn't required to use the two together — the four wiring steps are
-documented in both projects' deployment guides:
+If you have a specific reason to run the components on separate hosts instead
+of through `./setup.sh` (and accept that you lose the shared OpenBao secrets
+store), the four wiring steps are documented in both projects' deployment
+guides:

 1. One Docker network (or reachable hostnames) so the proxy can reach the SSO
   internally for token/userinfo + LDAPS.
@@ -129,8 +138,8 @@ documented in both projects' deployment guides:
 4. Point the proxy's `ldap.url` at the SSO's LDAPS + create a dedicated
   `cn=ldapclient` service account; set the same password as `bindPassword`.

-theta-env just automates those four steps with `./setup.sh`. If you prefer to
-do them by hand (or want the two on separate hosts), follow the standalone
-guides above.
+`./setup.sh` exists to do all of this for you — and to add the OpenBao secrets
+store, jump host, and ldap-client on top. Unless you need the components on
+separate hosts, prefer the integrated stack.

 [← Back to Home](index.html)
@@ -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 ───────────────────────────────────────────────────
-# Enable the theta42/jump-host component: a public SSH jump host that
-# authenticates users against the directory and bridges them to downstream
-# hosts (ssh uid_-_target@jump, or an interactive picker). Off by default.
-# When true, setup.sh clones/builds the jump-host submodule, the bootstrap
-# mints its directory API token + writes ./config/jump-secrets.js, and it's
-# registered in the proxy + directory. See jump-host's README for the LDAP
-# write-ACL note (the bundled deployment binds as cn=admin).
-#CFG_JUMP_HOST_ENABLED=false
+# ── SSH jump host (always installed) ─────────────────────────────────────────
+# The theta42/jump-host component is installed and started by default — a
+# public SSH jump host that authenticates users against the directory and
+# bridges them to downstream hosts (ssh uid_-_target@jump, or an interactive
+# picker). setup.sh clones/builds the jump-host submodule, the bootstrap mints
+# its directory API token + writes ./config/jump-secrets.js, and it's registered
+# in the proxy + directory. See jump-host's README for the LDAP write-ACL note
+# (the bundled deployment binds as cn=admin).
 #CFG_JUMP_HOST=jump.example.com   # defaults to jump.<domain>
 #JUMP_SSH_PORT=2222               # host port mapped to the jump host's SSH (never 22 by default)

@@ -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
@@ -141,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
@@ -151,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
@@ -161,26 +161,22 @@ then
 		AFTER_REV="$(git rev-parse HEAD)"
 		if [[ "$BEFORE_REV" != "$AFTER_REV" ]]; then
 			AFTER_VER="$(git describe --tags "$AFTER_REV" 2>/dev/null || echo "${AFTER_REV:0:12}")"
-			info "Updated theta-env (${BEFORE_VER} -> ${AFTER_VER}) — restarting setup.sh with the new version..."
-			THETA_ENV_REEXECED=1 exec "$0" "$@"
+			info "Updated theta-suite (${BEFORE_VER} -> ${AFTER_VER}) — restarting setup.sh with the new version..."
+			THETA_SUITE_REEXECED=1 exec "$0" "$@"
 		fi
 	else
-		warn "Could not fast-forward theta-env to the latest upstream (offline, or local changes) — continuing with the current checkout."
+		warn "Could not fast-forward theta-suite to the latest upstream (offline, or local changes) — continuing with the current checkout."
 	fi
 fi

-# ── Optional jump host: resolve the enable flag early ─────────────────────────
-# CFG_JUMP_HOST_ENABLED gates the optional SSH jump host (a third submodule).
-# Read it from the environment or ./setup.env now (before the submodule loop
-# and the compose steps) so every run knows whether to build/start it. The
-# authoritative CFG_* for secrets are still resolved in ensure_config; this is
-# only the on/off switch + its hostname.
+# ── Jump host hostname (always installed) ─────────────────────────────────────
+# The SSH jump host is a core component — always built + started (no longer
+# gated by CFG_JUMP_HOST_ENABLED). Read its optional hostname override from
+# ./setup.env now (before the submodule loop and the compose steps) so the
+# later steps can use it. The authoritative CFG_* for secrets are still
+# resolved in ensure_config; this is only the hostname override.
 [[ -f ./setup.env ]] && parse_kv_file ./setup.env
-JUMP_ENABLED=0
-case "${CFG_JUMP_HOST_ENABLED:-}" in 1|true|TRUE|yes|YES) JUMP_ENABLED=1 ;; esac
-export CFG_JUMP_HOST_ENABLED CFG_JUMP_HOST
-# When enabled, activate the compose profile so `up`/`ps` include the service.
-if [[ "$JUMP_ENABLED" == "1" ]]; then export COMPOSE_PROFILES="jump-host"; fi
+export CFG_JUMP_HOST

 # ── Optional outbound HTTP(S) proxy for docker build + the running containers ─
 # CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY (from ./setup.env or the
@@ -213,9 +209,8 @@ if [[ "${SKIP_SUBMODULE_UPDATE:-0}" != "1" ]]; then
 		die "git submodule update --init failed. Run manually: git submodule update --init --recursive"
 	fi

-	# jump-host is optional: only track/build it when enabled.
-	SUBMODULES=(sso-manager-node proxy)
-	[[ "$JUMP_ENABLED" == "1" ]] && SUBMODULES+=(jump-host)
+	# jump-host is a core component — always tracked + built.
+	SUBMODULES=(sso-manager-node proxy jump-host)
 	info "Updating submodules to their latest release tag (${SUBMODULES[*]})..."
 	for sm in "${SUBMODULES[@]}"; do
 		[[ -d "$sm" ]] || continue
@@ -570,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.
@@ -730,7 +725,15 @@ ensure_policy() {
 env_get() {
 	local key="$1" file=./.env
 	[[ -f "$file" ]] || return 0
-	grep -m1 "^${key}=" "$file" 2>/dev/null | cut -d= -f2-
+	# `|| 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`,
@@ -766,7 +769,9 @@ seed_app_conf() {
 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.
+# user-<uid> / app-<name> / sso-admin policies. secret/plugins/* holds per-instance
+# plugin secrets managed by the SSO plugin system (configurable plugin copies,
+# loaded/unloaded at runtime — see sso-manager-node docs/plugins.md).
 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"] }
@@ -774,6 +779,8 @@ path "secret/data/users/*" { capabilities = ["create", "read", "update", "delete
 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 "secret/data/plugins/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/plugins/*" { 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"] }
@@ -904,7 +911,6 @@ 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" \
@@ -984,35 +990,34 @@ NODEEOF
 ) || die "Registering hosts with the proxy failed:\n${HOSTS_OUT}"
 echo "$HOSTS_OUT" | sed 's/^/[setup] /'

-# ── 7b. Optional: build + start the SSH jump host ─────────────────────────────
-# Enabled by CFG_JUMP_HOST_ENABLED. The bootstrap (step 5) already wrote
-# ./config/jump-secrets.js (minted API token + LDAP admin bind). Build/start the
-# service (compose profile 'jump-host' is active), wait for its web /health, and
-# register its web UI hostname as a proxy Host so https://<JUMP_HOST> routes.
-if [[ "$JUMP_ENABLED" == "1" ]]; then
-	JUMP_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
-	JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
-	export JUMP_GIT_COMMIT
-	env_upsert JUMP_GIT_COMMIT "$JUMP_GIT_COMMIT"
-	# Seed jump-host/conf from the file bootstrap just wrote (it mints the API
-	# token + OAuth client into /config/jump-secrets.js at step 5). bootstrap
-	# also writes this to OpenBao directly, so this is a fallback for when
-	# bootstrap's jump provisioning warned-but-continued.
-	seed_app_conf jump-host/conf /config/jump-secrets.js
-	info "Building + starting jump-host (optional; enabled via CFG_JUMP_HOST_ENABLED)..."
-	"${COMPOSE[@]}" up -d --build jump-host
+# ── 7b. Build + start the SSH jump host ──────────────────────────────────────
+# The jump host is a core component (no longer optional). The bootstrap (step 5)
+# already wrote ./config/jump-secrets.js (minted API token + LDAP admin bind) and
+# mirrored it into OpenBao. Build/start the service, wait for its web /health,
+# and register its web UI hostname as a proxy Host so https://<JUMP_HOST> routes.
+JUMP_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
+JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
+export JUMP_GIT_COMMIT
+env_upsert JUMP_GIT_COMMIT "$JUMP_GIT_COMMIT"
+# Seed jump-host/conf from the file bootstrap just wrote (it mints the API
+# token + OAuth client into /config/jump-secrets.js at step 5). bootstrap also
+# writes this to OpenBao directly, so this is a fallback for when bootstrap's
+# jump provisioning warned-but-continued.
+seed_app_conf jump-host/conf /config/jump-secrets.js
+info "Building + starting jump-host..."
+"${COMPOSE[@]}" up -d --build jump-host

-	info "Waiting for jump-host to be healthy..."
-	for i in $(seq 1 60); do
-		if docker exec jump-host node -e "require('http').get('http://localhost:3002/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))" >/dev/null 2>&1; then
-			info "jump-host is healthy."; break
-		fi
-		if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
-		sleep 2
-	done
+info "Waiting for jump-host to be healthy..."
+for i in $(seq 1 60); do
+	if docker exec jump-host node -e "require('http').get('http://localhost:3002/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))" >/dev/null 2>&1; then
+		info "jump-host is healthy."; break
+	fi
+	if (( i == 60 )); then warn "jump-host did not become healthy in 120s. Check: ${COMPOSE[*]} logs jump-host"; break; fi
+	sleep 2
+done

-	info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
-	JUMP_HOSTS_OUT=$("${COMPOSE[@]}" exec -T proxy node <<NODEEOF || true
+info "Registering ${JUMP_HOST} (jump-host web UI) with the proxy..."
+JUMP_HOSTS_OUT=$("${COMPOSE[@]}" exec -T proxy node <<NODEEOF || true
 const {Host} = require('/app/models').models;
 (async () => {
 	try {
@@ -1027,8 +1032,7 @@ const {Host} = require('/app/models').models;
 })();
 NODEEOF
 )
-	echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'
-fi
+echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'

 # ── 8. Summary ───────────────────────────────────────────────────────────────
 echo
@@ -1038,11 +1042,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}"
@@ -1,7 +1,7 @@
 #!/bin/bash
 set -e

-echo "=== Starting theta-env Integration Tests ==="
+echo "=== Starting theta-suite Integration Tests ==="

 echo "=> Cleaning up any existing containers and volumes..."
 docker-compose down -v
@@ -11,7 +11,7 @@ echo "=> Running setup.sh to initialize environment..."
 # 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-env to test integration between all the include projects".
+# 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)"
Author	SHA1	Message	Date
wmantly	e2e8143880	Merge pull request #128 from theta42/release-v1.31.0 v1.31.0: roll up submodules to latest (sso v1.17.1 + ldap-client v1.23.0)	2026-08-01 21:26:55 -04:00
wmantly	aa01a5cc07	release: bump submodules to latest tags (v1.31.0) sso-manager-node v1.16.1 -> v1.17.1 (plugin system v1.17.0 + /conf secret masking v1.17.1). ldap-client v1.1.1 -> v1.23.0 (CHANGELOG-only, no code change). proxy v1.13.1 + jump-host v1.14.1 already latest, unchanged. Changelog embeds the full sso v1.17.0 + v1.17.1 release notes. Co-Authored-By: Claude <noreply@anthropic.com>	2026-08-01 21:26:13 -04:00
wmantly	1185bb90b8	Merge pull request #127 from theta42/feature/plugin-secrets-policy v1.30.1: grant sso-broker OpenBao access to secret/plugins/* (plugin-system prerequisite)	2026-08-01 20:50:20 -04:00
wmantly	403e66556c	feat: grant sso-broker OpenBao access to secret/plugins/* (v1.30.1) Prerequisite for the SSO Manager plugin system (shipped in sso-manager-node v1.17.0). Adds secret/data/plugins/* (CRUD+list) + secret/metadata/plugins/* (list/read/delete) to the sso-broker policy HCL so the SSO can store per-instance plugin secrets in OpenBao instead of sso-secrets.js. ensure_policy is idempotent, so re-running ./setup.sh grants the existing SSO_VAULT_TOKEN live. Docs: secrets.md (Plugin secrets section + policy row), architecture.md. Co-Authored-By: Claude <noreply@anthropic.com>	2026-08-01 20:33:21 -04:00
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