Skip to main content
Run the command like this:
This will fail in CI if any version mismatches are detected. Ensure everything runs locally first using the dev 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).
You can also setup GitHub Actions to deploy your tasks automatically.

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.
--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.

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

These options are typically used when self-hosting or for local development.
--self-hosted
Builds and loads the image using your local docker. Use the --registry option to specify the registry to push the image to when using --self-hosted, or just use --push to push to the default registry.
--skip-deploy | -D
Load the built image into your local docker.
--load-image
Loads the image into your local docker after building it.
--registry
Specify the registry to push the image to when using --self-hosted. Will automatically enable --push.
--push
When using the --self-hosted flag, push the image to the registry.
--namespace
The namespace to use when pushing the image to the registry. For example, if pushing to Docker Hub, the namespace is your Docker Hub username.
--network
The networking mode for RUN instructions when using --self-hosted.

Examples

Push to Docker Hub (self-hosted)

An example of deploying to Docker Hub when using a self-hosted setup: