- Optionally updates packages when running locally.
- Compiles and bundles the code.
- Deploys the code to the Trigger.dev instance.
- 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 theTRIGGER_ACCESS_TOKEN environment variable. Please see the CI / GitHub Actions guide for more information.
Arguments
[path]
The path to the project. Defaults to the current directory.
Options
--config | -c
The name of the config file found at the project path. Defaults to
trigger.config.ts--project-ref | -p
The project ref. Required if there is no config 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 checking for
@trigger.dev package updates.--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.--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
Create a deployable build but don’t deploy it. Prints out the build path so you can inspect it.
--skip-promotion
Skips automatically promoting the newly deployed version to the “current” deploy.
--skip-sync-env-vars
Turn off syncing environment variables with the Trigger.dev instance.
--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.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
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.--local-build
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.--profile
The login profile to use. Defaults to “default”.
--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 | -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
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 | -h
Shows the help information for the command.
--version | -v
Displays the version number of the CLI.
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:TRIGGER_ACCESS_TOKEN and TRIGGER_API_URL environment variables. See the GitHub Actions guide for more details.