@trigger.dev/sdk 4.5.2 → 4.5.4

package/docs/bulk-actions.mdx

@@ -1,9 +1,15 @@
 ---
 title: "Bulk actions"
-description: "Perform actions like replay and cancel on multiple runs at once."
+description: "Replay or cancel multiple runs from the dashboard using filters or selected run IDs."
 ---
 
-Bulk actions allow you to perform replaying and canceling on multiple runs at once. This is especially useful when you need to retry a batch of failed runs with a new version of your code, or when you need to cancel multiple in-progress runs.
+**Bulk actions let you replay or cancel multiple runs asynchronously from the dashboard.**
+
+Use bulk actions when you need to retry failed runs after deploying a fix, or stop a group of queued or executing runs.
+
+<Note>
+  For backend code, see [Bulk actions with the SDK](/runs/bulk-actions).
+</Note>
 
 <video
   src="https://content.trigger.dev/bulk-actions.mp4"
@@ -16,34 +22,55 @@ Bulk actions allow you to perform replaying and canceling on multiple runs at on
   height="100%"
 />
 
-## How to create a new bulk action
+## Create a bulk action in the dashboard
 
-<Icon icon="circle-1" iconType="solid" color="#FF2D6B" size="20" /> Open the bulk action panel from the top right of the runs page
+<Steps>
+  <Step title="Open the bulk action panel">
+    Open the runs page and click **Bulk action** in the top right.
 
-![Access bulk actions](/images/bulk-action-open-panel.png)
+    ![Open the bulk action panel from the runs page](/images/bulk-action-open-panel.png)
+  </Step>
 
+  <Step title="Choose the runs">
+    Filter the runs table to target a group of runs, or select individual runs from the table.
+  </Step>
 
-<Icon icon="circle-2" iconType="solid" color="#FF2D6B" size="20" /> Filter the runs table to show the runs you want to bulk action
+  <Step title="Configure the action">
+    Choose **Replay** or **Cancel**, add an optional name, then confirm the action.
 
-<Icon icon="circle-3" iconType="solid" color="#FF2D6B" size="20" /> Alternatively, you can select individual runs
+    ![Configure and create a bulk action](/images/bulk-action-create.png)
+  </Step>
 
-<Icon icon="circle-4" iconType="solid" color="#FF2D6B" size="20" /> Choose the runs you want to bulk action
+  <Step title="Track progress">
+    Open the bulk action page to see progress, view affected runs, or replay the action.
 
-<Icon icon="circle-5" iconType="solid" color="#FF2D6B" size="20" /> Name your bulk action (optional)
+    ![View bulk action progress](/images/bulk-action-page.png)
+  </Step>
+</Steps>
 
-<Icon icon="circle-6" iconType="solid" color="#FF2D6B" size="20" /> Choose the action you want to perform, replay or cancel
+<Note>
+  You can only cancel runs that are still cancelable, such as queued or executing runs. Runs that have already reached a final state cannot be canceled.
+</Note>
 
-<Icon icon="circle-7" iconType="solid" color="#FF2D6B" size="20" /> Click the "Replay" or "Cancel" button and confirm in the dialog
 
-![Access bulk actions](/images/bulk-action-create.png)
+## Create a bulk action from the SDK
 
-<Icon icon="circle-8" iconType="solid" color="#FF2D6B" size="20" /> You'll now view the bulk action processing from the bulk action page
+Use `runs.bulk.replay()` or `runs.bulk.cancel()` when you want to create a bulk action from your backend code.
 
-<Icon icon="circle-9" iconType="solid" color="#FF2D6B" size="20" /> You can replay or view the runs from this page
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
 
-![Access bulk actions](/images/bulk-action-page.png)
+const action = await runs.bulk.replay({
+  filter: {
+    status: "FAILED",
+    taskIdentifier: "sync-customer",
+    period: "24h",
+  },
+  name: "Replay failed customer syncs",
+});
 
-<Note>
-  You can only cancel runs that are in states that allow cancellation (like QUEUED or EXECUTING).
-  Runs that are already completed, failed, or in other final states by the time the bulk action process gets to them, cannot be canceled.
-</Note>
+const completed = await runs.bulk.poll(action.id);
+console.log(completed.status, completed.counts);
+```
+
+See [Bulk actions with the SDK](/runs/bulk-actions) for canceling, listing, polling, and aborting bulk actions from your backend code.

package/docs/cli-introduction.mdx

@@ -18,7 +18,7 @@ import VersionOption from '/snippets/cli-options-version.mdx';
 | [login](/cli-login-commands)                 | Login with Trigger.dev so you can perform authenticated actions.   |
 | [init](/cli-init-commands)                   | Initialize your existing project for development with Trigger.dev. |
 | [dev](/cli-dev-commands)                     | Run your Trigger.dev tasks locally.                                |
-| [deploy](/cli-deploy-commands)               | Deploy your Trigger.dev v3 project to the cloud.                   |
+| [deploy](/cli-deploy-commands)               | Deploy your Trigger.dev project to the cloud.                      |
 | [whoami](/cli-whoami-commands)               | Display the current logged in user and project details.            |
 | [logout](/cli-logout-commands)               | Logout of Trigger.dev.                                             |
 | [list-profiles](/cli-list-profiles-commands) | List all of your CLI profiles.                                     |

package/docs/config/extensions/syncEnvVars.mdx

@@ -32,6 +32,33 @@ The callback is passed a context object with the following properties:
 - `projectRef`: The project ref of the Trigger.dev project
 - `env`: The environment variables that are currently set in the Trigger.dev project
 
+### Marking variables as secrets
+
+Return the array form and set `isSecret: true` on any variable you want stored as a [secret](/deploy-environment-variables). Secret env vars are redacted in the dashboard and their values can't be revealed after they're set, just like manually created secret variables. You can mix secret and non-secret variables in the same callback.
+
+```ts
+import { defineConfig } from "@trigger.dev/sdk";
+import { syncEnvVars } from "@trigger.dev/build/extensions/core";
+
+export default defineConfig({
+  build: {
+    extensions: [
+      syncEnvVars(async (ctx) => {
+        return [
+          { name: "PUBLIC_API_URL", value: "https://api.example.com" },
+          { name: "DATABASE_URL", value: "postgres://...", isSecret: true },
+        ];
+      }),
+    ],
+  },
+});
+```
+
+<Note>
+  `isSecret` is only available when you return the array form (`{ name, value, isSecret }`). The
+  record form (`{ KEY: "value" }`) always creates non-secret variables.
+</Note>
+
 ### Example: Sync env vars from Infisical
 
 In this example we're using env vars from [Infisical](https://infisical.com).

package/docs/errors-retrying.mdx

@@ -377,3 +377,7 @@ export const openaiTask = task({
   },
 });
 ```
+
+## Replay failed runs in bulk
+
+After you deploy a fix, use [bulk actions](/bulk-actions) to replay multiple failed runs from the dashboard, or [bulk actions with the SDK](/runs/bulk-actions) to replay them from backend code. Bulk replay creates an asynchronous action that targets selected run IDs or a `runs.list()` filter, so you can retry a known failure set without replaying each run individually.

package/docs/github-repo.mdx

@@ -5,4 +5,4 @@ url: "https://github.com/triggerdotdev/trigger.dev"
 
 Trigger.dev is [Open Source on GitHub](https://github.com/triggerdotdev/trigger.dev). You can contribute to the project by submitting issues, pull requests, or simply by using it and providing feedback.
 
-You can also [self-host](/open-source-self-hosting) the project if you want to run it on your own infrastructure.
+You can also [self-host](/self-hosting/overview) the project if you want to run it on your own infrastructure.

package/docs/limits.mdx

@@ -104,7 +104,11 @@ Additional bundles are available for $10/month per 100 concurrent connections. C
 | Batch trigger payload  | Each item can be up to 3MB (SDK 4.3.1+). Prior: 1MB total combined |
 | Task outputs           | Must not exceed 10MB                                               |
 
-Payloads and outputs that exceed 512KB will be offloaded to object storage and a presigned URL will be provided to download the data when calling `runs.retrieve`. You don't need to do anything to handle this in your tasks however, as we will transparently upload/download these during operation.
+Large payloads and outputs are offloaded to object storage automatically. You don't need to do anything to handle this in your tasks, as we upload and download the data transparently during operation.
+
+On the way in, the SDK uploads any trigger or batch-item payload over 128KB to object storage before sending, so large triggers and batches don't exceed the request body limit. `trigger` and `triggerAndWait` have done this since SDK 4.5.0, and `batchTrigger` and `batchTriggerAndWait` (including the by-id and by-task variants) do too from SDK 4.5.2.
+
+Payloads and outputs over 512KB are kept in object storage rather than inline. Calling `runs.retrieve` returns that offloaded data as a presigned download URL (`payloadPresignedUrl` / `outputPresignedUrl`).
 
 ## Batch size
 

package/docs/migrating-from-v3.mdx

@@ -7,16 +7,14 @@ import NodeVersions from "/snippets/node-versions.mdx";
 import MigrateV4UsingAi from "/snippets/migrate-v4-using-ai.mdx";
 
 <Warning>
-  **Action required: Trigger.dev v3 deprecation**
+  **Trigger.dev v3 has been retired**
 
-We're retiring Trigger.dev v3. **New v3 deploys will stop working from 1 April 2026.** Trigger.dev v4 is stable, fully supported, and recommended for all users.
+Trigger.dev v3 is end of life. v4 is stable, fully supported, and recommended for all users.
 
-**Key dates:**
+- On Trigger.dev Cloud, v3 has been shut down: v3 triggers and deploys no longer run.
+- If you self-host, 4.5.0 is the last version we officially support for running v3. Stay on 4.5.0 or upgrade to v4; 4.5.1 and later reject v3 triggers, batch triggers, and deploys with an upgrade message.
 
-- **1 April 2026** — New v3 deploys will no longer work. Existing v3 runs will continue to execute.
-- **1 July 2026** — v3 will be fully shut down. All v3 runs will stop executing.
-
-**What you need to do:** Migrate to v4 before April to avoid disruption to your task executions. The migration takes about 2 minutes — follow the steps on this page below. If you have questions or need help, [contact us](https://trigger.dev/contact) or reach out in our [Discord](https://trigger.dev/discord).
+**What you need to do:** Migrate to v4. The migration takes about 2 minutes; follow the steps below. If you have questions or need help, [contact us](https://trigger.dev/contact) or reach out in our [Discord](https://trigger.dev/discord).
 
 </Warning>
 

package/docs/quick-start.mdx

@@ -57,7 +57,7 @@ If I've already run init and want the MCP server, run: npx trigger.dev@latest in
 
 <Step title="Create a Trigger.dev account">
 
-Sign up at [Trigger.dev Cloud](https://cloud.trigger.dev) (or [self-host](/open-source-self-hosting)). The onboarding flow will guide you through creating your first organization and project.
+Sign up at [Trigger.dev Cloud](https://cloud.trigger.dev) (or [self-host](/self-hosting/overview)). The onboarding flow will guide you through creating your first organization and project.
 
 </Step>
 

package/docs/run-tests.mdx

@@ -3,18 +3,19 @@ title: "Run tests"
 description: "You can use the dashboard to run a test of your tasks."
 ---
 
-From the "Test" page in the side menu of the dashboard you can run a test for any of your tasks from any environment.
+You can run a test for any of your tasks, in any environment, from the dashboard.
 
-![Select an environment](/images/test-dashboard.png)
+<Note>
+  There is no longer a "Test" page in the sidebar. You test a task from the task itself: on the
+  Tasks page open a task (or use the "Test" action next to a task in the Runs list) and press the
+  "Test" button to open its test page.
+</Note>
 
-<Icon icon="circle-1" iconType="solid" color="#FF2D6B" size="20" /> Select a task to test
+On a task's test page you can:
 
-<Icon icon="circle-2" iconType="solid" color="#FF2D6B" size="20" /> Include a payload or metadata
+- Enter the run's input — a JSON **payload** and optional **metadata**. Scheduled tasks show timestamp fields instead of a payload.
+- Configure run **options** like the machine size, version, queue, tags, retries, max duration, or a delay.
+- Pre-populate the form from a previous run with **Recent runs**, or save and reuse a configuration with **Templates**.
+- Press **Run test** to trigger the run.
 
-<Icon icon="circle-3" iconType="solid" color="#FF2D6B" size="20" /> Configure any additional options like the machine size, queue or delay
-
-<Icon icon="circle-4" iconType="solid" color="#FF2D6B" size="20" /> Select from previous test runs
-
-<Icon icon="circle-5" iconType="solid" color="#FF2D6B" size="20" /> Save the current test configuration as a template for later
-
-<Icon icon="circle-6" iconType="solid" color="#FF2D6B" size="20" /> Run the test
+![Test page](/images/test-dashboard.png)

package/docs/runs/bulk-actions.mdx

@@ -0,0 +1,182 @@
+---
+title: "Bulk actions"
+description: "Cancel or replay many runs from the SDK using run IDs or SDK run-list filters."
+---
+
+**Bulk actions let you cancel or replay many runs asynchronously from the SDK by selecting runs with run IDs or SDK run-list filters.**
+
+A bulk action returns a handle immediately. Use the handle to retrieve progress, poll until completion, list previous actions, or abort pending work.
+
+## Create a bulk replay
+
+Use `runs.bulk.replay()` to replay every run that matches a filter.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+const action = await runs.bulk.replay({
+  filter: {
+    status: "FAILED",
+    taskIdentifier: "sync-customer",
+    period: "24h",
+  },
+  name: "Replay failed customer syncs",
+  targetRegion: "eu-central-1",
+});
+
+const completed = await runs.bulk.poll(action.id);
+console.log(completed.status, completed.counts);
+```
+
+`filter` accepts the SDK run-list filter fields, excluding pagination fields such as `limit`, `after`, and `before`. This is the TypeScript SDK shape used by `runs.list()` (`from`, `to`, and `period` are top-level fields), not the nested `filter[createdAt]` query shape shown in the raw HTTP list-runs endpoint. Provide at least one filter field; use `runIds` when you want to target specific runs. Relative time filters such as `period` are resolved when the bulk action is created, so later batches process the same fixed time range.
+
+<Warning>
+  Filters inherit the same time semantics as `runs.list()`: when you don't pass `from`, `to`, or `period`, the action defaults to the **last 7 days** and won't target older matching runs. To cover a wider range, pass an explicit `period` (such as `"30d"`), a `from` timestamp, or a `from`/`to` pair. This default only applies to `filter` selections; `runIds` selections are never time-bounded.
+</Warning>
+
+<ParamField body="filter" type="BulkActionFilter">
+  Selects runs using the SDK run-list filter shape, excluding `limit`, `after`, and `before`. In raw HTTP requests these fields are sent as JSON body properties, so time fields are top-level (`from`, `to`, `period`) instead of nested under `createdAt`.
+</ParamField>
+
+<ParamField body="runIds" type="string[]">
+  Selects specific run IDs. Provide either `filter` or `runIds`, not both.
+</ParamField>
+
+<ParamField body="name" type="string" optional>
+  A name for the bulk action.
+</ParamField>
+
+<ParamField body="targetRegion" type="string" optional>
+  Replays matching runs in a specific region. When omitted, each replay keeps the original run's region. This option is only available for `runs.bulk.replay()`.
+</ParamField>
+
+## Create a bulk cancel
+
+Use `runs.bulk.cancel()` to cancel every run that matches a filter, or specific run IDs.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+const action = await runs.bulk.cancel({
+  runIds: ["run_1234", "run_5678"],
+  name: "Cancel selected runs",
+});
+
+console.log(action.id);
+```
+
+Only runs that are still cancelable when the action reaches them are canceled. Runs that have already reached a final state count as failures in the bulk action summary.
+
+## Retrieve progress
+
+Use `runs.bulk.retrieve()` to read the current status and aggregate counts.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+const action = await runs.bulk.retrieve("bulk_1234");
+
+console.log(action.status);
+console.log(action.counts.total, action.counts.success, action.counts.failure);
+```
+
+The returned bulk action object has these fields:
+
+<ResponseField name="id" type="string">
+  The bulk action ID, starting with `bulk_`.
+</ResponseField>
+
+<ResponseField name="type" type="'CANCEL' | 'REPLAY'">
+  The action being performed.
+</ResponseField>
+
+<ResponseField name="status" type="'PENDING' | 'COMPLETED' | 'ABORTED'">
+  The current bulk action status.
+</ResponseField>
+
+<ResponseField name="counts" type="object">
+  Aggregate processing counts.
+
+  <Expandable title="properties">
+    <ResponseField name="total" type="number">
+      The number of runs selected when the bulk action was created.
+    </ResponseField>
+    <ResponseField name="success" type="number">
+      The number of runs processed successfully.
+    </ResponseField>
+    <ResponseField name="failure" type="number">
+      The number of runs that could not be processed.
+    </ResponseField>
+  </Expandable>
+</ResponseField>
+
+<ResponseField name="createdAt" type="Date">
+  The date and time the bulk action was created.
+</ResponseField>
+
+<ResponseField name="completedAt" type="Date" optional>
+  The date and time the bulk action completed.
+</ResponseField>
+
+## Poll for completion
+
+Use `runs.bulk.poll()` to wait until the bulk action leaves the `PENDING` state.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+const completed = await runs.bulk.poll("bulk_1234", {
+  pollIntervalMs: 2_000,
+});
+
+console.log(completed.status);
+```
+
+## Abort a bulk action
+
+Use `runs.bulk.abort()` to stop future batches from being processed.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+await runs.bulk.abort("bulk_1234");
+```
+
+Abort is best effort. Runs already being processed in the current batch may still finish.
+
+<Note>
+  Each environment can only run a limited number of bulk replays at the same time. If you start a replay while too many are still in progress, the call fails and returns an error. Wait for an in-progress replay to finish or abort one before starting another. Bulk cancels are not subject to this limit.
+</Note>
+
+## List bulk actions
+
+Use `runs.bulk.list()` to page through previous bulk actions in the current environment.
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+const page = await runs.bulk.list({ limit: 25 });
+
+for (const action of page.data) {
+  console.log(action.id, action.status);
+}
+```
+
+List results support the same auto-pagination helpers as other management API list methods:
+
+```ts Your backend code
+import { runs } from "@trigger.dev/sdk";
+
+for await (const action of runs.bulk.list({ limit: 25 })) {
+  console.log(action.id, action.status);
+}
+```
+
+## API reference
+
+The SDK methods use the bulk actions HTTP API:
+
+- [Create bulk action](/management/bulk-actions/create)
+- [List bulk actions](/management/bulk-actions/list)
+- [Retrieve bulk action](/management/bulk-actions/retrieve)
+- [Abort bulk action](/management/bulk-actions/abort)

package/docs/self-hosting/docker.mdx

@@ -344,6 +344,12 @@ TRIGGER_IMAGE_TAG=v4.5.0
 
 We patch the latest released version line only, so keep an eye on new releases to receive security fixes. See [Security & vulnerability reporting](/self-hosting/security).
 
+<Note>
+  Trigger.dev 4.5.0 is the last version we officially support for running v3 (SDK v3) tasks. If
+  you still have v3 tasks, pin `TRIGGER_IMAGE_TAG` to exactly `v4.5.0` or [migrate to
+  v4](/migrating-from-v3). 4.5.1 and later reject v3 triggers and deploys with an upgrade message.
+</Note>
+
 ## Task events
 
 By default, task events (timeline, logs, spans) are stored in PostgreSQL. For production deployments we recommend storing them in ClickHouse instead, it scales to much higher volumes and avoids unbounded growth of the `TaskEvent` table.
@@ -390,8 +396,6 @@ See the [webapp environment variables](/self-hosting/env/webapp) for the full li
   docker compose logs -f webapp
   ```
 
-- **Deploy fails with `ERROR: schema "graphile_worker" does not exist`.** This error occurs when Graphile Worker migrations fail to run during webapp startup. Check the webapp logs for certificate-related errors like `self-signed certificate in certificate chain`. This is often caused by PostgreSQL SSL certificate issues when using an external PostgreSQL instance with SSL enabled. Ensure that both the webapp and supervisor containers have access to the same CA certificate used by your PostgreSQL instance. You can configure this by mounting the certificate file and setting the `NODE_EXTRA_CA_CERTS` environment variable to point to the certificate path. Once the certificate issue is resolved, the migrations will complete and create the required `graphile_worker` schema.
-
 - **ClickHouse migrations say "no migrations to run" but schema is missing.** The goose migration tracker is out of sync. Exec into the webapp container, set the GOOSE env vars (from webapp startup logs), and run `goose reset && goose up`.
 
   <Warning>

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

@@ -52,11 +52,8 @@ mode: "wide"
 | `AWS_REGION`                                     | No       | —                     | AWS region for SES.                                                                                                |
 | `AWS_ACCESS_KEY_ID`                              | No       | —                     | AWS access key ID for SES.                                                                                         |
 | `AWS_SECRET_ACCESS_KEY`                          | No       | —                     | AWS secret access key for SES.                                                                                     |
-| **Graphile & Redis worker**                      |          |                       |                                                                                                                    |
-| `WORKER_CONCURRENCY`                             | No       | 10                    | Redis worker concurrency.                                                                                          |
-| `WORKER_POLL_INTERVAL`                           | No       | 1000                  | Redis worker poll interval (ms).                                                                                   |
-| `WORKER_SCHEMA`                                  | No       | graphile_worker       | Graphile worker schema.                                                                                            |
-| `GRACEFUL_SHUTDOWN_TIMEOUT`                      | No       | 60000 (1m)            | Graphile graceful shutdown timeout (ms). Affects shutdown time.                                                    |
+| **Worker**                                       |          |                       |                                                                                                                    |
+| `GRACEFUL_SHUTDOWN_TIMEOUT`                      | No       | 60000 (1m)            | Graceful shutdown timeout (ms). Affects shutdown time.                                                             |
 | **Concurrency limits**                           |          |                       |                                                                                                                    |
 | `DEFAULT_ENV_EXECUTION_CONCURRENCY_LIMIT`        | No       | 100                   | Default env execution concurrency.                                                                                 |
 | `DEFAULT_ORG_EXECUTION_CONCURRENCY_LIMIT`        | No       | 300                   | Default org execution concurrency, needs to be 3x env concurrency.                                                 |
@@ -138,6 +135,7 @@ mode: "wide"
 | `SERVER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT`  | No       | 8192                  | OTel span attribute value length limit.                                                                            |
 | **Task events**                                  |          |                       |                                                                                                                    |
 | `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_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.                                                                                        |
@@ -168,8 +166,6 @@ mode: "wide"
 | `MAXIMUM_DEV_QUEUE_SIZE`                         | No       | —                     | Maximum queued runs per queue in development environments.                                                         |
 | `MAXIMUM_DEPLOYED_QUEUE_SIZE`                    | No       | —                     | Maximum queued runs per queue in deployed (staging/prod) environments.                                             |
 | **Misc**                                         |          |                       |                                                                                                                    |
-| `PROVIDER_SECRET`                                | No       | provider-secret       | Secret for provider auth. **Must be set to a secure value in self-hosted/production**; the default is insecure.    |
-| `COORDINATOR_SECRET`                             | No       | coordinator-secret    | Secret for coordinator auth. **Must be set to a secure value in self-hosted/production**; the default is insecure. |
 | `TRIGGER_TELEMETRY_DISABLED`                     | No       | —                     | Disable telemetry.                                                                                                 |
 | `NODE_MAX_OLD_SPACE_SIZE`                        | No       | 8192                  | Maximum memory allocation for Node.js heap in MiB (e.g. "4096" for 4GB).                                           |
 | `OPENAI_API_KEY`                                 | No       | —                     | OpenAI API key.                                                                                                    |

package/docs/self-hosting/kubernetes.mdx

@@ -528,6 +528,12 @@ webapp:
 
 ## Version locking
 
+<Note>
+  Trigger.dev 4.5.0 is the last version we officially support for running v3 (SDK v3) tasks. If
+  you still have v3 tasks, pin to exactly 4.5.0 or [migrate to v4](/migrating-from-v3). 4.5.1 and
+  later reject v3 triggers and deploys with an upgrade message.
+</Note>
+
 You can lock versions in two ways:
 
 **Helm chart version (recommended):**
@@ -602,7 +608,6 @@ kubectl delete namespace trigger
 - **Deploy fails**: Verify registry access and authentication
 - **Pods stuck pending**: Describe the pod and check the events
 - **Worker token issues**: Check webapp and supervisor logs for errors
-- **Deploy fails with `ERROR: schema "graphile_worker" does not exist`**: See the [Docker troubleshooting](/self-hosting/docker#troubleshooting) section for details on resolving PostgreSQL SSL certificate issues that prevent Graphile Worker migrations.
 
 See the [Docker troubleshooting](/self-hosting/docker#troubleshooting) section for more information.
 

package/docs/self-hosting/overview.mdx

@@ -10,6 +10,13 @@ You are responsible for provisioning resources, handling updates, and managing a
 
 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.
 
+<Warning>
+  **v3 is end of life.** Trigger.dev 4.5.0 is the last version we officially support for running
+  v3 (SDK v3) tasks. If you still have v3 tasks, stay on 4.5.0 or [migrate to
+  v4](/migrating-from-v3). 4.5.1 and later reject v3 triggers, batch triggers, and deploys with an
+  upgrade message; v4 workloads are unaffected.
+</Warning>
+
 ## Should you self-host?
 
 Trigger.dev Cloud is fully managed, scalable, and comes with dedicated support. For most users, it offers the best experience. However, if you have specific requirements around data residency, compliance, or infrastructure control, self-hosting may be the right choice for you.

package/docs/tasks/scheduled.mdx

@@ -127,11 +127,11 @@ export const secondScheduledTask = schedules.task({
 });
 ```
 
-When you run the [dev](/cli-dev-commands) or [deploy](/cli-deploy-commands) commands, declarative schedules will be synced. If you add, delete or edit the `cron` property it will be updated when you run these commands. You can view your schedules on the Schedules page in the dashboard.
+When you run the [dev](/cli-dev-commands) or [deploy](/cli-deploy-commands) commands, declarative schedules will be synced. If you add, delete or edit the `cron` property it will be updated when you run these commands. You can view your synced schedules in the dashboard: open the task on the Tasks page and check its "Schedules" tab.
 
 ### Imperative schedules
 
-Alternatively you can explicitly attach schedules to a `schedules.task`. You can do this in the Schedules page in the dashboard by just pressing the "New schedule" button, or you can use the SDK to create schedules.
+Alternatively you can explicitly attach schedules to a `schedules.task`. You can do this in the dashboard from the scheduled task's page by pressing the "Create schedule" button, or you can use the SDK to create schedules.
 
 The advantage of imperative schedules is that they can be created dynamically, for example, you could create a schedule for each user in your database. They can also be activated, disabled, edited, and deleted without deploying new code by using the SDK or dashboard.
 
@@ -166,26 +166,37 @@ There are two situations when a scheduled task won't trigger:
 
 ## Attaching schedules in the dashboard
 
-You need to attach a schedule to a task before it will run on a schedule. You can attach static schedules in the dashboard:
+You need to attach a schedule to a task before it will run on a schedule. You can attach imperative schedules in the dashboard:
+
+<Note>
+  **The Schedules page has moved.** There is no longer a standalone "Schedules" page in the
+  sidebar. Schedules now live on the Tasks page: open a scheduled task to create, view, edit,
+  enable/disable, and delete its schedules. The old `/schedules` URL redirects to the Tasks page.
+
+  The scheduled task must already exist first — define it in your code with `schedules.task()` and
+  sync it to the environment by running the [dev](/cli-dev-commands) or
+  [deploy](/cli-deploy-commands) command so it appears on the Tasks page. A project with no tasks
+  yet will only show the deploy onboarding.
+</Note>
 
 <Steps>
 
-<Step title="Go to the Schedules page">
-  In the sidebar select the "Schedules" page, then press the "New schedule" button. Or you can
-  follow the onboarding and press the create in dashboard button. ![Blank schedules
-  page](/images/schedules-blank.png)
+<Step title="Open the scheduled task">
+  In the sidebar select the "Tasks" page, then select the scheduled task you want to attach a
+  schedule to (scheduled tasks have a clock icon, and you can filter the list to Scheduled).
+  ![Scheduled task page](/images/schedules-blank.png)
 </Step>
 
 <Step title="Create your schedule">
-  Fill in the form and press "Create schedule" when you're done. ![Environment variables
-  page](/images/schedules-create.png)
+  Press the "Create schedule" button, fill in the form, and press "Create schedule" when you're
+  done. ![Create schedule form](/images/schedules-create.png)
 
 These are the options when creating a schedule:
 
 | Name              | Description                                                                                   |
 | ----------------- | --------------------------------------------------------------------------------------------- |
 | Task              | The id of the task you want to attach to.                                                     |
-| Cron pattern      | The schedule in cron format.                                                                  |
+| Cron pattern      | The schedule in cron format. You can also describe it in natural language and press "Generate" to fill this in. |
 | Timezone          | The timezone the schedule will run in. Defaults to "UTC"                                      |
 | External id       | An optional external id, usually you'd use a userId.                                          |
 | Deduplication key | An optional deduplication key. If you pass the same value, it will update rather than create. Scoped per project, not per environment. |
@@ -195,6 +206,12 @@ These are the options when creating a schedule:
 
 </Steps>
 
+## Managing schedules in the dashboard
+
+Open the scheduled task and switch to the "Schedules" tab to see every schedule attached to it — both declarative and imperative — with its type, cron pattern, external id, next and last run, and status.
+
+Click a schedule to open the inspector, where you can **enable/disable**, **edit**, or **delete** imperative schedules without deploying new code. Declarative schedules are managed in your code, so they can't be edited or deleted from here.
+
 ## Attaching schedules with the SDK
 
 You call `schedules.create()` to create a schedule from your code. Here's the simplest possible example:
@@ -302,14 +319,19 @@ You can also retrieve, list, delete, deactivate and re-activate schedules using
 
 You can test a scheduled task in the dashboard. Note that the `scheduleId` will always come through as `sched_1234` to the run.
 
+<Note>
+  There is no longer a standalone "Test" page in the sidebar. You test a task from the task itself —
+  open it on the Tasks page and press the "Test schedule" button.
+</Note>
+
 <Steps>
 
-<Step title="Go to the Test page">
-  In the sidebar select the "Test" page, then select a scheduled task from the list (they have a
-  clock icon on them) ![Test page](/images/schedules-test.png)
+<Step title="Open the test page for your task">
+  On the "Tasks" page, open your scheduled task and press the "Test schedule" button.
+  ![Scheduled task page](/images/schedules-test.png)
 </Step>
 
-<Step title="Create your schedule">
+<Step title="Run the test">
   Fill in the form [1]. You can select from a recent run [2] to pre-populate the fields. Press "Run
   test" when you're ready ![Schedule test form](/images/schedules-test-form.png)
 </Step>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trigger.dev/sdk",
-  "version": "4.5.2",
+  "version": "4.5.4",
   "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.2",
+    "@trigger.dev/core": "4.5.4",
     "chalk": "^5.2.0",
     "cronstrue": "^2.21.0",
     "debug": "^4.3.4",