Files
triggerdotdev--trigger.dev/docs/snippets/cli-commands-deploy.mdx
T
nicktrn 8d1e41693a v3: self-hosting support for latest packages (#1319)
* display --profile flag after init if used

* add containerfile debug logs

* log all indexing errors in case of connection issues

* specify dockerfile syntax version

* add network flag for self-hosting

* move all self-hosting tags to latest

* add self-hosting update section

* manual setup subsection

* registry flag implies push

* add changeset
2024-09-18 17:07:47 +01:00

128 lines
3.5 KiB
Plaintext

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';
Run the command like this:
<CodeGroup>
```bash npm
npx trigger.dev@latest deploy
```
```bash pnpm
pnpm dlx trigger.dev@latest deploy
```
```bash yarn
yarn dlx trigger.dev@latest deploy
```
</CodeGroup>
<Warning>
This will fail in CI if any version mismatches are detected. Ensure everything runs locally first
using the [dev](/cli-dev-commands) command and don't bypass the version checks!
</Warning>
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](/github-actions) to deploy your tasks automatically.
## Arguments
```
npx trigger.dev@latest deploy [path]
```
<ProjectPathArg />
## Options
<ConfigFileOption />
<ProjectRefOption />
<EnvFileOption />
<SkipUpdateCheckOption />
<ParamField body="Environment" type="--env | -e">
Defaults to `prod` but you can specify `staging`.
</ParamField>
<ParamField body="Dry run" type="--dry-run">
Create a deployable build but don't deploy it. Prints out the build path so you can inspect it.
</ParamField>
<ParamField body="Build platform" type="--build-platform">
The platform to build the deployment image for. Defaults to `linux/amd64`.
</ParamField>
<ParamField body="Skip syncing env vars" type="--skip-sync-env-vars">
Turn off syncing environment variables with the Trigger.dev instance.
</ParamField>
### Common options
These options are available on most commands.
<CommonOptions />
### Self-hosting
These options are typically used when [self-hosting](/open-source-self-hosting) or for local development.
<ParamField body="Self-hosted (builds locally)" type="--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.
</ParamField>
<ParamField body="Skip deploying the image" type="--skip-deploy | -D">
Load the built image into your local docker.
</ParamField>
<ParamField body="Load image" type="--load-image">
Loads the image into your local docker after building it.
</ParamField>
<ParamField body="Registry" type="--registry">
Specify the registry to push the image to when using `--self-hosted`. Will automatically enable `--push`.
</ParamField>
<ParamField body="Push image" type="--push">
When using the `--self-hosted` flag, push the image to the registry.
</ParamField>
<ParamField body="Namespace" type="--namepsace">
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.
</ParamField>
<ParamField body="Network" type="--network">
The networking mode for RUN instructions when using `--self-hosted`.
</ParamField>
## Examples
### Push to Docker Hub (self-hosted)
An example of deploying to Docker Hub when using a self-hosted setup:
```bash
npx trigger.dev@latest deploy \
--self-hosted \
--load-image \
--registry docker.io \
--namespace mydockerhubusername
```