Cli Commands Deploy

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:

<CodeGroup> </CodeGroup> <Warning> 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! </Warning>

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 for more information.

Arguments

<ProjectPathArg />

Options

<ConfigFileOption /> <ProjectRefOption /> <EnvFileOption /> <SkipUpdateCheckOption /> <ParamField body="Environment" type="--env | -e"> 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. </ParamField> <BranchOption /> <ParamField body="Dry run" type="--dry-run"> Create a deployable build but don't deploy it. Prints out the build path so you can inspect it. </ParamField> <ParamField body="Skip promotion" type="--skip-promotion"> Skips automatically promoting the newly deployed version to the "current" deploy. </ParamField> <ParamField body="Skip syncing env vars" type="--skip-sync-env-vars"> Turn off syncing environment variables with the Trigger.dev instance. </ParamField> <ParamField body="External id" type="--external-id"> 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. </ParamField>

<ParamField body="Force" type="--force"> 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`. </ParamField> <ParamField body="Local build" type="--local-build"> Force building the deployment image locally using your local Docker. This is automatic when self-hosting. </ParamField>

Common options

These options are available on most commands.

<CommonOptions />

Self-hosting

When self-hosting, builds are performed locally by default. Once you've logged in to your self-hosted instance using the CLI, you can deploy with:

For CI/CD environments, set TRIGGER_ACCESS_TOKEN and TRIGGER_API_URL environment variables. See the GitHub Actions guide for more details.