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
Copy file name to clipboardExpand all lines: docs/open-source-self-hosting.mdx
+23-20Lines changed: 23 additions & 20 deletions
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,8 @@ title: "Self-hosting"
3
3
description: "You can self-host Trigger.dev on your own infrastructure."
4
4
---
5
5
6
+
<Warning>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.</Warning>
7
+
6
8
<Note>This guide is for Docker only. We don't currently provide documentation for Kubernetes.</Note>
7
9
8
10
## Overview
@@ -23,27 +25,18 @@ It's dangerous to go alone! Join the self-hosting channel on our [Discord server
23
25
24
26
<Note>The v3 worker components don't have ARM support yet.</Note>
25
27
26
-
This guide outlines a quick way to start self-hosting Trigger.dev. Scaling, security, and reliability concerns are not fully addressed here. It's unlikely to result in a production-ready deployment on its own, but it's a good starting point.
28
+
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.
27
29
28
-
As self-hosted deployments tend to have unique requirements and configurations, we don't provide specific advice for scaling up or improving security and reliability.
30
+
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.
29
31
30
32
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.
31
33
32
34
<Accordiontitle="Please consider these additional warnings">
33
-
- The Docker [checkpoint command](https://docs.docker.com/reference/cli/docker/checkpoint/) is an
34
-
experimental feature which may not work as expected. It won't be enabled by default. Instead, the
35
-
containers will stay up and their processes frozen. They won't consume CPU but they _will_ consume
36
-
RAM. - The Docker provider does not currently enforce any resource limits. This means your tasks
37
-
can consume up to the total machine CPU and RAM. Having no limits may be preferable when
38
-
self-hosting, but can impact the performance of other services. - The worker components (not the
39
-
tasks!) have direct access to the Docker socket. This means they can run any Docker command. To
40
-
restrict access, you may want to consider using [Docker Socket
41
-
Proxy](https://github.com/Tecnativa/docker-socket-proxy). - The task containers are running with
42
-
host networking. This means there is no network isolation between them and the host machine. They
43
-
will be able to access any networked service on the host. - There is currently no support for
44
-
adding multiple worker machines. This would require a more elaborate provider, or possibly a
45
-
switch to Docker Swarm. This is not currently planned, but you are welcome to
- 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.
36
+
- 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.
37
+
- 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).
38
+
- 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.
39
+
- There is currently no support for adding multiple worker machines, but we're working on it.
47
40
</Accordion>
48
41
49
42
## Requirements
@@ -67,24 +60,34 @@ Some very basic steps to get started:
0 commit comments