From 82e9aba45bcd1d6652c1f855088f5c0f6b350b87 Mon Sep 17 00:00:00 2001 From: Derek Date: Tue, 29 Sep 2026 23:23:48 +1000 Subject: [PATCH 1/2] fix: say what seeds a HyperDX team, not the engine's service token The docs and a compose comment said the engine's service token seeds the default team with its connection and sources before anyone logs in. It never did: the engine gives the service identity no ClickHouse connection, so that team stays empty. A team is seeded from the engine's answer for its members, on their first login. --- docker-compose.yml | 4 ++-- docs/configuration.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docker-compose.yml b/docker-compose.yml index 05ee259..a52093c 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -1140,8 +1140,8 @@ services: # lands root-owned and the engine runs as UID 1000. DFE_GITOPS_ENABLED: ${DFE_GITOPS_ENABLED:-true} DFE_GITOPS_LOCAL_PATH: ${DFE_ENGINE_CONFIG_DIR:-/app/config}/deploy-repo - # HyperDX's control surface: the engine confirms the fork's default team and - # seeds its connections and sources. Both follow the resolved footprint + # HyperDX's control surface: the engine fans the sources it deploys onto + # every HyperDX team. Both follow the resolved footprint # (scripts/resolve_profile.py), so one DFE_HYPERDX_ENABLED governs the # HyperDX containers and the engine that drives them. DFE_HYPERDX_ENABLED: ${DFE_HYPERDX_RESOLVED:-false} diff --git a/docs/configuration.md b/docs/configuration.md index d8cd90c..c45b787 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -308,7 +308,7 @@ Off by default. `DFE_OTEL_ENABLED=true` (or a profile declaring `otel: true`, as Off by default. `DFE_HYPERDX_ENABLED=true` starts `hyperdx` (API + App), the `dfe-hyperdx-proxy` that fronts both origins, a one-shot `dfe-dashboards` that copies the engine's shipped dashboards into a volume, plus `hyperdx-ferretdb` and `hyperdx-postgres`, sharing the always-on ClickHouse. -HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how the team gets seeded with the connection and sources from `config/hyperdx/default-sources.json` before anyone logs in, and how a source added through the console reaches HyperDX at all. +HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how a source added through the console reaches every HyperDX team. That token's team, `DFE_HYPERDX_TEAM`, holds no connection and no sources, because the engine gives the service identity no ClickHouse connection. Every other team gets its connection and sources on its members' first login, from the engine's answer for that member: `main` and `hunts` everywhere, plus the otel and `clickhouse_system` sources on a platform team, and the shipped dashboards those sources can render. From hyperi-io/dfe-hyperdx#106 on, a login the engine gives no connection is retried on a later request. `config/hyperdx/default-sources.json` seeds nothing in `oidc-proxy` mode, only in `header-dev`. The same toggle points the engine at HyperDX: with it on, the engine receives `DFE_HYPERDX_ENABLED=true` and `DFE_HYPERDX_BASE_URL=http://hyperdx:8000`, so its `/api/v1/hyperdx/*` surface answers instead of returning `503 hyperdx_absent`. From f08af5c00da800547412aed8bbfc1d8ea1c2eff2 Mon Sep 17 00:00:00 2001 From: Derek Date: Tue, 29 Sep 2026 23:25:29 +1000 Subject: [PATCH 2/2] fix: name the mechanism that leaves the service token's team empty HyperDX never seeds from the service token at all, so that is the reason to give, not what the engine would answer if it were asked. --- docs/configuration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/configuration.md b/docs/configuration.md index c45b787..bad15ee 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -308,7 +308,7 @@ Off by default. `DFE_OTEL_ENABLED=true` (or a profile declaring `otel: true`, as Off by default. `DFE_HYPERDX_ENABLED=true` starts `hyperdx` (API + App), the `dfe-hyperdx-proxy` that fronts both origins, a one-shot `dfe-dashboards` that copies the engine's shipped dashboards into a volume, plus `hyperdx-ferretdb` and `hyperdx-postgres`, sharing the always-on ClickHouse. -HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how a source added through the console reaches every HyperDX team. That token's team, `DFE_HYPERDX_TEAM`, holds no connection and no sources, because the engine gives the service identity no ClickHouse connection. Every other team gets its connection and sources on its members' first login, from the engine's answer for that member: `main` and `hunts` everywhere, plus the otel and `clickhouse_system` sources on a platform team, and the shipped dashboards those sources can render. From hyperi-io/dfe-hyperdx#106 on, a login the engine gives no connection is retried on a later request. `config/hyperdx/default-sources.json` seeds nothing in `oidc-proxy` mode, only in `header-dev`. +HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how a source added through the console reaches every HyperDX team. That token's team, `DFE_HYPERDX_TEAM`, holds no connection and no sources, because HyperDX seeds a team only from a person's login, never from the service token. Every other team gets its connection and sources on its members' first login, from the engine's answer for that member: `main` and `hunts` everywhere, plus the otel and `clickhouse_system` sources on a platform team, and the shipped dashboards those sources can render. From hyperi-io/dfe-hyperdx#106 on, a login the engine gives no connection is retried on a later request. `config/hyperdx/default-sources.json` seeds nothing in `oidc-proxy` mode, only in `header-dev`. The same toggle points the engine at HyperDX: with it on, the engine receives `DFE_HYPERDX_ENABLED=true` and `DFE_HYPERDX_BASE_URL=http://hyperdx:8000`, so its `/api/v1/hyperdx/*` surface answers instead of returning `503 hyperdx_absent`.