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 BranchOption from "/snippets/cli-options-branch.mdx";
Run the command like this:
```bash npm
npx trigger.dev@latest deploy
```
```bash pnpm
pnpm dlx trigger.dev@latest deploy
```
```bash yarn
yarn dlx trigger.dev@latest deploy
```
This will fail in CI if any version mismatches are detected. Ensure everything runs locally first
using the [dev](/cli-dev-commands) command and don't bypass the version checks!
It performs a few steps to deploy:
1. Optionally updates packages when running locally.
2. Compiles and bundles the code.
3. Deploys the code to the Trigger.dev instance.
4. Registers the tasks as a new version in the environment (prod by default).
## Deploying from CI
When deploying from CI/CD environments such as GitHub Actions, GitLab CI, or Jenkins, you need to authenticate non-interactively by setting the `TRIGGER_ACCESS_TOKEN` environment variable. Please see the [CI / GitHub Actions guide](/github-actions) for more information.
## Arguments
```
npx trigger.dev@latest deploy [path]
```
## Options
Defaults to `prod` but you can specify `staging` or `preview`. If you specify `preview` we will
try and automatically detect the branch name from git.
Create a deployable build but don't deploy it. Prints out the build path so you can inspect it.
Skips automatically promoting the newly deployed version to the "current" deploy.
Turn off syncing environment variables with the Trigger.dev instance.
Attach your own identifier to this deployment — a commit SHA, release tag or CI run id, up to 128
characters. Your app can then send the same id when triggering, and runs are pinned to this
deployment. See [version skew protection](/deployment/version-skew-protection).
Repeating an id that is already deployed doesn't build again: the CLI reports the existing version,
sets the same outputs, and exits successfully. Repeating an id that has a build in flight is an
error. An id whose build failed rebuilds normally.
The short-circuit is keyed on the id, not on the build inputs — so redeploying the same id after
changing a synced environment variable produces no new build.
Start a new build for an `--external-id` that already has one. Non-destructive with respect to
deployments that already succeeded — both remain and the newer version wins. If a build for that
id is still in flight, `--force` **cancels** it first, so one id never has two live builds. A
cancelled build usually stops within seconds, but one running on another machine can keep going
briefly before it notices. Requires `--external-id`.
Force building the deployment image locally using your local Docker. This is automatic when self-hosting.
### Common options
These options are available on most commands.
### Self-hosting
When [self-hosting](/self-hosting/overview), builds are performed locally by default. Once you've logged in to your self-hosted instance using the CLI, you can deploy with:
```bash
npx trigger.dev@latest deploy
```
For CI/CD environments, set `TRIGGER_ACCESS_TOKEN` and `TRIGGER_API_URL` environment variables. See the [GitHub Actions guide](/github-actions#self-hosting) for more details.