> ## Documentation Index
> Fetch the complete documentation index at: https://trigger.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# CLI deploy command

> Use the deploy command to deploy your tasks to Trigger.dev.

Run the command like this:

```bash npm theme={"theme":"css-variables"}
npx trigger.dev@latest deploy --env prod
```

```bash pnpm theme={"theme":"css-variables"}
pnpm dlx trigger.dev@latest deploy --env prod
```

```bash yarn theme={"theme":"css-variables"}
yarn dlx trigger.dev@latest deploy --env prod
```

> [!WARNING]
>
> This will fail in CI if any version mismatches are detected. Ensure everything runs locally first
> using the [dev](https://trigger.dev/docs/cli-dev-commands.md) 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 you pass with `--env`.

## 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](https://trigger.dev/docs/github-actions.md) for more information.

## Arguments

```
npx trigger.dev@latest deploy [path]
```

**Project path** `[path]`

The path to the project. Defaults to the current directory.

## Options

**Config file** `--config | -c`

The name of the config file found at the project path. Defaults to `trigger.config.ts`

**Project ref** `--project-ref | -p`

The project ref. Required if there is no config file.

**Env file** `--env-file`

Load environment variables from a file. This will only hydrate the `process.env` of the CLI
process, not the tasks.

**Skip update check** `--skip-update-check`

Skip checking for `@trigger.dev` package updates.

**Environment** `--env | -e`

The environment to deploy to: `prod`, `staging` or `preview`. If you specify `preview` we will
try and automatically detect the branch name from git. When you don't pass `--env`, the deploy
goes to the environment of the API key in `TRIGGER_ACCESS_TOKEN`, or to `prod` if you're using a
personal access token. We recommend always passing `--env`.

**Prod** `--prod`

Deploy to the `prod` environment. Shorthand for `--env prod`.

**Preview branch** `--branch | -b`

When using `--env preview` the branch is automatically detected from git. But you can manually
specify it by using this option, e.g. `--branch my-branch` or `-b my-branch`.

**Dry run** `--dry-run`

Create a deployable build but don't deploy it. Prints out the build path so you can inspect it.

**Skip promotion** `--skip-promotion`

Skips automatically promoting the newly deployed version to the "current" deploy.

**Skip syncing env vars** `--skip-sync-env-vars`

Turn off syncing environment variables with the Trigger.dev instance.

**External id** `--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](https://trigger.dev/docs/deployment/atomic-deployment.md).

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.

**Force** `--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`.

**Native build** `--native-build`

Use the native build server to install, bundle and build your project.

**Local bundle** `--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.

**Detach** `--detach`

Exit once the build is queued instead of streaming the build logs. The deployment continues on
the build server. Requires `--native-build`.

**Depot build** `--depot-build`

Build the image with Depot, ignoring the build path configured for your project.

**Local build** `--local-build`

Force building the deployment image locally using your local Docker. This is automatic when self-hosting.

**Build logs** `--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`.

### Common options

These options are available on most commands.

**Login profile** `--profile`

The login profile to use. Defaults to the current profile, which is set by your last `login` or `switch` (initially "default").

**API URL** `--api-url | -a`

Override the default API URL. If not specified, it uses `https://api.trigger.dev`. This can also be set via the `TRIGGER_API_URL` environment variable.

**Log level** `--log-level | -l`

The CLI log level to use. Options are `debug`, `info`, `log`, `warn`, `error`, and `none`. This does not affect the log level of your trigger.dev tasks. Defaults to `log`.

**Skip telemetry** `--skip-telemetry`

Opt-out of sending telemetry data. This can also be done via the `TRIGGER_TELEMETRY_DISABLED` environment variable. Just set it to anything other than an empty string.

**Help** `--help | -h`

Shows the help information for the command.

**Version** `--version | -v`

Displays the version number of the CLI.

### Self-hosting

When [self-hosting](https://trigger.dev/docs/self-hosting/overview.md), builds are performed locally by default. Once you've logged in to your self-hosted instance using the CLI, you can deploy with:

```bash theme={"theme":"css-variables"}
npx trigger.dev@latest deploy
```

For CI/CD environments, set `TRIGGER_ACCESS_TOKEN` and `TRIGGER_API_URL` environment variables. See the [GitHub Actions guide](https://trigger.dev/docs/github-actions.md#self-hosting) for more details.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.