feat(control-plane): wire tenant containers to the central PostHog key

[jeffrey701]

What

Wire the hosted fleet to report to the central PostHog project (#7875): every tenant container
the control-plane starts now carries the central project key, so the self-host image's own error
tracking points at the loopover-owned project instead of nothing. Reuses the existing tenant-env
injection seam (the same mechanism PINNED_VERSION_ENV_VAR #4898 and TENANT_SECRET_ENV_VAR
#8202 already use) rather than inventing a new one — the key is a control-plane secret, injected
into envVars at the single point in a container's lifecycle where env vars are applied.

Change (control-plane/ only, additive)

• container-driver.ts: new CENTRAL_POSTHOG_KEY_ENV_VAR (LOOPOVER_CENTRAL_POSTHOG_KEY,
  product-agnostic like its siblings) + optional centralPosthogKey on ContainerDriverConfig.
  createTenantContainer injects it into envVars when set, merged with any per-tenant vars.
• driver-factory.ts: threads env.CENTRAL_POSTHOG_KEY (via the existing nonBlank guard)
  into the real container driver's config; blank/unset ⇒ omitted.
• worker.ts: forwards env.CENTRAL_POSTHOG_KEY into createTenantProvisioningDriver.
• env.d.ts: declares the CENTRAL_POSTHOG_KEY? secret.
• index.ts: re-exports the new env-var constant.

Absent key ⇒ byte-identical tenant behavior (no env var injected). Self-host / operator-set
key behavior is untouched — this is additive for the hosted path only.

Validation

• New tests: the key rides into a container as CENTRAL_POSTHOG_KEY_ENV_VAR; it merges with
  pinned-version + bootstrap-secret vars into one start() call; createTenantProvisioningDriver
  threads it from env; a blank value is omitted (tenant start byte-identical).
• npm run control-plane:test → 205/205 pass (build + node:test). Both branches of the new
  key-present / key-absent logic covered.

Closes #7876

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.99%. Comparing base (6b1eb63) to head (7ad16a6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8601      +/-   ##
==========================================
- Coverage   92.54%   91.99%   -0.56%     
==========================================
  Files         796      796              
  Lines       79855    79874      +19     
  Branches    24136    24138       +2     
==========================================
- Hits        73905    73479     -426     
- Misses       4804     5312     +508     
+ Partials     1146     1083      -63     

Flag	Coverage Δ
backend	92.94% <ø> (-0.78%)	⬇️
control-plane	99.85% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
control-plane/src/container-driver.ts	100.00% <100.00%> (ø)
control-plane/src/driver-factory.ts	100.00% <100.00%> (ø)
control-plane/src/index.ts	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-25 02:19:52 UTC}

7 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a clean, additive plumbing PR: a new optional `centralPosthogKey` config value is threaded from `env.CENTRAL_POSTHOG_KEY` through `driver-factory.ts` and `worker.ts` into `container-driver.ts`, which injects it as `LOOPOVER_CENTRAL_POSTHOG_KEY` into every tenant container's `envVars`, merged correctly with the existing pinned-version and bootstrap-secret vars. The `nonBlank` guard and the `if (config.centralPosthogKey)` check correctly make an absent/blank key a no-op, preserving byte-identical tenant behavior, and the new tests cover both the present and blank-key paths as well as merging with per-tenant vars. One thing worth flagging: the container-driver.ts comment itself admits the self-host image doesn't yet read this env var ('once its Phase-1 init lands'), so this PR wires a value that nothing currently consumes — pure plumbing ahead of its consumer, which is fine if that's the intended incremental rollout.

Nits — 5 non-blocking

• The linked-issue metadata for Wire hosted control-plane + tenant containers to report to the central PostHog project (implements #4934) #7876 in the review brief describes 'wire hosted control-plane + tenant containers to report to the central Sentry DSN,' which doesn't match this PR's PostHog framing — worth confirming Wire hosted control-plane + tenant containers to report to the central PostHog project (implements #4934) #7876 is actually the right issue for a PostHog (not Sentry) key before merging, since issue-scope is enforced here.
• container-driver.ts:44-47's new doc comment references a not-yet-landed 'Phase-1 init' on the self-host image; until that consumer exists this env var is inert — fine for staged rollout but worth a one-line callout in the PR description that this is pure plumbing with no current consumer.
• driver-factory.ts:80's conditional spread `...(centralPosthogKey ? { centralPosthogKey } : {})` is a bit more indirect than just always passing `centralPosthogKey` (which would be `undefined` when absent and behave identically given `container-driver.ts`'s `if (config.centralPosthogKey)` check) — not wrong, just an extra pattern to maintain versus the plainer alternative.
• Confirm the issue link (Wire hosted control-plane + tenant containers to report to the central PostHog project (implements #4934) #7876) actually matches this PostHog-key change rather than a Sentry DSN as the retrieved issue title suggests, and correct the 'Closes' reference if it's stale.
• Consider simplifying driver-factory.ts:80 to always pass `centralPosthogKey` (possibly `undefined`) into `createContainerDriver` rather than conditionally spreading, since `container-driver.ts`'s own truthy check already handles the absent case.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7876
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 74 registered-repo PR(s), 34 merged, 18 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 74 PR(s), 18 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: minor

Linked issue satisfaction

Partially addressed
The PR wires the central PostHog key as an env var into every tenant container's start() call, which addresses the AMS tenant container piece of the deliverable, but it does not touch the hosted control-plane itself (no PostHog init in the control-plane worker) nor the hosted ORB Worker's own raw-capture init pattern, and self-host's own consumption of the injected env var to actually initialize P

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 74 PR(s), 18 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.