@trigger.dev/sdk 4.7.0 → 4.7.1

package/dist/commonjs/version.js

@@ -1,5 +1,5 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.VERSION = void 0;
-exports.VERSION = "4.7.0";
+exports.VERSION = "4.7.1";
 //# sourceMappingURL=version.js.map

package/dist/esm/version.js

@@ -1,2 +1,2 @@
-export const VERSION = "4.7.0";
+export const VERSION = "4.7.1";
 //# sourceMappingURL=version.js.map

package/docs/config/config-file.mdx

@@ -269,6 +269,8 @@ export default defineConfig({
 
 ## Runtime
 
+If you don't set a `runtime`, your tasks run on the current Node.js LTS. Setting `runtime: "node"` does the same thing — see the Node.js versions section below to pin a specific version instead.
+
 We currently only officially support the `node` runtime, but you can try our experimental `bun` runtime by setting the `runtime` option in your config file:
 
 ```ts trigger.config.ts

package/docs/deployment/preview-branches.mdx

@@ -123,12 +123,12 @@ jobs:
       - name: Deploy preview branch
         run: npx trigger.dev@latest deploy --env preview
         env:
-          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_PREVIEW_ACCESS_TOKEN }}
 ```
 
 For this workflow to work, you need to set the following secrets in your GitHub repository:
 
-- `TRIGGER_ACCESS_TOKEN`: A Trigger.dev personal access token (they start with `tr_pat_`). [Learn how to create one and set it in GitHub](/github-actions#creating-a-personal-access-token).
+- `TRIGGER_PREVIEW_ACCESS_TOKEN`: A Trigger.dev API key for the Preview environment with **Deploy only** access. [Create a deployment API key and add it to GitHub](/github-actions#create-a-deployment-api-key).
 
 Notice that the deploy command has `--env preview` at the end. We automatically detect the preview branch from the GitHub actions env var.
 

package/docs/github-actions.mdx

@@ -1,9 +1,9 @@
 ---
 title: "CI / GitHub Actions"
-description: "You can easily deploy your tasks with GitHub actions and other CI environments."
+description: "Deploy your tasks from GitHub Actions and other CI environments using an environment API key."
 ---
 
-The instructions below are specific to GitHub Actions, but the same concepts can be used with other CI systems.
+The instructions below are specific to GitHub Actions, but the same concepts apply to other CI systems. Use an environment API key rather than a Personal Access Token so deployments are not tied to an individual team member's account or permissions.
 
 <Tip>
   Check out our new [GitHub integration](/github-integration) for automatic deployments, without adding any GitHub Actions workflows.
@@ -74,7 +74,7 @@ jobs:
 
       - name: 🚀 Deploy Trigger.dev
         env:
-          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_STAGING_ACCESS_TOKEN }}
         run: |
           npx trigger.dev@latest deploy --env staging --external-id ${{ github.sha }}
 ```
@@ -135,7 +135,7 @@ jobs:
       - name: Deploy preview branch
         run: npx trigger.dev@latest deploy --env preview --external-id ${{ github.event.pull_request.head.sha }}
         env:
-          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_PREVIEW_ACCESS_TOKEN }}
 ```
 
 On `pull_request`, `github.sha` is the merge commit GitHub creates for the PR, not the commit your
@@ -146,26 +146,36 @@ deployment sends.
   **Include `closed`** in the `pull_request.types` list. Without it, preview branches won't be archived when PRs are merged or closed, and you may hit the limit on active preview branches. See [Preview branches](/deployment/preview-branches#preview-branches-with-github-actions-recommended) for more details.
 </Note>
 
-## Creating a Personal Access Token
+## Create a deployment API key
+
+Create a separate API key for each environment that your CI workflows deploy to. The key remains valid when team membership or permissions change.
 
 <Steps>
 
-<Step title="Create a new access token">
-  Go to your profile page and click on the ["Personal Access
-  Tokens"](https://cloud.trigger.dev/account/tokens) tab.
+<Step title="Open the API keys page">
+  Select the project and target environment, then open [**API keys**](https://cloud.trigger.dev/_/apikeys).
 </Step>
 
-<Step title="Go to your repository on GitHub.">
-  Click on 'Settings' -> 'Secrets and variables' -> 'Actions' -> 'New repository secret'
+<Step title="Create an API key">
+  Click **New API key**, give the key a name that identifies the workflow, and choose **Deploy
+  only** access.
 </Step>
 
-<Step title="Add the TRIGGER_ACCESS_TOKEN">
-  Add the name `TRIGGER_ACCESS_TOKEN` and the value of your access token. ![Add TRIGGER_ACCESS_TOKEN
-  in GitHub](/images/github-access-token.png)
+<Step title="Copy the API key">
+  Create the key and copy its value. Trigger.dev shows the complete value only once.
+</Step>
+
+<Step title="Add the TRIGGER_ACCESS_TOKEN secret to GitHub">
+  Open the repository's **Settings**, then select **Secrets and variables** → **Actions** → **New
+  repository secret**. Add the name `TRIGGER_ACCESS_TOKEN` and paste the API key as its value.
+
+  ![Add TRIGGER_ACCESS_TOKEN in GitHub](/images/github-access-token.png)
 </Step>
 
 </Steps>
 
+The API key must belong to the environment targeted by the deploy command. If the repository deploys to multiple environments, store each environment's key in a separate GitHub secret and map the appropriate secret to `TRIGGER_ACCESS_TOKEN` in each workflow.
+
 ## CLI Version pinning
 
 The CLI and `@trigger.dev/*` package versions need to be in sync with the `trigger.dev` CLI, otherwise there will be errors and unpredictable behavior. Hence, the `deploy` command will automatically fail during CI on any version mismatches.
@@ -178,7 +188,7 @@ Tip: add the `trigger.dev` CLI to your `devDependencies` and the deploy command
     "deploy:trigger": "trigger deploy --env staging"
   },
   "devDependencies": {
-    "trigger.dev": "4.0.2"
+    "trigger.dev": "4.7.0"
   }
 }
 ```

package/docs/manual-setup.mdx

@@ -168,7 +168,7 @@ export default defineConfig({
 
 ### Using the Bun runtime
 
-By default, Trigger.dev will use the Node.js runtime. If you're using Bun, you can specify the runtime:
+By default, Trigger.dev runs your tasks on the current Node.js LTS. If you're using Bun, you can specify the runtime:
 
 ```typescript
 import { defineConfig } from "@trigger.dev/sdk";

package/docs/self-hosting/env/webapp.mdx

@@ -156,6 +156,8 @@ mode: "wide"
 | `EVENT_REPOSITORY_DEFAULT_STORE`                 | No       | postgres              | Where to store task events. Set to `clickhouse_v2` to store in ClickHouse (recommended for production).            |
 | `EVENT_REPOSITORY_POSTGRES_WRITES_DISABLED`      | No       | 0                     | Skip all PostgreSQL task-event writes (set to `1`). Only enable when `EVENT_REPOSITORY_DEFAULT_STORE` is `clickhouse_v2`, otherwise task events are lost. |
 | **Realtime**                                     |          |                       |                                                                                                                    |
+| `REALTIME_BACKEND_NATIVE_ENABLED`                | No       | 0                     | Set to `1` to enable native realtime run subscriptions and change notifications. When `0`, subscriptions use Electric. The Helm chart sets this to `1`. |
+| `REALTIME_BACKEND_DEFAULT`                       | No       | electric              | Backend for run subscriptions when native realtime is enabled and no `realtimeBackend` feature-flag override is set. One of `electric`, `native`, `shadow`. The Helm chart sets this to `native`. Separate from realtime stream version settings. |
 | `REALTIME_STREAM_VERSION`                        | No       | v1                    | Stream version exposed to tasks via the `TRIGGER_REALTIME_STREAM_VERSION` variable. Distinct from `REALTIME_STREAMS_DEFAULT_VERSION`. One of `v1`, `v2`. |
 | `REALTIME_STREAM_MAX_LENGTH`                     | No       | 1000                  | Realtime stream max length.                                                                                        |
 | `REALTIME_STREAM_TTL`                            | No       | 86400 (1d)            | Realtime stream TTL (s).                                                                                           |

package/docs/self-hosting/kubernetes.mdx

@@ -35,7 +35,13 @@ flowchart TD
   workers --> reg
 ```
 
-Each component maps to a top-level key in `values.yaml`: `webapp`, `supervisor`, `postgres`, `redis`, `electric`, `clickhouse`, `s3` (object storage), `s2`, and `registry`. The datastores default to `deploy: true` and run in-cluster; set `deploy: false` with an `external` block to bring your own. The registry is the exception - it defaults to `deploy: false`, so you point it at an external one. Webapp settings live under `webapp`, supervisor settings under `supervisor.config`, and each service takes `extraEnvVars` for anything else.
+Each component maps to a top-level key in `values.yaml`: `webapp`, `supervisor`, `postgres`, `redis`, `clickhouse`, `s3` (object storage), `s2`, and `registry`. The datastores default to `deploy: true` and run in-cluster; set `deploy: false` with an `external` block to bring your own. The registry is the exception - it defaults to `deploy: false`, so you point it at an external one. Webapp settings live under `webapp`, supervisor settings under `supervisor.config`, and each service takes `extraEnvVars` for anything else.
+
+Realtime run subscriptions use the native backend with the configured PostgreSQL, Redis, and ClickHouse services. The chart sets `REALTIME_BACKEND_NATIVE_ENABLED=1` and `REALTIME_BACKEND_DEFAULT=native`; no Electric service is required. These settings are separate from the S2-backed realtime streams configuration.
+
+<Warning>
+  Before upgrading from a chart that deploys Electric, unset the global `realtimeBackend` feature flag and any organization overrides, or set them to `native`. Both take precedence over the environment default. Values of `electric` or `shadow` still select the Electric backend, which this chart no longer deploys.
+</Warning>
 
 ## Requirements
 
@@ -91,7 +97,7 @@ Bundled datastores let you run the whole stack with a single command and no exte
       --create-namespace
     ```
 
-    The chart deploys the webapp, supervisor, and bundled Postgres, Redis, Electric, ClickHouse, MinIO, and s2-lite. The registry is not deployed by default - configure an external one before deploying tasks.
+    The chart deploys the webapp, supervisor, and bundled Postgres, Redis, ClickHouse, MinIO, and s2-lite. The registry is not deployed by default - configure an external one before deploying tasks.
   </Step>
 
   <Step title="Port-forward the webapp">
@@ -533,9 +539,14 @@ With external datastores, secrets, registry, and authentication in place, you ha
 
 ### Upgrading
 
-`helm upgrade` is safe to run as-is. Your generated secrets, data volumes, and the bundled ClickHouse are preserved and migrated automatically, so a normal upgrade needs no preparation. A few situations need one manual step first — expand any that apply to you.
+Your generated secrets, data volumes, and the bundled ClickHouse are preserved and migrated automatically. Before running `helm upgrade`, complete any prerequisites below that apply to your installation.
 
 <AccordionGroup>
+  <Accordion title="You upgrade from a chart that deploys Electric">
+    Unset the global `realtimeBackend` feature flag and any organization overrides, or set them to `native`, before upgrading. Organization overrides take precedence over the global flag, and the global flag takes precedence over `REALTIME_BACKEND_DEFAULT`.
+
+    The chart enables native realtime and removes the Electric service. A remaining `electric` or `shadow` flag value directs run subscriptions to that removed service and breaks realtime updates.
+  </Accordion>
   <Accordion title="You supply your own secret (secrets.existingSecret)">
     With `secrets.existingSecret` set, the chart reads every key from your Secret and generates none, so any key the app needs must already be present there.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trigger.dev/sdk",
-  "version": "4.7.0",
+  "version": "4.7.1",
   "description": "trigger.dev Node.JS SDK",
   "license": "MIT",
   "publishConfig": {
@@ -69,7 +69,7 @@
   "dependencies": {
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/semantic-conventions": "1.41.1",
-    "@trigger.dev/core": "4.7.0",
+    "@trigger.dev/core": "4.7.1",
     "uncrypto": "^0.1.3"
   },
   "devDependencies": {