feat(webapp): share rate limit bucket across additional API keys per environment

[carderne]

What

Rate-limit the API by environment rather than per API key.

Previously the limiter keyed its bucket on the hash of the full Authorization header — one bucket per key. With additional environment API keys (tr_*_sk_*), an environment can mint many keys and each got its own full bucket, so more keys = higher effective rate limit. This collapses all of an environment's keys onto a single shared per-environment bucket, so the ceiling is exactly the configured limit regardless of key mix.

How

• authorizationRateLimitMiddleware now lets the override return { config?, identifier? }. identifier, when present, is the rate limit bucket key; otherwise it falls back to the hashed Authorization header (unchanged legacy behavior, still used by engineRateLimiter and any unauthenticated fallthrough).
• apiRateLimiter's override resolves the environment id and uses it as the identifier:
  • Additional keys (isAdditionalApiKey) resolve via a new resolveAdditionalApiKeyRateLimitScope() — a scope-agnostic keyHash → (environmentId, org limiter config) lookup. It is deliberately permissive (restricted keys resolve too) because it's used only for bucketing, never as an auth decision — request auth still goes through the RBAC bearer controller, which enforces scopes. Revoked/expired keys are excluded so they can't hold a bucket warm.
  • Root/legacy keys reuse the environment already resolved by authenticateAuthorizationHeader and key on environment.id too.
• The identifier is always the stable environment id, never the secret key (which can rotate and would split the bucket).
• The whole override result is cached per key by the existing SWR cache, so no extra per-request lookup and no separate Redis mapping is added.

Behavior notes

• Root + additional keys of the same environment now share one bucket (ceiling = configured limit, not a multiple of it). Restricted additional keys are included — they were the biggest gap, since they authenticate via the RBAC controller and previously fell back to per-key buckets.
• Public JWTs keep their existing fixed-window, per-token bucketing.
• One-time bucket reset on deploy (bucket keys change); harmless.

Tests

• New: two tokens resolving to the same identifier share one bucket.
• New: with no identifier, bucketing stays per-key (legacy behavior preserved).
• Updated existing override tests to the new { config } return shape.

Base: feat/multi-keys-surface. Closes TRI-12888.

[changeset-bot]

🦋 Changeset detected

Latest commit: e9ae728

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 27 packages

Name	Type
@trigger.dev/sdk	Patch
@trigger.dev/python	Patch
@internal/dashboard-agent	Patch
@internal/sdk-compat-tests	Patch
@trigger.dev/build	Patch
@trigger.dev/core	Patch
@trigger.dev/react-hooks	Patch
@trigger.dev/redis-worker	Patch
@trigger.dev/rsc	Patch
@trigger.dev/schema-to-json	Patch
@trigger.dev/database	Patch
@trigger.dev/otlp-importer	Patch
@trigger.dev/rbac	Patch
@trigger.dev/sso	Patch
trigger.dev	Patch
@internal/cache	Patch
@internal/clickhouse	Patch
@internal/llm-model-catalog	Patch
@internal/metrics-pipeline	Patch
@internal/redis	Patch
@internal/replication	Patch
@internal/run-engine	Patch
@internal/run-store	Patch
@internal/schedule-engine	Patch
@internal/testcontainers	Patch
@internal/tracing	Patch
@internal/tsql	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8d8e390b-6b3b-4285-8ea5-da8f3d06070b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

@trigger.dev/build

npm i https://pkg.pr.new/@trigger.dev/build@316db63

trigger.dev

npm i https://pkg.pr.new/trigger.dev@316db63

@trigger.dev/core

npm i https://pkg.pr.new/@trigger.dev/core@316db63

@trigger.dev/python

npm i https://pkg.pr.new/@trigger.dev/python@316db63

@trigger.dev/react-hooks

npm i https://pkg.pr.new/@trigger.dev/react-hooks@316db63

@trigger.dev/redis-worker

npm i https://pkg.pr.new/@trigger.dev/redis-worker@316db63

@trigger.dev/rsc

npm i https://pkg.pr.new/@trigger.dev/rsc@316db63

@trigger.dev/schema-to-json

npm i https://pkg.pr.new/@trigger.dev/schema-to-json@316db63

@trigger.dev/sdk

npm i https://pkg.pr.new/@trigger.dev/sdk@316db63

commit: 316db63

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🟡 Newly created or revoked API keys can be missing from the list right after the change

The API keys page now reads its data from a replica database ($replica default at apps/webapp/app/presenters/v3/ApiKeysPresenter.server.ts:22) while the create and revoke actions on the same page write to the primary, so the list shown immediately after a change can still be the pre-change state.
Impact: After creating a key a user may not see it in the table, and after revoking one it may still show as Active until the page is reloaded.

Read-your-writes across primary/replica on the API keys page

Previously ApiKeysPresenter defaulted to the writer client (prisma). This PR changes the default to $replica and, in the same PR, adds mutations on the same route: createEnvironmentApiKey / revokeEnvironmentApiKey (apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.apikeys/route.tsx:260-289) write via the primary prisma client and then the route revalidates/redirects straight back into the loader, which calls the presenter. Under any replication lag the just-created key can be absent from keyEnvironment.apiKeys, and a just-revoked key can still have revokedAt: null (so it renders as Active with a Revoke button). The revoke flow uses redirectWithSuccessMessage, so the user sees "API key revoked" next to a row that still looks active.

If the read must stay on the replica, the mutation responses should either carry the new state or the loader should read the mutated rows from the primary.

Prompt for agents

ApiKeysPresenter's default Prisma client was changed from the writer (`prisma`) to the read replica (`$replica`). The same PR adds create/revoke API key mutations on the route that uses this presenter (apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.apikeys/route.tsx). Those mutations write through the primary and then immediately trigger a loader revalidation/redirect that reads through the presenter, so under replication lag the newly created key may be missing from the table and a just-revoked key may still render as Active. Decide whether this page needs read-your-writes: either keep the presenter on the writer for the api key rows, re-read the mutated rows from the primary, or have the action response carry the authoritative post-mutation state.

---

Was this helpful? React with 👍 or 👎 to provide feedback.