diff --git a/.server-changes/retire-legacy-v3-dev-websocket.md b/.server-changes/retire-legacy-v3-dev-websocket.md new file mode 100644 index 00000000000..2ecb79e8ed6 --- /dev/null +++ b/.server-changes/retire-legacy-v3-dev-websocket.md @@ -0,0 +1,6 @@ +--- +area: webapp +type: breaking +--- + +Removed support for the end-of-life v3 `trigger dev` CLI. Starting a dev session with an old v3 CLI now returns an upgrade message instead of connecting - upgrade to the v4 CLI to continue using `trigger dev`. diff --git a/apps/webapp/app/v3/authenticatedSocketConnection.server.ts b/apps/webapp/app/v3/authenticatedSocketConnection.server.ts deleted file mode 100644 index a4f42bb142c..00000000000 --- a/apps/webapp/app/v3/authenticatedSocketConnection.server.ts +++ /dev/null @@ -1,181 +0,0 @@ -import { - clientWebsocketMessages, - IntervalService, - serverWebsocketMessages, -} from "@trigger.dev/core/v3"; -import { ZodMessageHandler, ZodMessageSender } from "@trigger.dev/core/v3/zodMessageHandler"; -import { Evt } from "evt"; -import { randomUUID } from "node:crypto"; -import type { CloseEvent, ErrorEvent, MessageEvent } from "ws"; -import { WebSocket } from "ws"; -import type { AuthenticatedEnvironment } from "~/services/apiAuth.server"; -import { logger } from "~/services/logger.server"; -import { DevQueueConsumer } from "./marqs/devQueueConsumer.server"; - -export class AuthenticatedSocketConnection { - public id: string; - public onClose: Evt = new Evt(); - - private _sender: ZodMessageSender; - private _consumer: DevQueueConsumer; - private _messageHandler: ZodMessageHandler; - private _pingService: IntervalService; - - constructor( - public ws: WebSocket, - public authenticatedEnv: AuthenticatedEnvironment, - private readonly ipAddress: string | string[] - ) { - this.id = randomUUID(); - - this._sender = new ZodMessageSender({ - schema: serverWebsocketMessages, - sender: async (message) => { - return new Promise((resolve, reject) => { - if (!ws.OPEN) { - return reject(new Error("Websocket is not open")); - } - - ws.send(JSON.stringify(message), {}, (err) => { - if (err) { - reject(err); - return; - } - - resolve(); - }); - }); - }, - canSendMessage() { - return ws.readyState === WebSocket.OPEN; - }, - }); - - this._consumer = new DevQueueConsumer(this.id, authenticatedEnv, this._sender, { - ipAddress: Array.isArray(this.ipAddress) ? this.ipAddress.join(", ") : this.ipAddress, - }); - - ws.addEventListener("message", this.#handleMessage.bind(this)); - ws.addEventListener("close", this.#handleClose.bind(this)); - ws.addEventListener("error", this.#handleError.bind(this)); - - ws.on("ping", (data) => { - logger.debug("[AuthenticatedSocketConnection] Received ping", { - id: this.id, - envId: this.authenticatedEnv.id, - data, - }); - }); - - ws.on("pong", (data) => { - // logger.debug("[AuthenticatedSocketConnection] Received pong", { - // id: this.id, - // envId: this.authenticatedEnv.id, - // data, - // }); - }); - - this._pingService = new IntervalService({ - onInterval: async () => { - if (ws.readyState !== WebSocket.OPEN) { - logger.debug("[AuthenticatedSocketConnection] Websocket not open, skipping ping"); - return; - } - - // logger.debug("[AuthenticatedSocketConnection] Sending ping", { - // id: this.id, - // envId: this.authenticatedEnv.id, - // }); - - ws.ping(); - }, - intervalMs: 45_000, - }); - this._pingService.start(); - - this._messageHandler = new ZodMessageHandler({ - schema: clientWebsocketMessages, - logger, - messages: { - READY_FOR_TASKS: async (payload) => { - await this._consumer.registerBackgroundWorker( - payload.backgroundWorkerId, - payload.inProgressRuns ?? [] - ); - }, - BACKGROUND_WORKER_DEPRECATED: async (payload) => { - await this._consumer.deprecateBackgroundWorker(payload.backgroundWorkerId); - }, - BACKGROUND_WORKER_MESSAGE: async (payload) => { - switch (payload.data.type) { - case "TASK_RUN_COMPLETED": { - await this._consumer.taskAttemptCompleted( - payload.backgroundWorkerId, - payload.data.completion, - payload.data.execution - ); - break; - } - case "TASK_RUN_FAILED_TO_RUN": { - await this._consumer.taskRunFailed( - payload.backgroundWorkerId, - payload.data.completion - ); - - break; - } - case "TASK_HEARTBEAT": { - await this._consumer.taskHeartbeat(payload.backgroundWorkerId, payload.data.id); - break; - } - case "TASK_RUN_HEARTBEAT": { - await this._consumer.taskRunHeartbeat(payload.backgroundWorkerId, payload.data.id); - break; - } - } - }, - }, - }); - } - - async initialize() { - this._sender.send("SERVER_READY", { id: this.id }); - } - - async #handleMessage(ev: MessageEvent) { - try { - const data = JSON.parse(ev.data.toString()); - - await this._messageHandler.handleMessage(data); - } catch (error) { - logger.error("[AuthenticatedSocketConnection] Failed to handle message", { - error: - error instanceof Error - ? { - message: error.message, - stack: error.stack, - } - : error, - message: ev.data.toString(), - }); - } - } - - async #handleClose(ev: CloseEvent) { - logger.debug("[AuthenticatedSocketConnection] Websocket closed", { ev }); - - this._pingService.stop(); - - await this._consumer.stop(); - - const result = this.onClose.post(ev); - - logger.debug("[AuthenticatedSocketConnection] Called onClose", { - result, - }); - } - - async #handleError(ev: ErrorEvent) { - logger.error("Websocket error", { ev }); - } -} diff --git a/apps/webapp/app/v3/handleWebsockets.server.ts b/apps/webapp/app/v3/handleWebsockets.server.ts index bb1350a52ee..47d6b997034 100644 --- a/apps/webapp/app/v3/handleWebsockets.server.ts +++ b/apps/webapp/app/v3/handleWebsockets.server.ts @@ -3,31 +3,15 @@ import { WebSocketServer, type WebSocket } from "ws"; import { authenticateApiKey } from "~/services/apiAuth.server"; import { logger } from "~/services/logger.server"; import { singleton } from "../utils/singleton"; -import { AuthenticatedSocketConnection } from "./authenticatedSocketConnection.server"; -import { Gauge } from "prom-client"; -import { metricsRegister } from "~/metrics.server"; -import { isV3Disabled, V3_DEV_DEPRECATION_MESSAGE } from "./engineDeprecation.server"; +import { V3_DEV_DEPRECATION_MESSAGE } from "./engineDeprecation.server"; export const wss = singleton("wss", initalizeWebSocketServer); -let authenticatedConnections: Map; - function initalizeWebSocketServer() { const server = new WebSocketServer({ noServer: true }); server.on("connection", handleWebSocketConnection); - authenticatedConnections = new Map(); - - new Gauge({ - name: "dev_authenticated_connections", - help: "Number of authenticated dev connections", - collect() { - this.set(authenticatedConnections.size); - }, - registers: [metricsRegister], - }); - return server; } @@ -59,35 +43,14 @@ async function handleWebSocketConnection(ws: WebSocket, req: IncomingMessage) { const authenticatedEnv = authenticationResult.environment; - // This legacy websocket is only used by the v3 `trigger dev` CLI (v4 uses a - // different dev transport). When the v3 shutdown is on, close it with a - // graceful reason instead of letting the CLI sit connected with no work. - if (isV3Disabled()) { - logger.warn("Rejected deprecated v3 dev CLI websocket connection", { - environmentId: authenticatedEnv.id, - projectId: authenticatedEnv.projectId, - organizationId: authenticatedEnv.organizationId, - }); - ws.close(1008, V3_DEV_DEPRECATION_MESSAGE); - return; - } - - const authenticatedConnection = new AuthenticatedSocketConnection( - ws, - authenticatedEnv, - req.headers["x-forwarded-for"] ?? req.socket.remoteAddress ?? "unknown" - ); - - authenticatedConnections.set(authenticatedConnection.id, authenticatedConnection); - - authenticatedConnection.onClose.attachOnce((closeEvent) => { - logger.debug("Websocket closed", { - closeEvent, - authenticatedConnectionId: authenticatedConnection.id, - }); - - authenticatedConnections.delete(authenticatedConnection.id); + // This websocket is only used by the legacy v3 `trigger dev` CLI (v4 uses a + // different dev transport). The v3 engine is end-of-lifed, so there is no + // longer any work to run here — close with the graceful upgrade message so + // an old CLI is told what to do instead of sitting connected. + logger.warn("Rejected deprecated v3 dev CLI websocket connection", { + environmentId: authenticatedEnv.id, + projectId: authenticatedEnv.projectId, + organizationId: authenticatedEnv.organizationId, }); - - await authenticatedConnection.initialize(); + ws.close(1008, V3_DEV_DEPRECATION_MESSAGE); } diff --git a/docs/docs.json b/docs/docs.json index 0a5ce9db8b9..c5a546636e2 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -286,8 +286,7 @@ { "group": "Environment variables", "pages": ["self-hosting/env/webapp", "self-hosting/env/supervisor"] - }, - "open-source-self-hosting" + } ] }, { @@ -735,9 +734,13 @@ "source": "/v3/upgrading-from-v2", "destination": "/guides/use-cases/upgrading-from-v2" }, + { + "source": "/open-source-self-hosting", + "destination": "/self-hosting/overview" + }, { "source": "/v3/open-source-self-hosting", - "destination": "/open-source-self-hosting" + "destination": "/self-hosting/overview" }, { "source": "/v3/:slug*", diff --git a/docs/github-repo.mdx b/docs/github-repo.mdx index 022155e18bb..89c9805d717 100644 --- a/docs/github-repo.mdx +++ b/docs/github-repo.mdx @@ -5,4 +5,4 @@ url: "https://github.com/triggerdotdev/trigger.dev" Trigger.dev is [Open Source on GitHub](https://github.com/triggerdotdev/trigger.dev). You can contribute to the project by submitting issues, pull requests, or simply by using it and providing feedback. -You can also [self-host](/open-source-self-hosting) the project if you want to run it on your own infrastructure. +You can also [self-host](/self-hosting/overview) the project if you want to run it on your own infrastructure. diff --git a/docs/open-source-self-hosting.mdx b/docs/open-source-self-hosting.mdx deleted file mode 100644 index 0664b2c52d3..00000000000 --- a/docs/open-source-self-hosting.mdx +++ /dev/null @@ -1,541 +0,0 @@ ---- -title: "Docker (legacy)" -description: "Self-host Trigger.dev on your own infrastructure using Docker." ---- - -This is a legacy guide for self-hosting v3 using Docker, you can find the v4 guide [here](/self-hosting/docker). - -Security, scaling, and reliability concerns are not fully addressed here. This guide is meant for evaluation purposes and won't result in a production-ready deployment. - -## Overview - - - Self-hosting architecture - - -The self-hosting guide covers two alternative setups. The first option uses a simple setup where you run everything on one server. With the second option, the webapp and worker components are split on two separate machines. - -You're going to need at least one Debian (or derivative) machine with Docker and Docker Compose installed. We'll also use Ngrok to expose the webapp to the internet. - -## Support - -It's dangerous to go alone! Join the self-hosting channel on our [Discord server](https://discord.gg/NQTxt5NA7s). - -## Caveats - -The v3 worker components don't have ARM support yet. - -This guide outlines a quick way to start self-hosting Trigger.dev for evaluation purposes - it won't result in a production-ready deployment. Security, scaling, and reliability concerns are not fully addressed here. - -As self-hosted deployments tend to have unique requirements and configurations, we don't provide specific advice for securing your deployment, scaling up, or improving reliability. - -Should the burden ever get too much, we'd be happy to see you on [Trigger.dev cloud](https://trigger.dev/pricing) where we deal with these concerns for you. - - - - The [docker checkpoint](https://docs.docker.com/reference/cli/docker/checkpoint/) command is an experimental feature which may not work as expected. It won't be enabled by default. Instead, the containers will stay up and their processes frozen. They won't consume CPU but they _will_ consume RAM. - - The `docker-provider` does not currently enforce any resource limits. This means your tasks can consume up to the total machine CPU and RAM. Having no limits may be preferable when self-hosting, but can impact the performance of other services. - - The worker components (not the tasks!) have direct access to the Docker socket. This means they can run any Docker command. To restrict access, you may want to consider using [Docker Socket Proxy](https://github.com/Tecnativa/docker-socket-proxy). - - The task containers are running with host networking. This means there is no network isolation between them and the host machine. They will be able to access any networked service on the host. - - There is currently no support for adding multiple worker machines, but we're working on it. - - -## Requirements - -- 4 CPU -- 8 GB RAM -- Debian or derivative -- Optional: A separate machine for the worker components - -You will also need a way to expose the webapp to the internet. This can be done with a reverse proxy, or with a service like Ngrok. We will be using the latter in this guide. - -## Option 1: Single server - -This is the simplest setup. You run everything on one server. It's a good option if you have spare capacity on an existing machine, and have no need to independently scale worker capacity. - -### Server setup - -Some very basic steps to get started: - -1. [Install Docker](https://docs.docker.com/get-docker/) -2. [Install Docker Compose](https://docs.docker.com/compose/install/) -3. [Install Ngrok](https://ngrok.com/download) - - -```bash -# add ngrok repo -curl -s https://ngrok-agent.s3.amazonaws.com/ngrok.asc | \ - sudo tee /etc/apt/trusted.gpg.d/ngrok.asc >/dev/null && \ - echo "deb https://ngrok-agent.s3.amazonaws.com buster main" | \ - sudo tee /etc/apt/sources.list.d/ngrok.list - -# add docker repo -curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc && \ - sudo chmod a+r /etc/apt/keyrings/docker.asc && \ - echo \ - "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \ - $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ - sudo tee /etc/apt/sources.list.d/docker.list > /dev/null - -# update and install -sudo apt-get update -sudo apt-get install -y \ - docker.io \ - docker-compose-plugin \ - ngrok -``` - - -### Trigger.dev setup - -1. Clone the [Trigger.dev docker repository](https://github.com/triggerdotdev/docker) - -```bash -git clone https://github.com/triggerdotdev/docker -cd docker -``` - -2. Run the start script and follow the prompts - -```bash -./start.sh # hint: you can append -d to run in detached mode -``` - -#### Manual - -Alternatively, you can follow these manual steps after cloning the docker repo: - -1. Create the `.env` file - -```bash -cp .env.example .env -``` - -2. Generate the required secrets - -```bash -echo MAGIC_LINK_SECRET=$(openssl rand -hex 16) -echo SESSION_SECRET=$(openssl rand -hex 16) -echo ENCRYPTION_KEY=$(openssl rand -hex 16) -echo PROVIDER_SECRET=$(openssl rand -hex 32) -echo COORDINATOR_SECRET=$(openssl rand -hex 32) -``` - -3. Replace the default secrets in the `.env` file with the generated ones - -4. Run docker compose to start the services - -```bash -. lib.sh # source the helper function -docker_compose -p=trigger up -``` - -### Tunnelling - -You will need to expose the webapp to the internet. You can use Ngrok for this. If you already have a working reverse proxy setup and a domain, you can skip to the last step. - -1. Start Ngrok. You may get prompted to sign up - it's free. - -```bash -./tunnel.sh -``` - -2. Copy the domain from the output, for example: `1234-42-42-42-42.ngrok-free.app` - -3. Uncomment the `TRIGGER_PROTOCOL` and `TRIGGER_DOMAIN` lines in the `.env` file. Set it to the domain you copied. - -```bash -TRIGGER_PROTOCOL=https -TRIGGER_DOMAIN=1234-42-42-42-42.ngrok-free.app -``` - -4. Quit the start script and launch it again, or run this: - -```bash -./stop.sh && ./start.sh -``` - -### Registry setup - -If you want to deploy v3 projects, you will need access to a Docker registry. The [CLI deploy](/cli-deploy-commands) command will push the images, and then the worker machine can pull them when needed. We will use Docker Hub as an example. - -1. Sign up for a free account at [Docker Hub](https://hub.docker.com/) - -2. Edit the `.env` file and add the registry details - -```bash -DEPLOY_REGISTRY_HOST=docker.io -DEPLOY_REGISTRY_NAMESPACE= -``` - -3. Log in to Docker Hub both locally and your server. For the split setup, this will be the worker machine. You may want to create an [access token](https://hub.docker.com/settings/security) for this. - -```bash -docker login -u docker.io -``` - -4. Required on some systems: Run the login command inside the `docker-provider` container so it can pull deployment images to run your tasks. - -```bash -docker exec -ti \ - trigger-docker-provider-1 \ - docker login -u docker.io -``` - -5. Restart the services - -```bash -./stop.sh && ./start.sh -``` - -6. You can now deploy v3 projects using the CLI with these flags: - -``` -npx trigger.dev@latest deploy --self-hosted --push -``` - -## Option 2: Split services - -With this setup, the webapp will run on a different machine than the worker components. This allows independent scaling of your workload capacity. - -### Webapp setup - -All steps are the same as for a single server, except for the following: - -1. **Startup.** Run the start script with the `webapp` argument - -```bash -./start.sh webapp -``` - -2. **Tunnelling.** This is now _required_. Please follow the [tunnelling](/open-source-self-hosting#tunnelling) section. - -### Worker setup - -1. **Environment variables.** Copy your `.env` file from the webapp to the worker machine: - -```bash -# an example using scp -scp -3 root@:docker/.env root@:docker/.env -``` - -2. **Startup.** Run the start script with the `worker` argument - -```bash -./start.sh worker -``` - -3. **Tunnelling.** This is _not_ required for the worker components. - -4. **Registry setup.** Follow the [registry setup](/open-source-self-hosting#registry-setup) section but run the last command on the worker machine - note the container name is different: - -```bash -docker exec -ti \ - trigger-worker-docker-provider-1 \ - docker login -u docker.io -``` - -## Additional features - -### Large payloads - -By default, payloads over 512KB will be offloaded to S3-compatible storage. If you don't provide the required env vars, runs with payloads larger than this will fail. - -For example, using Cloudflare R2: - -```bash -OBJECT_STORE_BASE_URL="https://..r2.cloudflarestorage.com" -OBJECT_STORE_ACCESS_KEY_ID="" -OBJECT_STORE_SECRET_ACCESS_KEY="" -``` - -Alternatively, you can increase the threshold: - -```bash -# size in bytes, example with 5MB threshold -TASK_PAYLOAD_OFFLOAD_THRESHOLD=5242880 -``` - -### Version locking - -There are several reasons to lock the version of your Docker images: -- **Backwards compatibility.** We try our best to maintain compatibility with older CLI versions, but it's not always possible. If you don't want to update your CLI, you can lock your Docker images to that specific version. -- **Ensuring full feature support.** Sometimes, new CLI releases will also require new or updated platform features. Running unlocked images can make any issues difficult to debug. Using a specific tag can help here as well. - -By default, the images will point at the latest versioned release via the `v3` tag. You can override this by specifying a different tag in your `.env` file. For example: - -```bash -TRIGGER_IMAGE_TAG=v3.0.4 -``` - -### Auth options - -By default, magic link auth is the only login option. If the `EMAIL_TRANSPORT` env var is not set, the magic links will be logged by the webapp container and not sent via email. - -Depending on your choice of mail provider/transport, you will want to configure a set of variables like one of the following: - -##### Resend: -```bash -EMAIL_TRANSPORT=resend -FROM_EMAIL= -REPLY_TO_EMAIL= -RESEND_API_KEY= -``` - -##### SMTP - -Note that setting `SMTP_SECURE=false` does _not_ mean the email is sent insecurely. -This simply means that the connection is secured using the modern STARTTLS protocol command instead of implicit TLS. -You should only set this to true when the SMTP server host directs you to do so (generally when using port 465) - -```bash -EMAIL_TRANSPORT=smtp -FROM_EMAIL= -REPLY_TO_EMAIL= -SMTP_HOST= -SMTP_PORT=587 -SMTP_SECURE=false -SMTP_USER= -SMTP_PASSWORD= -``` - -##### AWS Simple Email Service - -Credentials are to be supplied as with any other program using the AWS SDK. -In this scenario, you would likely either supply the additional environment variables `AWS_REGION`, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` or, when running on AWS, use credentials supplied by the EC2 IMDS. - -```bash -EMAIL_TRANSPORT=aws-ses -FROM_EMAIL= -REPLY_TO_EMAIL= -``` - -All email addresses can sign up and log in this way. If you would like to restrict this, you can use the `WHITELISTED_EMAILS` env var. For example: - -```bash -# every email that does not match this regex will be rejected -WHITELISTED_EMAILS="^(authorized@yahoo\.com|authorized@gmail\.com)$" -``` - -It's currently impossible to restrict GitHub OAuth logins by account name or email like above, so this method is _not recommended_ for self-hosted instances. It's also very easy to lock yourself out of your own instance. - -Only enable GitHub auth if you understand the risks! We strongly advise you against this. - -Your GitHub OAuth app needs a callback URL `https:///auth/github/callback` and you will have to set the following env vars: - -```bash -AUTH_GITHUB_CLIENT_ID= -AUTH_GITHUB_CLIENT_SECRET= -``` - -### Checkpoint support - - - This requires an _experimental Docker feature_. Successfully checkpointing a task today, does not - mean you will be able to restore it tomorrow. Your data may be lost. You've been warned! - - -Checkpointing allows you to save the state of a running container to disk and restore it later. This can be useful for -long-running tasks that need to be paused and resumed without losing state. Think fan-out and fan-in, or long waits in email campaigns. - -The checkpoints will be pushed to the same registry as the deployed images. Please see the [registry setup](#registry-setup) section for more information. - -#### Requirements - -- Debian, **NOT** a derivative like Ubuntu -- Additional storage space for the checkpointed containers - -#### Setup - -Underneath the hood this uses Checkpoint and Restore in Userspace, or [CRIU](https://github.com/checkpoint-restore/criu) in short. We'll have to do a few things to get this working: - -1. Install CRIU - -```bash -sudo apt-get update -sudo apt-get install criu -``` - -2. Tweak the config so we can successfully checkpoint our workloads - -```bash -mkdir -p /etc/criu - -cat << EOF >/etc/criu/runc.conf -tcp-close -EOF -``` - -3. Make sure everything works - -```bash -sudo criu check -``` - -3. Enable Docker experimental features, by adding the following to `/etc/docker/daemon.json` - -```json -{ - "experimental": true -} -``` - -4. Restart the Docker daemon - -```bash -sudo systemctl restart docker -``` - -5. Uncomment `FORCE_CHECKPOINT_SIMULATION=0` in your `.env` file. Alternatively, run this: - -```bash -echo "FORCE_CHECKPOINT_SIMULATION=0" >> .env -``` - -6. Restart the services - -```bash -# if you're running everything on the same machine -./stop.sh && ./start.sh - -# if you're running the worker on a different machine -./stop.sh worker && ./start.sh worker -``` - -## Updating - -Once you have everything set up, you will periodically want to update your Docker images. You can easily do this by running the update script and restarting your services: - -```bash -./update.sh -./stop.sh && ./start.sh -``` - -Sometimes, we will make more extensive changes that require pulling updated compose files, scripts, etc from our docker repo: - -```bash -git pull -./stop.sh && ./start.sh -``` - -Occasionally, you may also have to update your `.env` file, but we will try to keep these changes to a minimum. Check the `.env.example` file for new variables. - -### From beta - -If you're coming from the beta CLI package images, you will need to: -- **Stash you changes.** If you made any changes, stash them with `git stash`. -- **Switch branches.** We moved back to main. Run `git checkout main` in your docker repo. -- **Pull in updates.** We've added a new container for [Electric](https://github.com/electric-sql/electric) and made some other improvements. Run `git pull` to get the latest updates. -- **Apply your changes.** If you stashed your changes, apply them with `git stash pop`. -- **Update your images.** We've also published new images. Run `./update.sh` to pull them. -- **Restart all services.** Run `./stop.sh && ./start.sh` and you're good to go. - -In summary, run this wherever you cloned the docker repo: - -```bash -# if you made changes -git stash - -# switch to the main branch and pull the latest changes -git checkout main -git pull - -# if you stashed your changes -git stash pop - -# update and restart your services -./update.sh -./stop.sh && ./start.sh -``` - -## Troubleshooting - -- **Deployment fails at the push step.** The machine running `deploy` needs registry access: - -```bash -docker login -u -# this should now succeed -npx trigger.dev@latest deploy --self-hosted --push -``` - -- **Prod runs fail to start.** The `docker-provider` needs registry access: - -```bash -# single server? run this: -docker exec -ti \ - trigger-docker-provider-1 \ - docker login -u docker.io - -# split webapp and worker? run this on the worker: -docker exec -ti \ - trigger-worker-docker-provider-1 \ - docker login -u docker.io -``` - -## CLI usage - -This section highlights some of the CLI commands and options that are useful when self-hosting. Please check the [CLI reference](/cli-introduction) for more in-depth documentation. - -### Login - -To avoid being redirected to the [Trigger.dev Cloud](https://cloud.trigger.dev) login page when using the CLI, you can specify the URL of your self-hosted instance with the `--api-url` or `-a` flag. For example: - -```bash -npx trigger.dev@latest login -a http://trigger.example.com -``` - -Once you've logged in, the CLI will remember your login details and you won't need to specify the URL again with other commands. - -#### Custom profiles - -You can specify a custom profile when logging in. This allows you to easily use the CLI with our cloud product and your self-hosted instance at the same time. For example: - -``` -npx trigger.dev@latest login -a http://trigger.example.com --profile my-profile -``` - -You can then use this profile with other commands: - -``` -npx trigger.dev@latest dev --profile my-profile -``` - -To list all your profiles, use the `list-profiles` command: - -``` -npx trigger.dev@latest list-profiles -``` - -#### Verify login - -It can be useful to check you have successfully logged in to the correct instance. You can do this with the `whoami` command, which will also show the API URL: - -```bash -npx trigger.dev@latest whoami - -# with a custom profile -npx trigger.dev@latest whoami --profile my-profile -``` - -### Deploy - -On [Trigger.dev Cloud](https://cloud.trigger.dev), we build deployments remotely and push those images for you. When self-hosting you will have to do that locally yourself. This can be done with the `--self-hosted` and `--push` flags. For example: - -``` -npx trigger.dev@latest deploy --self-hosted --push -``` - -### CI / GitHub Actions - -When running the CLI in a CI environment, your login profiles won't be available. Instead, you can use the `TRIGGER_API_URL` and `TRIGGER_ACCESS_TOKEN` environment -variables to point at your self-hosted instance and authenticate. - -For more detailed instructions, see the [GitHub Actions guide](/github-actions). - - -## Telemetry - -By default, the Trigger.dev webapp sends telemetry data to our servers. This data is used to improve the product and is not shared with third parties. If you would like to opt-out of this, you can set the `TRIGGER_TELEMETRY_DISABLED` environment variable in your `.env` file. The value doesn't matter, it just can't be empty. For example: - -```bash -TRIGGER_TELEMETRY_DISABLED=1 -``` diff --git a/docs/quick-start.mdx b/docs/quick-start.mdx index 8e7e7cb0c01..1cc69141d7f 100644 --- a/docs/quick-start.mdx +++ b/docs/quick-start.mdx @@ -57,7 +57,7 @@ If I've already run init and want the MCP server, run: npx trigger.dev@latest in -Sign up at [Trigger.dev Cloud](https://cloud.trigger.dev) (or [self-host](/open-source-self-hosting)). The onboarding flow will guide you through creating your first organization and project. +Sign up at [Trigger.dev Cloud](https://cloud.trigger.dev) (or [self-host](/self-hosting/overview)). The onboarding flow will guide you through creating your first organization and project.