@trigger.dev/sdk 4.5.0 → 4.5.2

package/docs/self-hosting/kubernetes.mdx

@@ -61,7 +61,7 @@ webapp:
 ```bash
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0" \
+  --version "^4.5.0" \
   --create-namespace
 ```
 
@@ -107,11 +107,11 @@ The following commands will display the default values:
 ```bash
 # Specific version
 helm show values oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5"
+  --version "4.5.0"
 
 # Latest v4
 helm show values oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0"
+  --version "^4.5.0"
 ```
 
 ### Custom values
@@ -171,7 +171,7 @@ Deploy with your custom values:
 ```bash
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0" \
+  --version "^4.5.0" \
   --create-namespace \
   -f values-custom.yaml
 ```
@@ -375,6 +375,32 @@ webapp:
 
 This only affects new runs; existing runs continue to read from wherever their events were originally stored.
 
+## Realtime streams
+
+Realtime streams power AI-agent token streaming and run streams. They default to **v2**, backed by the bundled `s2` deployment — [s2-lite](https://s2.dev), the open-source, self-hostable S2 server. The chart deploys it with a persistent volume, so no extra services are required.
+
+To fall back to the Redis-backed **v1** streams, set the default version to `v1`:
+
+```yaml
+s2:
+  defaultStreamVersion: "v1"
+```
+
+To use a hosted S2 at [s2.dev](https://s2.dev) instead of the bundled s2-lite, disable the bundled deployment and point at your basin. Supply the access token via an existing secret:
+
+```yaml
+s2:
+  deploy: false
+  skipAccessTokens: false
+  external:
+    endpoint: "https://your-basin.b.aws.s2.dev/v1"
+    existingSecret: "s2-credentials"
+    existingSecretAccessTokenKey: "access-token"
+  basin: "your-basin"
+```
+
+To disable realtime streams v2 entirely and use v1, set `s2.deploy: false` with no external endpoint. See `helm show values` for all `s2` options.
+
 ## Worker token
 
 When using the default bootstrap configuration, worker creation and authentication is handled automatically. The webapp generates a worker token and makes it available to the supervisor via a shared volume.
@@ -510,14 +536,14 @@ You can lock versions in two ways:
 # Pin to a specific version for production
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5"
+  --version "4.5.0"
 
 # The app version will be different from the chart version
 # This is the version of the Trigger.dev webapp and supervisor
 # ..and should always match your Trigger.dev CLI version
 helm show chart \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5" | grep appVersion
+  --version "4.5.0" | grep appVersion
 ```
 
 **Specific image tags:**
@@ -525,11 +551,11 @@ helm show chart \
 ```yaml
 webapp:
   image:
-    tag: "v4.0.0"
+    tag: "v4.5.0"
 
 supervisor:
   image:
-    tag: "v4.0.0"
+    tag: "v4.5.0"
 ```
 
 The chart version's `appVersion` field determines the default image tags. Newer image tags may be incompatible with older chart versions and vice versa.

package/docs/self-hosting/overview.mdx

@@ -6,7 +6,7 @@ description: "You can self-host Trigger.dev on your own infrastructure."
 
 Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, deployment process, and the URLs you expose the service on.
 
-You are responsible for provisioning resources, handling updates, and managing any security, scaling or reliability challenges that arise.
+You are responsible for provisioning resources, handling updates, and managing any security, scaling or reliability challenges that arise. See [Security & vulnerability reporting](/self-hosting/security) for how to report issues and stay informed about security releases.
 
 We provide version-tagged releases for self-hosted deployments. It's highly advised to use these tags exclusively and keep them locked with your CLI version.
 
@@ -106,4 +106,7 @@ It's dangerous to go alone! Join the self-hosting channel on our [Discord server
   <Card title="Kubernetes" color="#326CE5" icon="dharmachakra" href="/self-hosting/kubernetes">
     Learn how to self-host Trigger.dev with Kubernetes.
   </Card>
+  <Card title="Security" icon="shield-halved" href="/self-hosting/security">
+    Report vulnerabilities and stay informed about security releases.
+  </Card>
 </CardGroup>

package/docs/self-hosting/security.mdx

@@ -0,0 +1,50 @@
+---
+title: "Security & vulnerability reporting"
+description: "How to report security issues in Trigger.dev, our response targets, and how self-hosters receive security notices."
+sidebarTitle: "Security"
+---
+
+We take the security of Trigger.dev seriously, for both Cloud and self-hosted deployments. This page covers how to report a vulnerability, what to expect, and how to stay informed about security releases.
+
+<Warning>
+  Do not report security vulnerabilities through public GitHub issues, pull requests, or Discord. Use one of the private channels below.
+</Warning>
+
+## Reporting a vulnerability
+
+<Steps>
+  <Step title="Choose a private channel">
+    - **GitHub (preferred):** open a private report from the repository's **Security** tab using **"Report a vulnerability"** ([direct link](https://github.com/triggerdotdev/trigger.dev/security/advisories/new)).
+    - **Email:** `security-advisories@trigger.dev`
+  </Step>
+  <Step title="Include the details">
+    A description and impact, steps to reproduce (a proof of concept helps), affected versions/components, and any suggested fix.
+  </Step>
+  <Step title="We track it privately">
+    Every report is tracked in a private GitHub Security Advisory. If you email us, we open the advisory on your behalf.
+  </Step>
+</Steps>
+
+## What to expect
+
+| Stage | Target |
+| --- | --- |
+| Acknowledgement | within 3 business days |
+| Validation + CVSS 3.1 severity assessment | within 1 week |
+
+We score issues with CVSS 3.1 and prioritise remediation by severity:
+
+| Severity (CVSS 3.1) | Target time to resolve |
+| --- | --- |
+| Critical (9.0–10.0) | 7 days |
+| High (7.0–8.9) | 30 days |
+| Medium (4.0–6.9) | 90 days |
+| Low (0.1–3.9) | As needed |
+
+<Note>
+  These are best-effort targets measured from when we validate and accept a report, not guarantees. We follow coordinated disclosure with a default 90-day window, and publish a GitHub Security Advisory (requesting a CVE where applicable) once a fix ships.
+</Note>
+
+## Supported versions
+
+We patch the **latest released version line** only. Run the latest version-tagged release to receive security fixes — see [Self-hosting overview](/self-hosting/overview).

package/docs/troubleshooting.mdx

@@ -242,6 +242,10 @@ If runs are staying in the `QUEUED` state for extended periods, check your concu
 - **Review queue concurrency limits** - Check if individual queues have restrictive `concurrencyLimit` settings
 - **Check for stuck runs** - See if stalled runs are blocking new executions
 
+### Runs queued because a billing limit was reached
+
+If your organization reaches a billing limit, billable environments (`production`, `staging`, and `preview`) pause: new runs still queue, but they won't start executing until you raise or remove the limit and choose whether to resume or cancel the queued runs. See [Billing limits and alerts](/billing-limits) for the full flow.
+
 ### `Crypto is not defined`
 
 This can happen in different situations, for example when using plain strings as idempotency keys. Support for `Crypto` without a special flag was added in Node `v19.0.0`. You will have to upgrade Node - we recommend even-numbered major releases, e.g. `v20` or `v22`. Alternatively, you can switch from plain strings to the `idempotencyKeys.create` SDK function. [Read the guide](/idempotency).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trigger.dev/sdk",
-  "version": "4.5.0",
+  "version": "4.5.2",
   "description": "trigger.dev Node.JS SDK",
   "license": "MIT",
   "publishConfig": {
@@ -66,7 +66,7 @@
   "dependencies": {
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/semantic-conventions": "1.41.1",
-    "@trigger.dev/core": "4.5.0",
+    "@trigger.dev/core": "4.5.2",
     "chalk": "^5.2.0",
     "cronstrue": "^2.21.0",
     "debug": "^4.3.4",