import CorepackError from "/snippets/corepack-error.mdx";

Before you can run production workloads on Trigger.dev, you need to deploy your tasks. The manual way to do this is the deploy CLI command. You can also deploy automatically with the GitHub integration or the Vercel integration:

npx trigger.dev@latest deploy

pnpm dlx trigger.dev@latest deploy

yarn dlx trigger.dev@latest deploy

Let's assume you have an existing trigger.dev project with a few tasks that you have been running locally but now want to deploy to the Trigger.dev cloud (or your self-hosted instance).

First, let's make sure you are logged in to the CLI (if you haven't already):

npx trigger.dev login

This will open a browser window where you can log in with your Trigger.dev account and link your CLI.

Now you can deploy your tasks:

npx trigger.dev deploy

This should print out a success message and let you know a new version has been deployed:

Trigger.dev (3.3.16)
------------------------------------------------------
┌  Deploying project
│
◇  Retrieved your account details for eric@trigger.dev
│
◇  Successfully built code
│
◇  Successfully deployed version 20250228.1
│
└  Version 20250228.1 deployed with 4 detected tasks

Now if you visit your Trigger.dev dashboard you should see the new version deployed:

Once you have deployed your tasks, open the API Keys page for the Production environment and create a named key with Trigger only access. Set the key as TRIGGER_SECRET_KEY in your backend environment. Tasks triggered with this key run against the deployed Production version:

TRIGGER_SECRET_KEY="tr_prod_sk_abc123"

Now you can trigger your tasks:

import { myTask } from "./trigger/tasks";

await myTask.trigger({ foo: "bar" });

See our triggering tasks guide for more information.

When you deploy your tasks, Trigger.dev creates a new version of all tasks in your project. A version is a snapshot of your tasks at a certain point in time. This ensures that tasks are not affected by changes to the code.

When you deploy, the version number is automatically incremented, and the new version is set as the current version for that environment.

The current version defines which version of the code new task runs will execute against. When a task run starts, it is locked to the current version. This ensures that the task run is not affected by changes to the code. Retries of the task run will also be locked to the original version.

You can optionally specify the version when triggering a task using the version parameter. This is useful when you want to run a task against a specific version of the code:

await myTask.trigger({ foo: "bar" }, { version: "20250228.1" });

If you want to set a global version to run all tasks against, you can use the TRIGGER_VERSION environment variable:

TRIGGER_VERSION=20250228.1

Trigger and wait functions version lock child task runs to the parent task run version. This ensures the results from child runs match what the parent task is expecting. If you don't wait then version locking doesn't apply.

When you deploy, the new version is automatically promoted be the current version. If you want to skip this promotion, you can use the --skip-promotion flag:

npx trigger.dev deploy --skip-promotion

This will create a new deployment version but not promote it to the current version:

This allows you to deploy and test a new version without affecting new task runs. When you want to promote the version, you can do so from the CLI:

npx trigger.dev promote 20250228.1

Or from the dashboard:

To keep your app and tasks in sync without coordinating promotion at all, see atomic deployments.

Use the --env flag to choose the environment you deploy to. If you don't pass it, the deploy command deploys to the prod environment, unless TRIGGER_ACCESS_TOKEN holds an API key for another environment. To deploy to staging:

npx trigger.dev deploy --env staging

This will create an entirely new version of your tasks for the staging environment, with a new version number and an independent current version:

To trigger tasks against Staging, create a named key in the Staging environment with Trigger only access and set it as TRIGGER_SECRET_KEY:

TRIGGER_SECRET_KEY="tr_stg_sk_abcd123"

For additional environments beyond prod and staging, you can use preview branches, which allow you to create isolated environments for each branch of your code.

By default we use a remote build provider to speed up builds. However, you can also force the build to happen locally on your machine using the --local-build flag:

npx trigger.dev deploy --local-build

To use local builds, you need the following tools installed on your machine:

• Docker (installation guide)
• Docker Buildx (installation guide)

To add custom environment variables to your deployed tasks, you need to add them to your project in the Trigger.dev dashboard, or automatically sync them using our syncEnvVars or syncVercelEnvVars build extensions.

For more information on environment variables, see our environment variables guide.

When things go wrong with your deployment, there are a few things you can do to diagnose the issue:

You can do a "dry run" of the deployment to see what is built and uploaded without actually deploying:

npx trigger.dev deploy --dry-run

#  Dry run complete. View the built project at /<project path>/.trigger/tmp/<build dir>

The dry run will output the build directory where you can inspect the built tasks and dependencies. You can also compress this directory and send it to us if you need help debugging.

You can run the deploy command with --log-level debug at the end. This will print out a lot of information about the deploy. If you can't figure out the problem from the information below please join our Discord and create a help forum post. Do NOT share the extended debug logs publicly as they might reveal private information about your project.

There should be a link below the error message to the full build logs on your machine. Take a look at these to see what went wrong. Join our Discord and you share it privately with us if you can't figure out what's going wrong. Do NOT share these publicly as the verbose logs might reveal private information about your project.

Sometimes these errors are caused by upstream availability issues with our remote build provider. In this case, you can try deploying with a local build using the --local-build flag. Refer to the Local builds section for more information.

Usually there will be some useful guidance below this message. If you can't figure out what's going wrong then join our Discord and create a Help forum post with a link to your deployment.

This happens because .node files are native code and can't be bundled like other packages. To fix this, add your package to build.external in the trigger.config.ts file like this:

import { defineConfig } from "@trigger.dev/sdk";

export default defineConfig({
  project: "<project ref>",
  // Your other config settings...
  build: {
    external: ["your-node-package"],
  },
});