diff --git a/docs/cli-deploy-commands.mdx b/docs/cli-deploy-commands.mdx
index ba334ae3b3..86f6ede1ee 100644
--- a/docs/cli-deploy-commands.mdx
+++ b/docs/cli-deploy-commands.mdx
@@ -1,9 +1,9 @@
---
-title: "CLI deploy options"
+title: "CLI deploy command"
sidebarTitle: "deploy"
-description: "Use these options to help deploy your tasks to Trigger.dev."
+description: "Use the deploy command to deploy your tasks to Trigger.dev."
---
-import CliDeployCommands from '/snippets/cli-commands-deploy.mdx';
+import CliDeployCommands from "/snippets/cli-commands-deploy.mdx";
-
\ No newline at end of file
+
diff --git a/docs/cli-promote-commands.mdx b/docs/cli-promote-commands.mdx
new file mode 100644
index 0000000000..0bc30d6de7
--- /dev/null
+++ b/docs/cli-promote-commands.mdx
@@ -0,0 +1,9 @@
+---
+title: "CLI promote command"
+sidebarTitle: "promote"
+description: "Use the promote command to promote a previously deployed version to the current version."
+---
+
+import CliPromoteCommands from "/snippets/cli-commands-promote.mdx";
+
+
diff --git a/docs/deployment/api-key.png b/docs/deployment/api-key.png
new file mode 100644
index 0000000000..2202846e13
Binary files /dev/null and b/docs/deployment/api-key.png differ
diff --git a/docs/deployment/atomic-deployment.mdx b/docs/deployment/atomic-deployment.mdx
new file mode 100644
index 0000000000..d421154efb
--- /dev/null
+++ b/docs/deployment/atomic-deployment.mdx
@@ -0,0 +1,171 @@
+---
+title: "Atomic deploys"
+sidebarTitle: "Atomic deploys"
+description: "Use atomic deploys to coordinate changes to your tasks and your application."
+---
+
+Atomic deploys in Trigger.dev allow you to synchronize the deployment of your application with a specific version of your tasks. This ensures that your application always uses the correct version of its associated tasks, preventing inconsistencies or errors due to version mismatches.
+
+## How it works
+
+Atomic deploys achieve synchronization by deploying your tasks to Trigger.dev without promoting them to the default version. Instead, you explicitly specify the deployed task version in your application’s environment. Here’s the process at a glance:
+
+1. **Deploy Tasks to Trigger.dev**: Use the Trigger.dev CLI to deploy your tasks with the `--skip-promotion` flag. This creates a new task version without making it the default.
+2. **Capture the Deployment Version**: The CLI outputs the version of the deployed tasks, which you’ll use in the next step.
+3. **Deploy Your Application**: Deploy your application (e.g., to Vercel), setting an environment variable like `TRIGGER_VERSION` to the captured task version.
+
+## Vercel CLI & GitHub Actions
+
+If you deploy to Vercel via their CLI, you can use this sample workflow that demonstrates performing atomic deploys with GitHub Actions, Trigger.dev, and Vercel:
+
+```yml
+name: Deploy to Trigger.dev (prod)
+on:
+ push:
+ branches:
+ - main
+concurrency:
+ group: ${{ github.workflow }}
+ cancel-in-progress: true
+jobs:
+ deploy:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+
+ - name: Use Node.js 20.x
+ uses: actions/setup-node@v4
+ with:
+ node-version: "20.x"
+
+ - name: Install dependencies
+ run: npm install
+
+ - name: Deploy Trigger.dev
+ id: deploy-trigger
+ env:
+ TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+ run: |
+ npx trigger.dev@latest deploy --skip-promotion
+
+ - name: Deploy to Vercel
+ run: npx vercel --yes --prod -e TRIGGER_VERSION=$TRIGGER_VERSION --token $VERCEL_TOKEN
+ env:
+ VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
+ TRIGGER_VERSION: ${{ steps.deploy-trigger.outputs.deploymentVersion }}
+
+ - name: Promote Trigger.dev Version
+ if: false
+ run: npx trigger.dev@latest promote $TRIGGER_VERSION
+ env:
+ TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+ TRIGGER_VERSION: ${{ steps.deploy-trigger.outputs.deploymentVersion }}
+```
+
+- Deploy to Trigger.dev
+
+ - The `npx trigger.dev deploy` command uses `--skip-promotion` to deploy the tasks without setting the version as the default.
+ - The step’s id: `deploy-trigger` allows us to capture the deployment version in the output (deploymentVersion).
+
+- Deploy to Vercel:
+ - The `npx vercel` command deploys the application, setting the `TRIGGER_VERSION` environment variable to the task version from the previous step.
+ - The --prod flag ensures a production deployment, and -e passes the environment variable.
+ - The `@trigger.dev/sdk` automatically uses the `TRIGGER_VERSION` environment variable to trigger the correct version of the tasks.
+
+For this workflow to work, you need to set up the following secrets in your GitHub repository:
+
+- `TRIGGER_ACCESS_TOKEN`: Your Trigger.dev personal access token. View the instructions [here](/github-actions) to learn more.
+- `VERCEL_TOKEN`: Your Vercel personal access token. You can find this in your Vercel account settings.
+
+## Vercel GitHub integration
+
+If you're are using Vercel, chances are you are using their GitHub integration and deploying your application directly from pushes to GitHub. This section covers how to achieve atomic deploys with Trigger.dev in this setup.
+
+### Turn off automatic promotion
+
+By default, Vercel automatically promotes new deployments to production. To prevent this, you need to disable the auto-promotion feature in your Vercel project settings:
+
+1. Go to your Production environment settings in Vercel at `https://vercel.com///settings/environments/production`
+2. Disable the "Auto-assign Custom Production Domains" setting:
+
+
+
+3. Hit the "Save" button to apply the changes.
+
+Now whenever you push to your main branch, Vercel will deploy your application to the production environment without promoting it, and you can control the promotion manually.
+
+### Deploy with Trigger.dev
+
+Now we want to deploy that same commit to Trigger.dev, and then promote the Vercel deployment when that completes. Here's a sample GitHub Actions workflow that does this:
+
+```yml
+name: Deploy to Trigger.dev (prod)
+
+on:
+ push:
+ branches:
+ - main
+
+concurrency:
+ group: ${{ github.workflow }}
+ cancel-in-progress: true
+
+jobs:
+ deploy:
+ runs-on: ubuntu-latest
+
+ steps:
+ - uses: actions/checkout@v4
+
+ - name: Use Node.js 20.x
+ uses: actions/setup-node@v4
+ with:
+ node-version: "20.x"
+
+ - name: Install dependencies
+ run: npm install
+
+ - name: Wait for vercel deployment (push)
+ id: wait-for-vercel
+ uses: ericallam/vercel-wait@main
+ with:
+ project-id: ${{ secrets.VERCEL_PROJECT_ID }}
+ token: ${{ secrets.VERCEL_TOKEN }}
+ sha: ${{ github.sha }}
+
+ - name: 🚀 Deploy Trigger.dev
+ id: deploy-trigger
+ env:
+ TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
+ run: |
+ npx trigger.dev@latest deploy
+
+ - name: Promote Vercel deploy
+ run: npx vercel promote $VERCEL_DEPLOYMENT_ID --yes --token $VERCEL_TOKEN --scope $VERCEL_SCOPE_NAME
+ env:
+ VERCEL_DEPLOYMENT_ID: ${{ steps.wait-for-vercel.outputs.deployment-id }}
+ VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
+ VERCEL_SCOPE_NAME: ""
+```
+
+This workflow does the following:
+
+1. Waits for the Vercel deployment to complete using the `ericallam/vercel-wait` action.
+2. Deploys the tasks to Trigger.dev using the `npx trigger.dev deploy` command. There's no need to use the `--skip-promotion` flag because we want to promote the deployment.
+3. Promotes the Vercel deployment using the `npx vercel promote` command.
+
+For this workflow to work, you need to set up the following secrets in your GitHub repository:
+
+- `TRIGGER_ACCESS_TOKEN`: Your Trigger.dev personal access token. View the instructions [here](/github-actions) to learn more.
+- `VERCEL_TOKEN`: Your Vercel personal access token. You can find this in your Vercel account settings.
+- `VERCEL_PROJECT_ID`: Your Vercel project ID. You can find this in your Vercel project settings.
+- `VERCEL_SCOPE_NAME`: Your Vercel team slug.
+
+Checkout our [example repo](https://github.com/ericallam/vercel-atomic-deploys) to see this workflow in action.
+
+
+ We are using the `ericallam/vercel-wait` action above as a fork of the [official
+ tj-actions/vercel-wait](https://github.com/tj-actions/vercel-wait) action because there is a bug
+ in the official action that exits early if the deployment isn't found in the first check. I've
+ opened a PR for this issue [here](https://github.com/tj-actions/vercel-wait/pull/106).
+
diff --git a/docs/deployment/auto-assign-production-domains.png b/docs/deployment/auto-assign-production-domains.png
new file mode 100644
index 0000000000..2285aa1450
Binary files /dev/null and b/docs/deployment/auto-assign-production-domains.png differ
diff --git a/docs/deployment/my-first-deployment.png b/docs/deployment/my-first-deployment.png
new file mode 100644
index 0000000000..8041670742
Binary files /dev/null and b/docs/deployment/my-first-deployment.png differ
diff --git a/docs/deployment/overview.mdx b/docs/deployment/overview.mdx
new file mode 100644
index 0000000000..582d6b609c
--- /dev/null
+++ b/docs/deployment/overview.mdx
@@ -0,0 +1,233 @@
+---
+title: "Deployment"
+sidebarTitle: "Overview"
+description: "Learn how to deploy your tasks to Trigger.dev."
+---
+
+Before you can run production workloads on Trigger.dev, you need to deploy your tasks. The only way to do this at the moment is through the [deploy CLI command](/cli-deploy):
+
+
+
+```bash npm
+npx trigger.dev@latest deploy
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest deploy
+```
+
+```bash yarn
+yarn dlx trigger.dev@latest deploy
+```
+
+
+
+## Deploying 101
+
+Let's assume you have an existing trigger.dev project with a few tasks that you have been running locally but now want to deploy to the Trigger.dev cloud (or your self-hosted instance).
+
+First, let's make sure you are logged in to the CLI (if you haven't already):
+
+```bash
+npx trigger.dev login
+```
+
+This will open a browser window where you can log in with your Trigger.dev account and link your CLI.
+
+Now you can deploy your tasks:
+
+```bash
+npx trigger.dev deploy
+```
+
+This should print out a success message and let you know a new version has been deployed:
+
+```bash
+Trigger.dev (3.3.16)
+------------------------------------------------------
+┌ Deploying project
+│
+◇ Retrieved your account details for eric@trigger.dev
+│
+◇ Successfully built code
+│
+◇ Successfully deployed version 20250228.1
+│
+└ Version 20250228.1 deployed with 4 detected tasks
+```
+
+Now if you visit your Trigger.dev dashboard you should see the new version deployed:
+
+
+
+
+ Deploying consists of building your tasks and uploading them to the Trigger.dev cloud. This
+ process can take a few seconds to a few minutes depending on the size of your project.
+
+
+## Triggering deployed tasks
+
+Once you have deployed your tasks, you can trigger tasks exactly the same way you did locally, but with the "PROD" API key:
+
+
+
+Copy the API key from the dashboard and set the `TRIGGER_SECRET_KEY` environment variable, and then any tasks you trigger will run against the deployed version:
+
+```txt .env
+TRIGGER_SECRET_KEY="tr_prod_abc123"
+```
+
+Now you can trigger your tasks:
+
+```ts
+import { myTask } from "./trigger/tasks";
+
+await myTask.trigger({ foo: "bar" });
+```
+
+See our [triggering tasks](/triggering) guide for more information.
+
+## Versions
+
+When you deploy your tasks, Trigger.dev creates a new version of all tasks in your project. A version is a snapshot of your tasks at a certain point in time. This ensures that tasks are not affected by changes to the code.
+
+### Current version
+
+When you deploy, the version number is automatically incremented, and the new version is set as the current version for that environment.
+
+
+ A single environment (prod, staging, etc.) can only have a single "current" version at a time.
+
+
+The current version defines which version of the code new task runs will execute against. When a task run starts, it is locked to the current version. This ensures that the task run is not affected by changes to the code. Retries of the task run will also be locked to the original version.
+
+
+ When you Replay a run in the dashboard we will create a new run, locked to the current version and
+ not necessarily the version of the original run.
+
+
+### Version locking
+
+You can optionally specify the version when triggering a task using the `version` parameter. This is useful when you want to run a task against a specific version of the code:
+
+```ts
+await myTask.trigger({ foo: "bar" }, { version: "20250228.1" });
+```
+
+If you want to set a global version to run all tasks against, you can use the `TRIGGER_VERSION` environment variable:
+
+```bash
+TRIGGER_VERSION=20250228.1
+```
+
+### Child tasks and auto-version locking
+
+Trigger and wait functions version lock child task runs to the parent task run version. This ensures the results from child runs match what the parent task is expecting. If you don't wait then version locking doesn't apply.
+
+| Trigger function | Parent task version | Child task version | isLocked |
+| ----------------------- | ------------------- | ------------------ | -------- |
+| `trigger()` | `20240313.2` | Current | No |
+| `batchTrigger()` | `20240313.2` | Current | No |
+| `triggerAndWait()` | `20240313.2` | `20240313.2` | Yes |
+| `batchTriggerAndWait()` | `20240313.2` | `20240313.2` | Yes |
+
+### Skipping promotion
+
+When you deploy, the new version is automatically promoted be the current version. If you want to skip this promotion, you can use the `--skip-promotion` flag:
+
+```bash
+npx trigger.dev deploy --skip-promotion
+```
+
+This will create a new deployment version but not promote it to the current version:
+
+
+
+This allows you to deploy and test a new version without affecting new task runs. When you want to promote the version, you can do so from the CLI:
+
+```bash
+npx trigger.dev promote 20250228.1
+```
+
+Or from the dashboard:
+
+
+
+To learn more about skipping promotion and how this enables atomic deployments, see our [Atomic deployment](/deployment/atomic-deployment) guide.
+
+## Staging deploys
+
+By default, the `deploy` command will deploy to the `prod` environment. If you want to deploy to a different environment, you can use the `--env` flag:
+
+```bash
+npx trigger.dev deploy --env staging
+```
+
+
+ If you are using the Trigger.dev Cloud, staging deploys are only available on the Hobby and Pro
+ plans.
+
+
+This will create an entirely new version of your tasks for the `staging` environment, with a new version number and an independent current version:
+
+
+
+Now you can trigger tasks against the staging environment by setting the `TRIGGER_SECRET_KEY` environment variable to the staging API key:
+
+```txt .env
+TRIGGER_SECRET_KEY="tr_stg_abcd123"
+```
+
+Currently, we only support two environments: `prod` and `staging`. Multiple environments are on our roadmap which you can track [here](https://feedback.trigger.dev/p/more-environments).
+
+## Environment variables
+
+To add custom environment variables to your deployed tasks, you need to add them to your project in the Trigger.dev dashboard, or automatically sync them using our [syncEnvVars](/config/config-file#syncenvvars) or [syncVercelEnvVars](/config/config-file#syncvercelenvvars) build extensions.
+
+For more information on environment variables, see our [environment variables](/deploy-environment-variables) guide.
+
+## Troubleshooting
+
+When things go wrong with your deployment, there are a few things you can do to diagnose the issue:
+
+### Dry runs
+
+You can do a "dry run" of the deployment to see what is built and uploaded without actually deploying:
+
+```bash
+npx trigger.dev deploy --dry-run
+
+# Dry run complete. View the built project at //.trigger/tmp/
+```
+
+The dry run will output the build directory where you can inspect the built tasks and dependencies. You can also compress this directory and send it to us if you need help debugging.
+
+### Debug logs
+
+You can run the deploy command with `--log-level debug` at the end. This will print out a lot of information about the deploy. If you can't figure out the problem from the information below please join [our Discord](https://trigger.dev/discord) and create a help forum post. Do NOT share the extended debug logs publicly as they might reveal private information about your project.
+
+### Common issues
+
+#### `Failed to build project image: Error building image`
+
+There should be a link below the error message to the full build logs on your machine. Take a look at these to see what went wrong. Join [our Discord](https://trigger.dev/discord) and you share it privately with us if you can't figure out what's going wrong. Do NOT share these publicly as the verbose logs might reveal private information about your project.
+
+#### `Deployment encountered an error`
+
+Usually there will be some useful guidance below this message. If you can't figure out what's going wrong then join [our Discord](https://trigger.dev/discord) and create a Help forum post with a link to your deployment.
+
+#### `No loader is configured for ".node" files`
+
+This happens because `.node` files are native code and can't be bundled like other packages. To fix this, add your package to [`build.external`](/config/config-file#external) in the `trigger.config.ts` file like this:
+
+```ts trigger.config.ts
+import { defineConfig } from "@trigger.dev/sdk/v3";
+
+export default defineConfig({
+ project: "",
+ // Your other config settings...
+ build: {
+ external: ["your-node-package"],
+ },
+});
+```
diff --git a/docs/deployment/promote-button.png b/docs/deployment/promote-button.png
new file mode 100644
index 0000000000..d192e49acc
Binary files /dev/null and b/docs/deployment/promote-button.png differ
diff --git a/docs/deployment/skip-promotion.png b/docs/deployment/skip-promotion.png
new file mode 100644
index 0000000000..c1961197f4
Binary files /dev/null and b/docs/deployment/skip-promotion.png differ
diff --git a/docs/deployment/staging-deploy.png b/docs/deployment/staging-deploy.png
new file mode 100644
index 0000000000..e999e77dc1
Binary files /dev/null and b/docs/deployment/staging-deploy.png differ
diff --git a/docs/docs.json b/docs/docs.json
index 46fae45d65..ebbf443f7f 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -18,37 +18,56 @@
"groups": [
{
"group": "Getting started",
- "pages": ["introduction", "quick-start", "video-walkthrough", "how-it-works", "limits"]
+ "pages": [
+ "introduction",
+ "quick-start",
+ "video-walkthrough",
+ "how-it-works",
+ "limits"
+ ]
},
{
"group": "Fundamentals",
"pages": [
{
"group": "Tasks",
- "pages": ["tasks/overview", "tasks/schemaTask", "tasks/scheduled"]
+ "pages": [
+ "tasks/overview",
+ "tasks/schemaTask",
+ "tasks/scheduled"
+ ]
},
"triggering",
"runs",
"apikeys",
{
"group": "Configuration",
- "pages": ["config/config-file", "config/extensions/overview"]
+ "pages": [
+ "config/config-file",
+ "config/extensions/overview"
+ ]
}
]
},
{
"group": "Development",
- "pages": ["cli-dev", "run-tests"]
+ "pages": [
+ "cli-dev",
+ "run-tests"
+ ]
},
{
"group": "Deployment",
"pages": [
- "cli-deploy",
+ "deployment/overview",
"deploy-environment-variables",
"github-actions",
+ "deployment/atomic-deployment",
{
"group": "Deployment integrations",
- "pages": ["vercel-integration"]
+ "pages": [
+ "vercel-integration"
+ ]
}
]
},
@@ -60,7 +79,13 @@
"errors-retrying",
{
"group": "Wait",
- "pages": ["wait", "wait-for", "wait-until", "wait-for-event", "wait-for-request"]
+ "pages": [
+ "wait",
+ "wait-for",
+ "wait-until",
+ "wait-for-event",
+ "wait-for-request"
+ ]
},
"queue-concurrency",
"versioning",
@@ -101,7 +126,6 @@
"realtime/subscribe-to-batch"
]
},
-
{
"group": "CLI",
"pages": [
@@ -113,6 +137,7 @@
"cli-init-commands",
"cli-dev-commands",
"cli-deploy-commands",
+ "cli-promote-commands",
"cli-whoami-commands",
"cli-logout-commands",
"cli-list-profiles-commands",
@@ -146,7 +171,11 @@
},
{
"group": "Help",
- "pages": ["community", "help-slack", "help-email"]
+ "pages": [
+ "community",
+ "help-slack",
+ "help-email"
+ ]
}
]
},
@@ -167,7 +196,10 @@
},
{
"group": "Tasks API",
- "pages": ["management/tasks/trigger", "management/tasks/batch-trigger"]
+ "pages": [
+ "management/tasks/trigger",
+ "management/tasks/batch-trigger"
+ ]
},
{
"group": "Runs API",
@@ -213,7 +245,9 @@
"groups": [
{
"group": "Introduction",
- "pages": ["guides/introduction"]
+ "pages": [
+ "guides/introduction"
+ ]
},
{
"group": "Frameworks",
@@ -326,7 +360,10 @@
"href": "https://trigger.dev"
},
"api": {
- "openapi": ["openapi.yml", "v3-openapi.yaml"],
+ "openapi": [
+ "openapi.yml",
+ "v3-openapi.yaml"
+ ],
"playground": {
"display": "simple"
}
@@ -501,4 +538,4 @@
"destination": "/management/overview"
}
]
-}
+}
\ No newline at end of file
diff --git a/docs/github-actions.mdx b/docs/github-actions.mdx
index 5bde211352..0732f5c4f1 100644
--- a/docs/github-actions.mdx
+++ b/docs/github-actions.mdx
@@ -95,8 +95,7 @@ If you already have a GitHub action file, you can just add the final step "🚀
-
-## Version pinning
+## 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.
Tip: add the deploy command to your `package.json` file to keep versions managed in the same place. For example:
@@ -122,7 +121,6 @@ Your workflow file will follow the version specified in the `package.json` scrip
You should use the version you run locally during dev and manual deploy. The current version is displayed in the banner, but you can also check it by appending `--version` to any command.
-
## Self-hosting
When self-hosting, you will have to take a few additional steps:
@@ -180,4 +178,4 @@ jobs:
npx trigger.dev@latest deploy --self-hosted --push
```
-
\ No newline at end of file
+
diff --git a/docs/snippets/cli-commands-deploy.mdx b/docs/snippets/cli-commands-deploy.mdx
index bbd3ddd8c4..78289eebc6 100644
--- a/docs/snippets/cli-commands-deploy.mdx
+++ b/docs/snippets/cli-commands-deploy.mdx
@@ -1,9 +1,9 @@
-import ProjectPathArg from '/snippets/cli-args-project-path.mdx';
-import CommonOptions from '/snippets/cli-options-common.mdx';
-import ProjectRefOption from '/snippets/cli-options-project-ref.mdx';
-import EnvFileOption from '/snippets/cli-options-env-file.mdx';
-import ConfigFileOption from '/snippets/cli-options-config-file.mdx';
-import SkipUpdateCheckOption from '/snippets/cli-options-skip-update-check.mdx';
+import ProjectPathArg from "/snippets/cli-args-project-path.mdx";
+import CommonOptions from "/snippets/cli-options-common.mdx";
+import ProjectRefOption from "/snippets/cli-options-project-ref.mdx";
+import EnvFileOption from "/snippets/cli-options-env-file.mdx";
+import ConfigFileOption from "/snippets/cli-options-config-file.mdx";
+import SkipUpdateCheckOption from "/snippets/cli-options-skip-update-check.mdx";
Run the command like this:
@@ -63,8 +63,8 @@ npx trigger.dev@latest deploy [path]
Create a deployable build but don't deploy it. Prints out the build path so you can inspect it.
-
- The platform to build the deployment image for. Defaults to `linux/amd64`.
+
+ Skips automatically promoting the newly deployed version to the "current" deploy.
@@ -96,7 +96,8 @@ These options are typically used when [self-hosting](/open-source-self-hosting)
- Specify the registry to push the image to when using `--self-hosted`. Will automatically enable `--push`.
+ Specify the registry to push the image to when using `--self-hosted`. Will automatically enable
+ `--push`.
diff --git a/docs/snippets/cli-commands-promote.mdx b/docs/snippets/cli-commands-promote.mdx
new file mode 100644
index 0000000000..e0b3c460f9
--- /dev/null
+++ b/docs/snippets/cli-commands-promote.mdx
@@ -0,0 +1,35 @@
+import CommonOptions from "/snippets/cli-options-common.mdx";
+
+Run the command like this:
+
+
+
+```bash npm
+npx trigger.dev@latest promote [version]
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest promote [version]
+```
+
+```bash yarn
+yarn dlx trigger.dev@latest promote [version]
+```
+
+
+
+## Arguments
+
+```
+npx trigger.dev@latest promote [version]
+```
+
+
+ The version to promote. This is the version that was previously deployed.
+
+
+### Common options
+
+These options are available on most commands.
+
+