You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -14,14 +14,15 @@ Should the burden ever get too much, we'd be happy to see you on [Trigger.dev cl
14
14
## What's new?
15
15
16
16
Goodbye v3, hello v4! We made quite a few changes:
17
-
-**Much simpler setup.** Provider + coordinator = supervisor. No more startup scripts. Just `docker compose up`.
17
+
-**Much simpler setup.** The provider and coordinator are now combined into a single supervisor. No more startup scripts, just `docker compose up`.
18
+
-**Automatic container cleanup.** The supervisor will automatically clean up containers that are no longer needed.
18
19
-**Support for multiple worker machines.** This is a big one, and we're very excited about it! You can now scale your workers horizontally as needed.
19
20
-**Resource limits enforced by default.** This means that tasks will be limited to the total CPU and RAM of the machine preset, preventing noisy neighbours.
20
21
-**No direct Docker socket access.** The compose file now comes with [Docker Socket Proxy](https://github.com/Tecnativa/docker-socket-proxy) by default. Yes, you want this.
21
22
-**No host networking.** All containers are now running with network isolation, using only the network access they need.
22
-
-**No checkpoint support.** This was only ever an experimental self-hosting feature and not recommended. It caused a bunch of issues. We decided to focus on the core features instead.
23
+
-**No checkpoint support.** This was only ever experimental when self-hosting and not recommended. It caused a bunch of issues. We decided to focus on the core features instead.
23
24
-**Built-in container registry and object storage.** You can now deploy and execute tasks without needing third party services for this.
24
-
-**Improved CLI commands.** You don't need any additional flags to deploy anymore, and there's a new `switch`command to easily switch between profiles.
25
+
-**Improved CLI commands.** You don't need any additional flags to deploy anymore, and there's a new command to easily `switch` between profiles.
25
26
-**Whitelisting for GitHub OAuth.** Any whitelisted email addresses will now also apply to sign ins via GitHub, unlike v3 where they only applied to magic links.
26
27
27
28
## Requirements
@@ -39,14 +40,14 @@ To run the webapp and worker components, you will need:
39
40
40
41
### Webapp
41
42
42
-
This will host the webapp, postgres, redis, and related services.
43
+
This machine will host the webapp, postgres, redis, and related services.
43
44
44
45
- 2+ vCPU
45
46
- 4+ GB RAM
46
47
47
48
### Worker
48
49
49
-
This will host the supervisor and all of the runs.
50
+
This machine will host the supervisor and all of the runs.
50
51
51
52
- 2+ vCPU
52
53
- 4+ GB RAM
@@ -86,26 +87,30 @@ cd webapp
86
87
docker compose up -d
87
88
```
88
89
89
-
4.Optional: Add traefik as a reverse proxy
90
+
4.Configure the webapp using the [environment variables](/self-hosting/env/webapp) in your `.env` file, then apply the changes:
90
91
91
92
```bash
92
-
docker compose -f ../docker-compose.traefik.yml up -d
93
+
docker compose up -d
93
94
```
94
95
95
-
5.Configure the webapp as needed using the [environment variables](/self-hosting/env/webapp) and apply the changes:
96
+
5.You should now be able to access the webapp at `http://localhost:8030`. When logging in, check the container logs for the magic link:
96
97
97
98
```bash
98
-
docker compose up -d
99
+
docker compose logs -f webapp
99
100
```
100
101
101
-
6. You should now be able to access the webapp at `http://localhost:8030`. When logging in, check the container logs for the magic link: `docker compose logs -f webapp`
102
-
103
-
7. Optional: To initialize a new project, run the following command:
102
+
6. (optional) To initialize a new project, run the following command:
104
103
105
104
```bash
106
105
npx trigger.dev@v4-beta init -p <project-ref> -a http://localhost:8030
107
106
```
108
107
108
+
{/* 7. Bonus: Add traefik as a reverse proxy
109
+
110
+
```bash
111
+
docker compose -f docker-compose.yml -f ../docker-compose.traefik.yml up -d
112
+
``` */}
113
+
109
114
### Worker
110
115
111
116
1. Clone the repository
@@ -128,50 +133,125 @@ cd worker
128
133
docker compose up -d
129
134
```
130
135
131
-
Configure the supervisor as needed using the [environment variables](/self-hosting/env/supervisor) and apply the changes:
136
+
4. Configure the supervisor using the [environment variables](/self-hosting/env/supervisor) in your `.env` file, including the [worker token](#worker-token).
137
+
138
+
5. Apply the changes:
132
139
133
140
```bash
134
141
docker compose up -d
135
142
```
136
143
137
-
Repeat as needed for additional workers.
144
+
6.Repeat as needed for additional workers.
138
145
139
146
### Combined
140
147
141
148
If you want to run the webapp and worker on the same machine, just replace the `up` command with the following:
142
149
143
150
```bash
144
151
# Run this from the /hosting/docker directory
145
-
docker compose -f docker-compose.webapp.yml -f docker-compose.worker.yml up -d
152
+
docker compose -f webapp/docker-compose.yml -f worker/docker-compose.yml up -d
146
153
```
147
154
148
-
And optionally add traefik as a reverse proxy:
155
+
{/*And optionally add traefik as a reverse proxy:
149
156
150
157
```bash
151
158
# Run this from the /hosting/docker directory
152
-
docker compose -f docker-compose.webapp.yml -f docker-compose.worker.yml -f docker-compose.traefik.yml up -d
159
+
docker compose -f webapp/docker-compose.yml -f worker/docker-compose.yml -f docker-compose.traefik.yml up -d
160
+
``` */}
161
+
162
+
## Worker token
163
+
164
+
When running the combined stack, worker bootstrap is handled automatically. When running the webapp and worker separately, you will need to manually set the worker token.
165
+
166
+
On the first run, the webapp will generate a worker token and store it in a shared volume. It will also print the token to the console. It should look something like this:
167
+
168
+
```bash
169
+
==========================
170
+
Trigger.dev Bootstrap - Worker Token
171
+
172
+
WARNING: This will only be shown once. Save it now!
You can then uncomment and set the `TRIGGER_WORKER_TOKEN` environment variable in your `.env` file.
156
190
157
-
There are several reasons to lock the version of your Docker images:
158
-
-**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.
159
-
-**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.
191
+
Don't forget to restart the worker container for the changes to take effect:
160
192
161
-
By default, the images will point at the latest versioned release via the `v4-beta` tag. You can override this by specifying a different tag in your `.env` file. For example:
193
+
```bash
194
+
# Run this from the /hosting/docker/worker directory
195
+
docker compose down
196
+
docker compose up -d
197
+
```
198
+
199
+
## Registry setup
200
+
201
+
The registry is used to store and pull deployment images. When testing the stack locally, the defaults should work out of the box.
202
+
203
+
When deploying to production, you will need to set the correct URL and generate secure credentials for the registry.
204
+
205
+
### Default settings
206
+
207
+
The default settings for the registry are:
208
+
209
+
- Registry: `localhost:5000`
210
+
- Username: `registry-user`
211
+
- Password: `very-secure-indeed`
212
+
213
+
You should change these before deploying to production, especially the password. You can find more information about how to do this in the official [registry docs](https://github.com/distribution/distribution/blob/735c161b53e7faf81a21ba94c55ac9edee081cd9/docs/deploying.md#native-basic-auth).
214
+
215
+
### Logging in
216
+
217
+
When self-hosting, builds run locally. You will have to login to the registry on every machine that runs the `deploy` command. You should only have to do this once:
162
218
163
219
```bash
164
-
TRIGGER_IMAGE_TAG=v4.0.0-v4-beta.21
220
+
docker login -u <username> <registry>
165
221
```
166
222
223
+
This will prompt for the password. Afterwards, the deploy command should work as expected.
224
+
225
+
## Object storage
226
+
227
+
This is mainly used for large payloads and outputs. There are a few simple steps to follow to get started.
228
+
229
+
### Default settings
230
+
231
+
The default settings for the object storage are:
232
+
233
+
- Endpoint: `http://localhost:9000`
234
+
- Username: `admin`
235
+
- Password: `very-safe-password`
236
+
237
+
You should change these before deploying to production, especially the password.
238
+
239
+
### Setup
240
+
241
+
1. Login to the dashboard: `http://localhost:9001`
242
+
243
+
2. Create a bucket named `packets`.
244
+
245
+
3. For production, you will want to set up a dedicated user and not use the root credentials above.
246
+
167
247
## Authentication
168
248
249
+
The specific set of variables required will depend on your choice of email transport or alternative login methods like GitHub OAuth.
250
+
169
251
### Magic link
170
252
171
253
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.
172
254
173
-
The specific set of variables required will depend on your choice of email transport.
174
-
175
255
#### Resend
176
256
177
257
```bash
@@ -228,23 +308,32 @@ All email addresses can sign up and log in this way. If you would like to restri
This will apply to all auth methods including magic link and GitHub OAuth.
232
312
233
-
## Troubleshooting
313
+
## Version locking
234
314
235
-
-**Deployment fails at the push step.** The machine running `deploy` needs registry access:
315
+
There are several reasons to lock the version of your Docker images:
316
+
- **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.
317
+
- **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.
318
+
319
+
By default, the images will point at the latest versioned release via the `v4-beta` tag. You can override this by specifying a different tag in your `.env` file. For example:
236
320
237
321
```bash
238
-
docker login -u <username><registry>
239
-
# this should now succeed
240
-
npx trigger.dev@v4-beta deploy
322
+
TRIGGER_IMAGE_TAG=v4.0.0-v4-beta.21
241
323
```
242
324
243
-
This needs to match the registry credentials. Defaults for the `localhost:5000` registry are `registry-user` and `very-safe-password`. You should change these.
325
+
## Troubleshooting
326
+
327
+
- **Deployment fails at the push step.** The machine running `deploy` needs registry access. See the [registry setup](#registry-setup) section for more details.
244
328
245
329
- **Magic links don't arrive.** The webapp container needs to be able to send emails. You probably need to set up an email transport. See the [authentication](#authentication) section for more details.
246
330
247
-
You should check the logs of the webapp container to see the magic link: `docker logs -f trigger-webapp-1`
331
+
You should check the logs of the webapp container to see the magic link:
332
+
333
+
```bash
334
+
# Run this from the /hosting/docker/webapp directory
335
+
docker compose logs -f webapp
336
+
```
248
337
249
338
## CLI usage
250
339
@@ -260,7 +349,7 @@ npx trigger.dev@v4-beta login -a http://trigger.example.com
260
349
261
350
Once you've logged in, you shouldn't have to specify the URL again with other commands.
262
351
263
-
####Profiles
352
+
### Profiles
264
353
265
354
You can specify a profile when logging in. This allows you to easily use the CLI with multiple instances of Trigger.dev. For example:
It can be useful to check you are logged into the correct instance. Running this will also show the API URL:
305
394
306
395
```bash
307
396
npx trigger.dev@v4-beta whoami
308
397
```
309
398
310
-
###CI / GitHub Actions
399
+
## CI / GitHub Actions
311
400
312
401
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
313
402
variables to point at your self-hosted instance and authenticate.
0 commit comments