manifest-llm-gateway-2.11.1

Chart 2.11.0 → 2.11.1 · appVersion 6.28.1 → 6.28.2

Upstream release notes: manifest@6.28.2

Changes

• feat(manifest-llm-gateway): update to upstream 6.28.2 (#65) (a96b91e)

  Chart version 2.11.0 -> 2.11.1, appVersion 6.28.1 -> 6.28.2.

Also changed: Chart.yaml

---

Chart documentation · Full diff

manifest-llm-gateway-2.9.0

Chart 2.8.2 → 2.9.0 · appVersion 6.25.5 → 6.26.0

Upstream release notes: manifest@6.26.0

Changes

• docs(manifest-llm-gateway): re-anchor the boot-path refusal on 6.26.0 (9068d68)

  Upstream 6.26.0 (#2979) makes migrate.js waiters poll pg_try_advisory_lock
  instead of blocking in pg_advisory_lock, which removes the hang the chart's
  explanation of the runMigrationsOnBoot refusal was built on. The refusal
  stands -- the boot path still takes no lock at all -- but README, values
  comment and the guard's message now say so instead of describing a lock
  cycle the boot path never had.

  The MANIFEST_PUBLIC_STATS row described aggregate /api/v1/public/*
  endpoints; 6.26.0 removed them, and the variable now gates only the
  published error pages.

• feat(manifest-llm-gateway): update to upstream 6.26.0 (8410b28)

  Chart version 2.8.2 -> 2.9.0, appVersion 6.25.5 -> 6.26.0.

Values

values.yaml diff

@@ -617,11 +617,13 @@ manifest:
 
   # -- Also apply migrations when the application boots
   # (`RUN_MIGRATIONS_ON_BOOT`). Off, because `migrations.job` already did it.
-  # Turning it on with more than one replica is refused: the boot path does not
-  # take the advisory lock the Job's entry point takes, and several pending
-  # migrations are a `CREATE INDEX CONCURRENTLY` that waits for the other
-  # replicas' sessions while those wait for the lock — a cycle PostgreSQL does
-  # not detect and does not break.
+  # Turning it on with more than one replica is refused: the boot path takes
+  # no lock at all, unlike the Job's entry point, so every replica applies the
+  # same pending migrations at once — and several of them are a
+  # `CREATE INDEX CONCURRENTLY` that waits for every other session on the table.
+  # Concurrent runners hung indefinitely on exactly those builds before
+  # appVersion 6.26.0 even with the lock; the upstream's fix covers the Job's
+  # entry point only.
   # @section -- Manifest: operations
   runMigrationsOnBoot: false
 

Also changed: Chart.yaml, README.md.gotmpl, templates/_helpers.tpl

---

Chart documentation · Full diff

manifest-llm-gateway-2.11.0

Chart 2.10.0 → 2.11.0 · appVersion 6.26.1 → 6.28.1

Upstream release notes: manifest@6.28.1

Changes

• feat(manifest-llm-gateway): update to upstream 6.28.1 (5ba7841)

  Chart version 2.10.0 -> 2.11.0, appVersion 6.26.1 -> 6.28.1.

  Nothing the chart models moved. The watched configuration files are
  unchanged, no migrations were added, and the code reads the same
  environment variables. 6.27.0 to 6.28.1 are provider routing fixes,
  Bedrock inference profiles and dashboard changes.

  This replaces the sync's original commit on this branch, which was cut
  from 6.25.5 and reused the published 2.9.0.

Also changed: Chart.yaml

---

Chart documentation · Full diff

manifest-llm-gateway-2.10.0

Chart 2.9.0 → 2.10.0 · appVersion 6.26.0 → 6.26.1

Upstream release notes: manifest@6.26.1

Changes

• chore(manifest-llm-gateway): name the source roots the audit scans (510152a)

  Adds charts.rgielen.de/upstream-source-roots (packages/backend/src), which
  chart_audit.py uses to find settings the upstream reads outside its
  documented sources (#64). The comment on upstream-config-sources no longer
  calls app.config.ts the authoritative list: 6.26.1 reads its new rate
  limits in the proxy's rate limiter. The watch-paths comment now sits on
  the annotation it describes.

  Annotation and comments only. No version bump: 2.10.0 has not been
  released yet.

• feat(manifest-llm-gateway): update to upstream 6.26.1 (a879d2e)

  Chart version 2.9.0 -> 2.10.0, appVersion 6.26.0 -> 6.26.1.

  6.26.1 turns the proxy's per-tenant and per-IP request limits, hardcoded
  at 200 and 500 requests per minute until now, into operator overrides
  (MANIFEST_RATE_MAX_REQUESTS, MANIFEST_IP_RATE_MAX_REQUESTS). They join
  MANIFEST_CONCURRENCY_MAX under manifest.proxy with the upstream defaults,
  and the replica table names all three: each is enforced per process.

  The schema requires a positive integer. The upstream falls back to its
  default on anything else, so a typo would otherwise disable the override
  without a word.

  This replaces the sync's original commit on this branch, which was cut
  from 6.25.5 before 2.9.0 shipped and reused that version number.

Values

values.yaml diff

@@ -442,6 +442,16 @@ manifest:
     # (`MANIFEST_CONCURRENCY_MAX`).
     # @section -- Manifest: LLM proxy
     concurrencyMax: 10
+    # -- Per-tenant limit of proxy requests per minute per backend process
+    # (`MANIFEST_RATE_MAX_REQUESTS`). Exceeding it answers HTTP 429 with error
+    # code M201.
+    # @section -- Manifest: LLM proxy
+    rateMaxRequests: 200
+    # -- Per-client-IP limit of proxy requests per minute per backend process
+    # (`MANIFEST_IP_RATE_MAX_REQUESTS`). Exceeding it answers HTTP 429 with
+    # error code M202.
+    # @section -- Manifest: LLM proxy
+    ipRateMaxRequests: 500
 
   # -- Base URL of a locally reachable Ollama or other OpenAI-compatible server
   # (`OLLAMA_HOST`), for example `http://ollama.ai.svc.cluster.local:11434`.

Also changed: Chart.yaml, README.md.gotmpl, templates/_helpers.tpl, values.schema.json

---

Chart documentation · Full diff

manifest-llm-gateway-2.8.2

Chart 2.8.1 → 2.8.2 · appVersion 6.25.2 → 6.25.5

Upstream release notes: manifest@6.25.5

Changes

• feat(manifest-llm-gateway): let plain http boot again, as 6.25.5 does (3c53fa4)

  Up to appVersion 6.25.2 the upstream built Better Auth's MCP plugin
  unconditionally. That plugin derives its resource URL from BETTER_AUTH_URL and
  rejects a non-HTTPS one while the module loads, so the process exited before it
  listened and the pod never left CrashLoopBackOff. The chart refused to render
  such a configuration rather than let anyone find out that way.

  6.25.3 added auth/mcp-availability.ts, which makes that decision before the
  plugin is constructed: an install on a plain-http LAN or tailnet host boots,
  serves the dashboard and the gateway, and simply has no MCP surface. The chart's
  guard therefore now rejects a configuration the upstream supports, so it goes.
  NOTES.txt reports what is actually left -- no HSTS, no remote MCP -- and only
  suggests the setting that would help when it is not already set.

  ci/http-lan-values.yaml holds the chart to that: an http:// publicUrl on a host
  that is not loopback has to render and come up healthy. Should the upstream ever
  go back to constructing the plugin unconditionally, ct install fails there, and
  nowhere else in the matrix would notice.

  Two settings 6.25.5 adds, both operational and neither gated by deployment mode:

  (shortened — full message)

• feat(manifest-llm-gateway): update to upstream 6.25.5 (d52a879)

  Chart version 2.8.1 -> 2.8.2, appVersion 6.25.2 -> 6.25.5.

Values

values.yaml diff

@@ -277,10 +277,13 @@ manifest:
   # -- Public URL the dashboard is reached at (`BETTER_AUTH_URL`). Must match
   # what the browser actually uses, or logins and OAuth callbacks break. No
   # trailing slash — the application appends paths such as `/api/auth/...` to
-  # this value. **Must be `https://`** unless it is a loopback address: since
-  # appVersion 6.24.0 the upstream builds its MCP resource URL from this value
-  # and refuses a non-HTTPS one while loading, so a plain-http host leaves the
-  # pod in CrashLoopBackOff. The chart refuses to render that instead.
+  # this value. Prefer `https://`, but plain http on a LAN or tailnet host is
+  # supported: up to appVersion 6.25.2 it left the pod in CrashLoopBackOff,
+  # because the upstream derived its MCP resource URL from this value and the
+  # MCP plugin rejects a non-HTTPS one while loading. Since 6.25.3 the upstream
+  # decides before building that plugin, so such an install boots and simply
+  # serves no MCP endpoint. What remains on plain http: no HSTS (see
+  # `disableHsts`) and no remote MCP (see `mcpEnabled`).
   # @default -- derived from the first `ingress.hosts` entry when an Ingress is enabled
   # @section -- Manifest: core
   publicUrl: ""
@@ -299,6 +302,17 @@ manifest:
   # @section -- Manifest: core
   disableHsts: false
 
+  # -- Serve the remote MCP endpoint at `/api/v1/mcp`, with its OAuth endpoints
+  # (`MCP_ENABLED`). On by default, and the upstream switches it off by itself
+  # when `publicUrl` is plain http on a host that is not loopback — the MCP
+  # resource URL is derived from `publicUrl` and `@better-auth/mcp` accepts only
+  # HTTPS or loopback — naming the reason on every boot. Set this to false to
+  # acknowledge that, or to close the MCP surface on an install that could serve
+  # it. Only a falsey string disables it upstream, which is what `false` here
+  # becomes.
+  # @section -- Manifest: core
+  mcpEnabled: true
+
   # -- Extra browser origins allowed to call the gateway
   # (`WINGMAN_CORS_ORIGINS`). Joined with commas.
   # @section -- Manifest: core
@@ -568,11 +582,14 @@ manifest:
       # @section -- Manifest: operations
       backoffLimit: 3
       # -- Hard timeout for the whole Job. A first migration on an empty
-      # database builds every index and is not instant. Raise it for
-      # `manifest.mode: cloud`: the upstream's cloud-only migrations build
-      # indexes on `requests` with `CREATE INDEX CONCURRENTLY` and budget
-      # minutes for one of them. Under `selfhosted` they return without
-      # touching the schema, which is why the default fits.
+      # database builds every index and is not instant. Since appVersion 6.25.3
+      # several migrations build indexes on `requests` and `agent_messages` with
+      # `CREATE INDEX CONCURRENTLY`, and the upstream deliberately does **not**
+      # gate them by deployment mode — the dashboard and retention queries they
+      # serve run self-hosted too. The default fits a small database, where
+      # those builds finish in seconds. Raise it for a large one, whatever
+      # `manifest.mode` is set to; upstream budgets minutes per index on tables
+      # of millions of rows.
       # @section -- Manifest: operations
       activeDeadlineSeconds: 900
       # -- Resource requests and limits for the migration pod.
@@ -601,13 +618,34 @@ manifest:
   # -- Also apply migrations when the application boots
   # (`RUN_MIGRATIONS_ON_BOOT`). Off, because `migrations.job` already did it.
   # Turning it on with more than one replica is refused: the boot path does not
-  # take the advisory lock the Job's entry point takes, and one pending
-  # migration is a `CREATE INDEX CONCURRENTLY` that waits for the other
+  # take the advisory lock the Job's entry point takes, and several pending
+  # migrations are a `CREATE INDEX CONCURRENTLY` that waits for the other
   # replicas' sessions while those wait for the lock — a cycle PostgreSQL does
   # not detect and does not break.
   # @section -- Manifest: operations
   runMigrationsOnBoot: false
 
+  agentUsage:
+    # -- Run the per-agent daily usage rollup worker
+    # (`AGENT_USAGE_DAILY_WORKER`). Since appVersion 6.25.3 the dashboard's
+    # agent usage figures are aggregated into `agent_usage_daily` by a job that
+    # fires every minute, instead of being queried from the raw request tables.
+    # It is not gated by deployment mode, so it runs here too. Set false to
+    # pause it — reads then fall back to the raw tables, which is correct but
+    # slower on a large database.
+    # @section -- Manifest: operations
+    dailyWorker: true
+    # -- Rows the worker claims per source table per run
+    # (`AGENT_USAGE_DAILY_BATCH_SIZE`). Lower it to spread the initial backfill
+    # of an existing database over more, smaller transactions.
+    # @section -- Manifest: operations
+    batchSize: 250
+    # -- Work budget in ms for each one-minute run
+    # (`AGENT_USAGE_DAILY_RUN_BUDGET_MS`). The worker stops claiming batches
+    # once it is spent and resumes on the next tick.
+    # @section -- Manifest: operations
+    runBudgetMs: 5000
+
   # -- Grace period in ms to finish in-flight requests after SIGTERM
   # (`SHUTDOWN_DRAIN_MS`). Keep `terminationGracePeriodSeconds` above it.
   # @section -- Manifest: operations

Also changed: Chart.yaml, README.md.gotmpl, ci/full-values.yaml, ci/http-lan-values.yaml, templates/NOTES.txt, templates/_helpers.tpl, values.schema.json

---

Chart documentation · Full diff

manifest-llm-gateway-2.8.1

Chart 2.8.0 → 2.8.1 · appVersion 6.25.2

Changes

• fix(manifest-llm-gateway): let the allow-list take what the upstream takes (#55) (bc4b9d7)

  Two findings from the review of #54, both reproduced before being believed.

  The schema rejected a host the upstream accepts. parseOriginHost() runs its
  input through new URL(), which parses https://[::1] and [::1]:8443 to the
  hosts [::1] and [::1]:8443 -- but the pattern allowed neither brackets nor
  the colons inside them, so the chart refused to render a configuration that
  would have worked. A schema that exists to catch typos must not reject valid
  input; the pattern now has a bracketed-literal alternative beside the name one.
  It also dropped % and ~ from the name class: new URL() throws on
  https://bad%host, so the upstream would have discarded it silently, which is
  the exact failure this pattern is here to prevent.

  (shortened — full message)

Values

values.yaml diff

@@ -310,7 +310,8 @@ manifest:
   # `publicUrl` — but only for hosts listed here; any other host is sent through
   # `publicUrl` and leaves its cookie on an origin the browser will not send
   # back. Entries are hostnames with an optional port, or full origins (the
-  # scheme is ignored), and `*.example.com` wildcards are accepted. Leave empty
+  # scheme is ignored), and `*.example.com` wildcards are accepted; an IPv6
+  # literal has to be bracketed, `[::1]`, as the upstream's URL parser wants it. Leave empty
   # for the usual single-host install: with one host known the upstream keeps
   # the static origin, which is what it did before 6.25.2. The remote MCP
   # endpoint stays bound to `publicUrl` either way.

Also changed: Chart.yaml, templates/NOTES.txt, values.schema.json

---

Chart documentation · Full diff

manifest-llm-gateway-2.8.0

Chart 2.7.1 → 2.8.0 · appVersion 6.25.2

Changes

• feat(manifest-llm-gateway): model the multi-host auth 6.25.2 adds (#54) (f25e8d3)

  ingress.hosts is a list, but publicUrl is one origin and Better Auth pins
  both the OAuth callback and the session cookie to it. Until now a login that
  started on a second host was redirected to a callback on publicUrl and left
  its cookie on an origin the second host's dashboard never sends back -- a login
  that does not stick, with nothing in the logs to say why, and no setting that
  helped.

  6.25.2 adds one: buildAuthBaseURL() in packages/backend/src/auth/auth.instance.ts
  resolves the base URL from the request host, restricted to an allow-list fed by
  BETTER_AUTH_URL, CORS_ORIGIN and the new BETTER_AUTH_ALLOWED_HOSTS.
  manifest.authAllowedHosts is that variable, joined with commas like
  corsOrigins.

  Three things the modelling rests on, all checked against the upstream rather
  than its changelog:

  (shortened — full message)

Values

values.yaml diff

@@ -304,6 +304,19 @@ manifest:
   # @section -- Manifest: core
   corsOrigins: []
 
+  # -- Further hosts this release answers on, besides the one in `publicUrl`
+  # (`BETTER_AUTH_ALLOWED_HOSTS`). Joined with commas. Since appVersion 6.25.2
+  # the OAuth callback and the session cookie follow the request host instead of
+  # `publicUrl` — but only for hosts listed here; any other host is sent through
+  # `publicUrl` and leaves its cookie on an origin the browser will not send
+  # back. Entries are hostnames with an optional port, or full origins (the
+  # scheme is ignored), and `*.example.com` wildcards are accepted. Leave empty
+  # for the usual single-host install: with one host known the upstream keeps
+  # the static origin, which is what it did before 6.25.2. The remote MCP
+  # endpoint stays bound to `publicUrl` either way.
+  # @section -- Manifest: core
+  authAllowedHosts: []
+
   # -- Name of an existing Secret holding sensitive settings. Its keys are the
   # upstream environment variable names (`BETTER_AUTH_SECRET`, `DATABASE_URL`,
   # `EMAIL_API_KEY`, ...) and it is mounted with `envFrom`. Takes precedence

Also changed: Chart.yaml, README.md.gotmpl, ci/full-values.yaml, templates/NOTES.txt, templates/_helpers.tpl, values.schema.json

---

Chart documentation · Full diff

manifest-llm-gateway-2.7.1

Chart 2.7.0 → 2.7.1 · appVersion 6.25.1 → 6.25.2

Upstream release notes: manifest@6.25.2

Changes

• feat(manifest-llm-gateway): update to upstream 6.25.2 (8e4f1d6)

  Chart version 2.7.0 -> 2.7.1, appVersion 6.25.1 -> 6.25.2.

Also changed: Chart.yaml

---

Chart documentation · Full diff

manifest-llm-gateway-2.7.0

Chart 2.6.0 → 2.7.0 · appVersion 6.24.0 → 6.25.1

Upstream release notes: manifest@6.25.1

Changes

• feat(manifest-llm-gateway): update to upstream 6.25.1 (3fc45e0)

  Chart version 2.6.0 -> 2.7.0, appVersion 6.24.0 -> 6.25.1.

Also changed: Chart.yaml

---

Chart documentation · Full diff

manifest-llm-gateway-2.6.0

Chart 2.5.1 → 2.6.0 · appVersion 6.23.4 → 6.24.0

Upstream release notes: manifest@6.24.0

Changes

• fix(manifest-llm-gateway): refuse a public URL 6.24.0 cannot boot with (9433070)

  ct install caught this on ci/full-values.yaml, and the sync workflow's own
  verify job had already refused to merge the bump at 05:26 for the same reason.
  The pod never listens:

  TypeError: MCP resource URL must use HTTPS, except for localhost or
  loopback IP development URLs
      at validateMcpResource (@better-auth/mcp/dist/index.mjs:25)
      at buildPlugins (packages/backend/dist/auth/auth.instance.js:60)
  

  6.24.0 wires Better Auth's MCP plugin unconditionally -- the upstream says so
  in as many words, "These are always on, unlike billing" -- and builds its
  resource URL out of BETTER_AUTH_URL (auth.instance.ts:37,42), which is this
  chart's manifest.publicUrl. The plugin validates that URL while the module
  loads, so a plain-http host kills the process before it listens. There is no
  switch to turn the plugin off.

  (shortened — full message)

• feat(manifest-llm-gateway): model the CLI token lifetimes 6.24.0 adds (3cd2229)

  6.24.0 adds CLI_TOKEN_TTL_DAYS and CLI_TOKEN_ABSOLUTE_TTL_DAYS, the lifetime
  of a management token minted by the CLI: a sliding window renewed on every
  authentication, and an absolute ceiling from issuance that finally retires a
  token in constant use. Both apply here -- the four migrations that come with
  the feature carry no isSelfHosted() gate, so the CLI login flow exists in a
  self-hosted install like this one, and token lifetime is an operator's
  decision, not the upstream's.

  Modelled as manifest.cliToken.ttlDays and .absoluteTtlDays, empty by default
  so the upstream's own 30 and 90 apply until someone decides otherwise. The
  schema takes the shape used for recordings.retentionDays -- empty, or an
  integer of at least 1 -- because upstream parses these with
  optionalPositiveInteger: 0 and 30d are silently discarded and the default
  applies, which would leave an operator believing they had set a lifetime they
  had not. Refused at install time instead.

  (shortened — full message)

• feat(manifest-llm-gateway): update to upstream 6.24.0 (f66d64d)

  Chart version 2.5.1 -> 2.6.0, appVersion 6.23.4 -> 6.24.0.

Values

values.yaml diff

@@ -277,8 +277,10 @@ manifest:
   # -- Public URL the dashboard is reached at (`BETTER_AUTH_URL`). Must match
   # what the browser actually uses, or logins and OAuth callbacks break. No
   # trailing slash — the application appends paths such as `/api/auth/...` to
-  # this value. Serve it over https wherever it is reachable from the internet:
-  # the application only sends HSTS for an `https://` origin.
+  # this value. **Must be `https://`** unless it is a loopback address: since
+  # appVersion 6.24.0 the upstream builds its MCP resource URL from this value
+  # and refuses a non-HTTPS one while loading, so a plain-http host leaves the
+  # pod in CrashLoopBackOff. The chart refuses to render that instead.
   # @default -- derived from the first `ingress.hosts` entry when an Ingress is enabled
   # @section -- Manifest: core
   publicUrl: ""
@@ -345,6 +347,22 @@ manifest:
   # @section -- Manifest: core
   apiKey: ""
 
+  cliToken:
+    # -- Sliding lifetime in days of a management token minted by the CLI
+    # (`CLI_TOKEN_TTL_DAYS`). Every successful authentication pushes the token's
+    # expiry this far out, so a CLI in regular use never has to log in again
+    # while an abandoned one lapses. Empty for the upstream default of 30.
+    # @section -- Manifest: core
+    ttlDays: ""
+    # -- Hard ceiling in days from issuance (`CLI_TOKEN_ABSOLUTE_TTL_DAYS`).
+    # The sliding window above renews on every use, so this is what finally
+    # retires a token that is in constant use. Empty for the upstream default
+    # of 90; set below `ttlDays` it retires tokens before the sliding window
+    # ever matters. Both take a plain positive integer -- upstream ignores `0`
+    # and anything like `30d`, and silently applies its own default instead.
+    # @section -- Manifest: core
+    absoluteTtlDays: ""
+
   database:
     # -- PostgreSQL connection string (`DATABASE_URL`), for example
     # `postgresql://manifest:secret@postgres.databases.svc:5432/manifest`.

Also changed: Chart.yaml, README.md.gotmpl, ci/full-values.yaml, templates/_helpers.tpl, values.schema.json

---

Chart documentation · Full diff