Re:Trigger.dev customer environment variables exposed
by cpursley on Monday November 02, 2026 @12:41AM
(#50333498)
The very fact that Nextjs vibe projects need an external (and paid!) background jobs / async service show how much of an anti pattern that this framework and similar are. Just use a sensible stack from day one that can handle concurrency out of the box like Elixir or something with established open source background jobs library. Then you can worry less about this kind of paid 3rd party nonsense. Ditto on auth. I just can't fathom outsourcing these types or core functionalities, the operational, security and cost risks make very little sense when there's libraries that do this out of the box.
[ Parent
| on HN ]
Re:Trigger.dev customer environment variables exposed
by multiplegeorges on Monday November 02, 2026 @12:49AM
(#50333527)
Yes, outsourcing these kinds of core functionality (your queue, your users table!) is insane to me.
Re:Trigger.dev customer environment variables exposed
by asdf88990 on Monday November 02, 2026 @05:34AM
(#50335121)
Auth0 and friends are useful for social logins but that should be about it, not replacing your user table wholesale like people do.
Re:Trigger.dev customer environment variables exposed
by cpursley on Monday November 02, 2026 @05:56AM
(#50335268)
There are open source libraries even for that sort of thing.
Re:Trigger.dev customer environment variables exposed
by dgellow on Monday November 02, 2026 @05:20AM
(#50335032)
You can run trigger in your own infra. That has very little to do with the libraries used for your web app
Re:Trigger.dev customer environment variables exposed
by cpursley on Monday November 02, 2026 @05:59AM
(#50335286)
Trigger and friends exist precisely because Node is not a serious backend runtime so you have to reach for bolt-ons for every little thing. No matter if trigger is open source or managed, it's an anti-pattern. Erlang/Elixir, C#, Go etc all handle this sort of async natively, literally out of the box. Mature frameworks like Rails, Django have pretty easy to use officially libraries as well. This has been a solved problem for literally decades.
Re:Trigger.dev customer environment variables exposed
by dgellow on Monday November 02, 2026 @07:32AM
(#50335976)
That has nothing to do with node. You have a lot of situations where a dedicated job queue makes sense
Re:Trigger.dev customer environment variables exposed
by cpursley on Monday November 02, 2026 @07:56AM
(#50336202)
The reason people are using these paid queue services is because Node sucks. Isn't it better to use an open source library or adult backend stack which solved this problem 30 years ago?
Re:Trigger.dev customer environment variables exposed
by dgellow on Monday November 02, 2026 @08:55AM
(#50336835)
Trigger is literally open source. That has nothing to do with how mature the node ecosystem is. If you want in-process queue systems you have a lots of other mature options. Trigger is a dedicated queue system, it runs in its own process and can be used from any language through its API. You seem to talk confidently about a topic I don’t think you understand.
Go has lots of mature in-process queue systems, yet River exists, because in lots of situation it makes perfect sense to have your job queue in its own process
Re:Trigger.dev customer environment variables exposed
by cpursley on Monday November 02, 2026 @10:52AM
(#50338539)
Yeah, I understand this topic really well, actually: https://github.com/agoodway/pgflow
Re:Trigger.dev customer environment variables exposed
by ishandotpage on Monday November 02, 2026 @01:01PM
(#50340843)
Have you actually tried using the open-source self hostable version of trigger? It seems to only exist in order to check a "we're open source yay" box.
It's missing lots of features like sleeping on waits, warm starts etc.