Repository navigation
Pass a store's licence token to the server, and say at boot when Intelligence will refuse memory - #771
Merged
Conversation
The chart emitted COPILOTKIT_LICENSE_TOKEN only when secrets.licenseToken was a literal. A token synced through externalSecrets, which ci/eks-values itself does, reached the Secret and never the pod, so a self-hosted deployment ran unlicensed with nothing saying why. openbot.licenseTokenSource now answers where the token comes from: the chart's own Secret, a store whose data names license-token, or an existingSecret the chart cannot read, where the reference is optional so a Secret without the key still starts. No source, no variable, as before for managed Intelligence. check-rendered-chart compared what containers demand with what the chart's own Secrets write, and not with what an ExternalSecret syncs. It now fails a render in which a store syncs a key nothing reads; with the old condition restored it fails eks and eks-sandbox on license-token.
A self-hosted Intelligence without its own licence answers every runtime entitlement read with RUNTIME_ENTITLEMENTS_SELF_HOSTED_MISCONFIGURED and refuses memory, while conversations carry on and OpenBot's log is silent. The licence belonging on Intelligence's deployment as well as OpenBot's is the part that is easy to miss. The server now reads the runtime entitlement once at start-up, without waiting on it, and logs intelligence-entitlement-not-ready with the code and the fix for misconfigured, expired and unavailable answers, or intelligence-entitlement-unreadable when Intelligence cannot be asked. The self-host banner reads the same answer but only while it is enabled, so it could not be the thing that reports this.
guidovizoso
requested review from
MikeRyanDev,
davidmckayv,
mxmzb and
tylerslaton
as code owners
October 12, 2026 16:47
…lement-warnings # Conflicts: # CHANGELOG.md
…lement-warnings # Conflicts: # CHANGELOG.md
#781 added openbot.secretKeySource for optional credentials, the same decision openbot.licenseTokenSource made for the licence alone: the chart's literal, a store that names the key, or an existingSecret referenced as optional. The licence now goes through it, and the licence-only helper is gone. Rendered output is unchanged in all five licence cases and on every ci target.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes from deploying OpenBot with self-hosted Intelligence on EKS. Each cost real time, and in both cases nothing reported the problem.
1. A licence token from a store never reached the server
The chart emitted
COPILOTKIT_LICENSE_TOKENonly whensecrets.licenseTokenwas a literal. WithexternalSecrets, whichci/eks-values.yamlitself uses withlicense-tokenin itsdata, the token reached the Secret and never the pod.openbot.licenseTokenSourcenow decides where the token comes from:secrets.licenseTokenliteralexternalSecrets.datanameslicense-tokensecrets.existingSecretoptional: trueref (new; the chart can't read that Secret's keys)Guard:
scripts/check-rendered-chart.tsonly compared demanded keys with Secrets the chart writes, not with what an ExternalSecret syncs. It now fails a render in which a store syncs a key nothing reads. With the old template condition restored, it failseksandeks-sandbox:With the fix, all five targets pass lint, render and the check.
2. A self-hosted Intelligence without its own licence refuses memory silently
That Intelligence answers every runtime entitlement read with
RUNTIME_ENTITLEMENTS_SELF_HOSTED_MISCONFIGURED. Memory is refused, conversations carry on, and OpenBot's log says nothing. The licence has to be on Intelligence's deployment as well as OpenBot's, and that's the part that's easy to miss.The server now reads the runtime entitlement once at boot, without waiting on it, and logs:
intelligence-entitlement-not-readywith the code, Intelligence's message, and a fix. The fix namesappApi.licenseSecret/externalSecrets.secrets.licensefor misconfigured, says to renew for expired, and calls managed-unavailable temporary.intelligence-entitlement-unreadablewhen Intelligence can't be asked.The self-host banner reads the same answer, but only while the banner is enabled, so it couldn't be the thing that reports this.
The docs (README, chart README,
values.yaml,configuration.md,deployment.md) now say the licence goes on both sides.Checks
intelligence-entitlement-check.test.ts, 8 tests: ready, inactive, misconfigured with fix text, expired, unknown code, logs once, silent when ready, unreachable doesn't throw. It passes together with the existingself-host-bannertests, 30 in all.tscand biome are clean.