@trigger.dev/sdk 4.5.11 → 4.5.13

package/docs/vercel-integration.mdx

@@ -5,7 +5,7 @@ description: "Automatically deploy your tasks whenever you deploy to Vercel."
 
 ## How it works
 
-The Vercel integration connects your Vercel project to your Trigger.dev project so that every Vercel deployment automatically triggers a Trigger.dev deployment. It also syncs environment variables from Vercel into Trigger.dev and supports atomic deployments to keep your app and tasks in sync.
+The Vercel integration connects your Vercel project to your Trigger.dev project so that every Vercel deployment automatically triggers a Trigger.dev deployment. It also syncs environment variables from Vercel into Trigger.dev, and sets up [version skew protection](/deployment/version-skew-protection) so your app and tasks stay in sync.
 
 This eliminates the need to manually run the `trigger.dev deploy` command or maintain custom CI/CD workflows for Vercel-based projects.
 
@@ -42,8 +42,7 @@ You can connect Vercel from two entry points:
 </Step>
 
 <Step title="Configure build options">
-  Optionally adjust [build options](#build-options) for atomic deployments, env var pulling, and new
-  env var discovery.
+  Optionally adjust [build options](#build-options) for env var pulling and new env var discovery.
 </Step>
 
 <Step title="Connect GitHub">
@@ -99,7 +98,7 @@ The integration syncs environment variables in both directions:
 
 The following variables are excluded from the Vercel → Trigger.dev sync:
 
-- `TRIGGER_SECRET_KEY`, `TRIGGER_VERSION`, `TRIGGER_PREVIEW_BRANCH` (managed by Trigger.dev)
+- `TRIGGER_SECRET_KEY`, `TRIGGER_API_URL`, `TRIGGER_VERSION`, `TRIGGER_PREVIEW_BRANCH`, `TRIGGER_AUTOMATIC_SKEW_VERSION_PROTECTION` (managed by Trigger.dev)
 - Sensitive/secret-type variables (Vercel API limitation)
 
 You can control sync behavior per-variable from your project's Vercel settings. Deselecting a variable prevents its value from being updated during future syncs.
@@ -120,8 +119,41 @@ You can control sync behavior per-variable from your project's Vercel settings.
 
 If you use [Supabase Branching](https://supabase.com/docs/guides/deployment/branching) or [Neon Database Branching](https://neon.tech/docs/guides/branching-intro) for preview environments, disable syncing for database env vars on the Environment Variables page and use the [syncSupabaseEnvVars](/config/extensions/syncEnvVars#syncsupabaseenvvars) or [syncNeonEnvVars](/config/extensions/syncEnvVars#syncneonenvvars) build extensions instead. These extensions automatically resolve the correct branch-specific credentials at build time.
 
+## Version skew protection
+
+Your Vercel app and your tasks are deployed separately, so there is always a window where a new app can trigger tasks built from older code. [Version skew protection](/deployment/version-skew-protection) closes that window: each Trigger.dev deployment is tagged with your commit SHA, your app sends the same SHA when it triggers, and every run is pinned to the deployment built from the same commit. Runs triggered before the task build finishes wait for it rather than running on the previous version.
+
+The integration sets this up for you:
+
+- It sets `TRIGGER_AUTOMATIC_SKEW_VERSION_PROTECTION=1` on your Vercel project when you connect it, and re-asserts it on every build — so existing projects pick it up on their next deployment.
+- It passes your commit SHA as the deployment's external id.
+- `VERCEL_GIT_COMMIT_SHA` is available at runtime on Vercel, so the SDK finds the matching id with no work from you.
+
+There is nothing to enable, and it works in production, staging and preview alike. Nothing is gated: your Vercel deployment is never held back.
+
+<Note>
+  Version skew protection requires the `@trigger.dev/sdk` release that introduces external
+  deployment ids. Check the [release
+  notes](https://github.com/triggerdotdev/trigger.dev/releases) for the exact version, or just use
+  the latest. On an older SDK no id is sent and your runs execute on the current version, with no
+  warning.
+</Note>
+
+To opt out, set `TRIGGER_AUTOMATIC_SKEW_VERSION_PROTECTION` to `0` on your Vercel project. The integration only writes the variable when it is absent, so a value you set is never overwritten.
+
 ## Atomic deployments
 
+<Warning>
+  **Automatic atomic deployments are deprecated.** Use [version skew
+  protection](/deployment/version-skew-protection) instead — it needs no second Vercel deployment,
+  never gates your app's deploy, doesn't touch `Auto-assign Custom Production Domains`, and covers
+  staging and preview as well as production.
+
+  Nothing is being switched off. The setting stays in your project's Vercel settings, keeps working,
+  and remains the way to hold your Vercel deployment back until your tasks have built. New
+  connections have it off by default.
+</Warning>
+
 Atomic deployments ensure your Vercel app and Trigger.dev tasks are deployed in sync. When enabled, Trigger.dev gates your Vercel deployment until the task build completes, then triggers a Vercel redeployment with the correct `TRIGGER_VERSION` set. This guarantees your app always uses the matching version of your tasks.
 
 ```mermaid
@@ -152,15 +184,16 @@ sequenceDiagram
   TD->>TD: Promote build
 ```
 
-Atomic deployments are enabled for the production environment by default.
+Atomic deployments are off by default for new connections. Projects that already had them enabled keep them enabled until you turn them off. Enabling them asks you to confirm first.
 
 <Note>
   When atomic deployments are enabled, the integration automatically disables `Auto-assign Custom
   Production Domains` on your Vercel project. This is required so that Vercel doesn't promote a
-  deployment before the Trigger.dev build is ready.
+  deployment before the Trigger.dev build is ready. If you turn atomic deployments off, re-enable
+  that setting in Vercel or promote deployments yourself.
 </Note>
 
-Previously, setting up atomic deployments with Vercel required custom GitHub Actions workflows. The Vercel integration automates this entirely. For more details on how atomic deployments work, see [Atomic deploys](/deployment/atomic-deployment).
+Previously, setting up atomic deployments with Vercel required custom GitHub Actions workflows. The Vercel integration automates this entirely. For more details on how atomic deployments work, see [Atomic deploys](/deployment/atomic-deployment). For how to move off them, see [replacing automatic atomic deployments](/deployment/version-skew-protection#replacing-automatic-atomic-deployments).
 
 ## Environment mapping
 
@@ -184,7 +217,7 @@ If your Vercel project has a custom environment, you can select which one maps t
 
 You can configure the following settings per-environment from your project's Vercel settings:
 
-- **Atomic deployments**: Controls whether Trigger.dev and Vercel deployments are synchronized. Enabled for production by default.
+- **Atomic deployments** (deprecated): Controls whether Trigger.dev gates and redeploys your Vercel deployment to keep it in sync. Off by default for new connections — use [version skew protection](/deployment/version-skew-protection) instead.
 - **Pull env vars before build**: When enabled, Trigger.dev pulls the latest environment variables from Vercel before each build. Enabled for production, staging, and preview by default.
 - **Discover new env vars**: When enabled, new environment variables found in Vercel that don't yet exist in Trigger.dev are created automatically during builds. Only available for environments that also have env var pulling enabled. Enabled for production, staging, and preview by default.
 
@@ -201,7 +234,8 @@ Disconnecting stops automatic deployments, environment variable syncing, and dep
 
 ## Related
 
+- [Version skew protection](/deployment/version-skew-protection)
 - [GitHub integration](/github-integration)
-- [Atomic deploys](/deployment/atomic-deployment)
+- [Atomic deploys](/deployment/atomic-deployment) (deprecated for Vercel)
 - [Environment variables](/deploy-environment-variables)
 - [Preview branches](/deployment/preview-branches)

package/docs/versioning.mdx

@@ -47,6 +47,8 @@ So a task run will continue running on the version it was locked to. We do this
 
 Every deployment creates a new version of all tasks for that environment.
 
+Because your application and your tasks deploy separately, a release of your app can briefly trigger tasks that belong to a different version. [Version skew protection](/deployment/version-skew-protection) pins each run to the deployment built from the same commit, once your app sends the id it was deployed with.
+
 ## Retries and reattempts
 
 When a task has an uncaught error it will [retry](/errors-retrying), assuming you have not set `maxAttempts` to 0. Retries are locked to the original version of the run.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trigger.dev/sdk",
-  "version": "4.5.11",
+  "version": "4.5.13",
   "description": "trigger.dev Node.JS SDK",
   "license": "MIT",
   "publishConfig": {
@@ -66,30 +66,18 @@
   "dependencies": {
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/semantic-conventions": "1.41.1",
-    "@trigger.dev/core": "4.5.11",
-    "chalk": "^5.2.0",
-    "cronstrue": "^2.21.0",
-    "debug": "^4.3.4",
-    "evt": "^2.4.13",
-    "slug": "^6.0.0",
-    "ulid": "^2.3.0",
-    "uncrypto": "^0.1.3",
-    "ws": "^8.11.0"
+    "@trigger.dev/core": "4.5.13",
+    "uncrypto": "^0.1.3"
   },
   "devDependencies": {
     "@ai-sdk/provider": "3.0.8",
     "@arethetypeswrong/cli": "^0.18.5",
-    "@types/debug": "^4.1.7",
     "@types/react": "^19.2.14",
-    "@types/slug": "^5.0.3",
-    "@types/ws": "^8.5.3",
     "ai": "^6.0.116",
     "ai-v7": "npm:ai@7.0.0-canary.159",
-    "encoding": "^0.1.13",
     "rimraf": "^6.0.1",
     "tshy": "^4.1.3",
     "tsx": "4.17.0",
-    "typed-emitter": "^2.1.0",
     "typescript": "7.0.2",
     "zod": "3.25.76"
   },