docs/snippets/cli-commands-deploy.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"; import BranchOption from "/snippets/cli-options-branch.mdx";
Run the command like this:
<CodeGroup>npx trigger.dev@latest deploy
pnpm dlx trigger.dev@latest deploy
yarn dlx trigger.dev@latest deploy
It performs a few steps to deploy:
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.
npx trigger.dev@latest deploy [path]
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="Native build" type="--native-build"> Use the native build server to install, bundle and build your project. </ParamField> <ParamField body="Local bundle" type="--local-bundle"> Install and bundle on your machine, then build the image on the build server from the uploaded bundle. Requires `--native-build`. Use it if you prefer dependencies to be installed on your machine rather than on the build server. </ParamField> <ParamField body="Detach" type="--detach"> Exit once the build is queued instead of streaming the build logs. The deployment continues on the build server. Requires `--native-build`. </ParamField> <ParamField body="Depot build" type="--depot-build"> Build the image with Depot, the default build provider. </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> <ParamField body="Build logs" type="--build-logs"> How build logs are shown: `compact` (default, a single updating line) or `full` (every log line). CI and piped output always use `full`. </ParamField>These options are available on most commands.
<CommonOptions />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:
npx trigger.dev@latest deploy
For CI/CD environments, set TRIGGER_ACCESS_TOKEN and TRIGGER_API_URL environment variables. See the GitHub Actions guide for more details.