feat: Self-Hosted Guide with just Docker?

[deadcoder0904]

Is your feature request related to a problem? Please describe.

Why not provide a simple Docker guide rather than platform-specific guides?

Describe the solution you'd like to see

A simple Docker step-by-step guide.

Describe alternate solutions

I guess I can perform trial & error with other guides (fly, supabase) to see what environment variables are required but would prefer a step-by-step answer.

Do I need all of these environment variables? or only 5 of these mentioned in Kubernetes docs? Like if I compare, I do see an extra RUNTIME_PLATFORM?

Also, are the self-hosted docs for v2 or v3? I'm trying trigger for 1st time only so don't know.

Additional information

I understand it goes against business incentives but if you're gonna promote it, you should provide a step-by-step guide in the docs. Otherwise, it just seems like a marketing gimic. Even though it does look easier to figure it out but would be cool if it follows Supabase footsteps. In the end, the best product wins :)

[erin-allison]

You can find a sample docker-compose YAML and necessary environment variables in their own repo: https://github.com/triggerdotdev/docker

Furthermore, all documentation is for v2 right now; v3 isn't even in preview yet.

[deadcoder0904]

@erin-allison I already saw that but confused what are the required environment variables?

Kubernetes guide says 5 but there is RUNTIME_PLATFORM mentioned in docker-compose.yml of the linked repo. And many other variables are also present.

[erin-allison]

The Kubernetes document does say "at a bare minimum" for those 5. For the rest, they mostly speak for themselves:

---

LOGIN_ORIGIN
APP_ORIGIN

_ORIGIN or _URL environment variables are generally used for generating callback/link URLs (i.e. for OAuth configuration or login emails)

---

PORT
REMIX_APP_PORT

Names say it all - they'll default if unspecified

---

POSTGRES_USER
POSTGRES_PASSWORD
POSTGRES_DB
DATABASE_HOST

All used to compose DATABASE_URL (and subsequently, DIRECT_URL)

---

AUTH_GITHUB_CLIENT_ID
AUTH_GITHUB_CLIENT_SECRET
FROM_EMAIL
REPLY_TO_EMAIL
RESEND_API_KEY

Described in the file - if unspecified, the relevant functions won't operate

---

NODE_ENV

Yes

---

RUNTIME_PLATFORM

Determines which platform-specific logic to use (namely rewriting localhost for docker deployments)

[erin-allison]

tl;dr: The 5 listed are the "required" variables, though the .env.example file lists additional options which are likely to be things that are more commonly customized.

There are a good number of extra environment variables that could be specified (most of which are listed here), but the docker repo does provide sane defaults and if you clone it and follow the couple extra steps of directions, it will just work.

[deadcoder0904]

alright, thanks. got it. i think this is what should be provided in docs.

further improvements would be to make .env.example as minimum as possible, i.e, using DATABASE_URL instead of the whole POSTGRES_HOST, POSTGRES_USERNAME, etc... which i think everyone knows who uses databases knows how to concatenate that string.

and providing which are required & optional in comments like:

# all these environment variables are required
LOGIN_ORIGIN=xxxx
APP_ORIGIN=xxxx

# these environment variables are optional
AUTH_GITHUB_CLIENT_ID=xxx

i guess i'll pin trigger to v2 in docker-compose.yml & test it out. thanks for the help 👍

[erin-allison]

My final 2 cents:

further improvements would be to make .env.example as minimum as possible, i.e, using DATABASE_URL instead of the whole POSTGRES_HOST, POSTGRES_USERNAME, etc... which i think everyone knows who uses databases knows how to concatenate that string.

I'm iffy on this one; the separation is a convenience thing that makes readability a bit nicer in an example. Otherwise, you end up with a chunk like postgresql://postgres:postgres@... that just makes my eyes bleed a bit.

and providing which are required & optional in comments like:

You and I and the Trigger.dev guys all agree there: those few are listed as optional already 😄

---

On another note, I think docs regarding v2 are probably frozen b/c v3 is right on the horizon and it will completely change the requirements for deployment.

[deadcoder0904]

I'm iffy on this one; the separation is a convenience thing that makes readability a bit nicer in an example. Otherwise, you end up with a chunk like postgresql://postgres:postgres@... that just makes my eyes bleed a bit.

Naah, I agree its great for readability but as an example, that takes too much space when it could be done in one line. Plus it has a repeated env variable.

Bdw, is v2 reliable enough? All I want to do is send emails after payment. Nothing more for now.

[erin-allison]

Naah, I agree its great for readability but as an example, that takes too much space when it could be done in one line.

I mean... its not like the few dozen bytes costs anything of note. I think the readability wins that trade-off in my books.

Plus it has a repeated env variable.

Which one? If you're referring to DATABASE_URL vs DIRECT_URL, there is a difference and in a production deployment, those are likely to not be equivalent (see the prisma docs for details)

Bdw, is v2 reliable enough? All I want to do is send emails after payment. Nothing more for now.

I don't have a local production deployment now, but from the dev work I've put into it, the platform is pretty solid.

[deadcoder0904]

what's the difference between DATABASE_URL & DIRECT_URL? i saw the prisma url but didn't get it.

plus not using prisma.

[nicktrn]

Setting DIRECT_URL to anything but DATABASE_URL is only required when DATABASE_URL points to a connection pooler such as PgBouncer. More details in this section on connection pooling.