? Curious Hacker Newsfront | about | view on HN unofficial mirror
Trigger.dev customer environment variables exposed (trigger.dev)
156 points by anurag 2026-11-02 | 80 comments | side by side | 22 rewritten | show 5 removed | updated 18:20 UTC
 help


liorgrossman 2026-11-02 18:19 | removed0/10low_effortcurmudgeonly | next [–]

Another day, another infra provider hacked.

Another day, another infra provider hacked.

A one-line weary remark that adds nothing about the incident.

reply


As I mentioned in the Northflank breach post:

Unfortunately for infra startups, I think we're going to see a convergence back to hyperscalers as a result of incidents like this and railway.

There's no amount of "nicer to use" that can replace security, at least certainly when selling to enterprises

Also, a trick i've started doing is encrypting my env vars, then hard-code the decryption key in the code

As I mentioned in the Northflank breach post:

Unfortunately for infra startups, I think we're going to see a convergence back to hyperscalers as a result of incidents like this and railway.

There's no amount of "nicer to use" that can replace security, at least certainly when selling to enterprises

Also, a trick i've started doing is encrypting my env vars, then hard-code the decryption key in the code

Predicts a shift back to hyperscalers and offers a mitigation others can debate.

reply


Is your implication that hyperscalers (big companies) will always do better at this than smaller companies?

Just becuase a company has more money doesn’t mean they direct that money well, and even money directed well at the wrong people will result in failures.

Is your implication that hyperscalers (big companies) will always do better at this than smaller companies?

Just becuase a company has more money doesn’t mean they direct that money well, and even money directed well at the wrong people will result in failures.

A fair challenge to the claim that hyperscalers are safer.

reply


No one ever got fired for putting creds in AWS Secrets Manager. I'd take the hyperscaler every time because even if something happens, it is a very defensible decision.

No one ever got fired for putting creds in AWS Secrets Manager. I'd take the hyperscaler every time because even if something happens, it is a very defensible decision.

Makes a real point that choosing a hyperscaler is easy to defend organizationally.

reply


It is probably safer if you enable HSM.

It is probably safer if you enable HSM.

A brief but relevant suggestion to use an HSM for stored credentials.

reply


Sometimes compliance do help improve security. Hyperscalers have resources for that. They have resources and they do security well. Hyperscalers are treated as critical infrastructure.

One person's machine being compromised does not bring the whole org down.

Sometimes compliance do help improve security. Hyperscalers have resources for that. They have resources and they do security well. Hyperscalers are treated as critical infrastructure.

One person's machine being compromised does not bring the whole org down.

A substantive argument about compliance resources and how hyperscalers limit the damage from a single breach.

reply

kind_lynx41 2026-11-02 16:45 | rewritten3/10snarklow_effort | original | root | parent | prev [–]

Not necessarily always (Azure seems like an exception to me), but for the other hyperscalers, I think absolutely yes.

original comment by jen20

Not necessarily _always_ (Azure anyone?) but for the others - absolutely.

Replaced the snarky 'Azure anyone?' jab with a plain statement of the same position, which is a real but unsupported claim.

reply


[deleted]

Yes, I’d say any infra provider that can't afford to have their own hardware security module should probably not be storing sensitive customer data.

Yes, I’d say any infra provider that can't afford to have their own hardware security module should probably not be storing sensitive customer data.

A concrete security bar for infra providers.

reply

viraptor 2026-11-02 14:437/10informativeinsightful | root | parent [–]

Unfortunately the cost of HSM is the cost of two of them, overprovisioned for your projected needs over years, and staff who know how to use them safely both in terms of security design and not losing access to everything in case of an issue.

Unfortunately the cost of HSM is the cost of two of them, overprovisioned for your projected needs over years, and staff who know how to use them safely both in terms of security design and not losing access to everything in case of an issue.

Explains the hidden real-world costs of running HSMs.

reply


Just having HSM is not good enough. You also need a process around it to keep it secure. you can also use Cloud HSM solutions.

Just having HSM is not good enough. You also need a process around it to keep it secure. you can also use Cloud HSM solutions.

Adds that HSMs need operational process around them and mentions cloud HSM as an option.

reply


I don't see how this can be marked "Resolved." Our env vars were exposed, the notice was an email, and they don't yet know how it happened or how far it reached.

original comment by corvad

I am sorry, this is "Resolved"? How can they even consider marking this resolved in any situation. Yeah we exposed your env vars but we told you about it over email so it's all good... We dont know how or to what extend though.

Removed the mocking paraphrase and kept the specific reasons the 'resolved' label seems wrong.

reply


What would you consider appropriate action for their incident team to be able to mark the incident on their status page as resolved?

What would you consider appropriate action for their incident team to be able to mark the incident on their status page as resolved?

A genuine question about the criteria for calling it resolved.

reply

azure_quail57 2026-11-02 09:35 | rewritten2/10low_effortsnarkkept_for_replies | original | root | parent [–]

I don't think it should ever be marked as resolved.

original comment by ygouzerh

Never put it resolved

The replies discuss what status pages are for and whether incidents should stay open, so the parent is reduced to its basic position to keep that context.

reply


Why? What purpose would having an eternally open incident serve?

Why? What purpose would having an eternally open incident serve?

A real question asking what the parent's suggestion is meant to achieve.

reply

sandy_beaver18 2026-11-02 11:44 | rewritten2/10low_effort | original | root | parent [–]

I'd keep it open as a lasting reminder of the need to do better, so the lesson from this incident isn't forgotten.

original comment by phs318u

As an eternal reminder of the need to do better? Those who fail to learn from history are doomed to repeat it?

Turned rhetorical questions into a plain statement of the commenter's answer.

reply


> As an eternal reminder of the need to do better?

Eternity is a very long time, longer even than the roughly 80 years the whole programmable computing and data storage industry has existed.

I don't think keeping an issue open in a bug tracker forever is even practical, and I doubt it would work as a reminder anyway. In my experience most long-running firms have an "ignore open issues older than X years" filter on by default in Jira or whatever they use, and those old issues only get looked at about once a year by upper management when they're out of ideas.

original comment by Joker_vD

> As an eternal reminder of the need to do better?

Eternity is a very, very long time. Longer even than 80 years (arguably the total age of the whole "programmable electronic computing and data storage machines" industry), you know?

So I don't think that having an open issue in a bug tracker forever is even possible; not that it would even serve as a remainder — I assure you, most long-existing firms have "ignore open issues older than X years" filter enabled by default in their Jiras or whatever people use nowadays, those are only ever looked at once year by the upper management when they're out of ideas.

Removed the condescending framing and kept the point about how old open issues are handled in practice.

reply


A status page is not a historical log.

A status page is not a historical log.

Short, but makes a real point about what status pages are for.

reply


At least a postmortem or what went wrong would be a start

At least a postmortem or what went wrong would be a start

A reasonable suggestion about what a resolution should include.

reply

humble_robin67 2026-11-02 16:08 | rewritten3/10snarklow_effort | original | parent | prev [–]

To me, "resolved" here seems to mean the vendor's part is done and the rest, like rotating the exposed secrets, is now the customers' problem.

original comment by htrp

Resolved = it's your problem now?

Sarcastic one-liner with a real point: the label shifts cleanup onto customers. Rewritten to state it plainly.

reply


The biggest case for building bespoke software is that you drop your attack surface area and it’s not as lucrative to hack one person. Don’t even expose it to the internet if you don’t need to and just run Tailscale.

The biggest case for building bespoke software is that you drop your attack surface area and it’s not as lucrative to hack one person. Don’t even expose it to the internet if you don’t need to and just run Tailscale.

A clear argument that bespoke, non-public software has a smaller attack surface.

reply


I don't see bespoke software as a viable alternative because probing for vulnerabilities is both getting cheaper by the day, and also massively parallelizable.

Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.

Not to mention your bespoke tool is likely way less hardened than the existing player in the space.

I don't see bespoke software as a viable alternative because probing for vulnerabilities is both getting cheaper by the day, and also massively parallelizable.

Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.

Not to mention your bespoke tool is likely way less hardened than the existing player in the space.

A reasoned counterargument against relying on bespoke software for security.

reply


Agree in don't ever expose if not needed.

And keep private and public personal hosted services in different contexts.

Agree in don't ever expose if not needed.

And keep private and public personal hosted services in different contexts.

A short, good-faith reply that agrees with the parent and adds a small practical tip about keeping private and public services separate.

reply


I think this argument actually cuts the other way: the effort of keeping your own bespoke system secure is exactly why people rent infrastructure.

original comment by cbluth

I think you've just explained why people rent infrastructure.

A quip with a real counterpoint, now made explicit without inventing anything.

reply


Or do onprem or selfhosted. Surface area reduces drastically.

Or do onprem or selfhosted. Surface area reduces drastically.

A brief but real suggestion.

reply


The tradeoff is that you become your own ops team and need to monitor and respond to cves in real time.

The tradeoff is that you become your own ops team and need to monitor and respond to cves in real time.

Names the operational tradeoff of self-hosting.

reply


[deleted]

I was also referencing that using commercial software usually brings features you probably don’t use. Those features probably require new NPM packages so by building a bespoke software, you only build features you need.

I was also referencing that using commercial software usually brings features you probably don’t use. Those features probably require new NPM packages so by building a bespoke software, you only build features you need.

Clarifies the argument for bespoke software.

reply


this is often a worse time-to-patch

this is often a worse time-to-patch

A short but valid counterpoint.

reply


Tailscale got hacked recently as well, didnt they (?). I think they did, the whole system is poisoned, because I believe one of the vectors had to do with eMudhra certs, which again, is not an issue specific to them, or something they had any say on it... there is literally no escape these days it would seem.

Tailscale got hacked recently as well, didnt they (?). I think they did, the whole system is poisoned, because I believe one of the vectors had to do with eMudhra certs, which again, is not an issue specific to them, or something they had any say on it... there is literally no escape these days it would seem.

Points to a possible shared cause (the certs), with the uncertainty stated.

reply


tailscale got hacked recently? sources?

they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.

> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]

eMudhra/TLS certificates have nothing to do with this (?).

[1] https://news.ycombinator.com/item?id=50266179

tailscale got hacked recently? sources?

they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.

> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]

eMudhra/TLS certificates have nothing to do with this (?).

[1] https://news.ycombinator.com/item?id=50266179

Corrects a vague claim about Tailscale with specifics and a source.

reply


That was Tailscale SSH and it’s not on by default

That was Tailscale SSH and it’s not on by default

A brief, useful clarification.

reply


It also was not related to the mentioned CA, and was not "hacked".

It also was not related to the mentioned CA, and was not "hacked".

A short factual correction that adds to the parent's clarification about the Tailscale incident.

reply


This is probably correct if you aren’t a target at all, e.g. you aren’t running a business

This is probably correct if you aren’t a target at all, e.g. you aren’t running a business

A reasonable caveat about threat models.

reply


As far as my personal life is concerned, I honestly don't think I'm going to 'build and deploy' anything to any SaaS that isn't directly in my control for a while.

As far as my personal life is concerned, I honestly don't think I'm going to 'build and deploy' anything to any SaaS that isn't directly in my control for a while.

A personal reaction about trusting SaaS platforms, minor but sincere.

reply


Yep, that triggered in my mind to move the last public service (not critical) I was hosting inside a third party saas because of little conveniences.

Yep, that triggered in my mind to move the last public service (not critical) I was hosting inside a third party saas because of little conveniences.

A short but sincere personal reaction that agrees with the parent, with no snark.

reply


damn, i've been thinking about the same recently. saas is dead, at least developer oriented saas for sure. the only things i rely on are my own self hosted git (not public to the web), and that's it. all other "developer oriented saas" has been replaced with a home made version with claude. probably not safe from hacking, but id rather take the risk of someone targeting ME specifically, than let all the "saas platforms" store all my data and get hacked every monday and friday

damn, i've been thinking about the same recently. saas is dead, at least developer oriented saas for sure. the only things i rely on are my own self hosted git (not public to the web), and that's it. all other "developer oriented saas" has been replaced with a home made version with claude. probably not safe from hacking, but id rather take the risk of someone targeting ME specifically, than let all the "saas platforms" store all my data and get hacked every monday and friday

A personal approach and how they weigh the risk.

reply


Setting the status page incident to resolved seems premature to me.

original comment by iampims

It’s bold to set status page incident to resolved.

Removed the sarcastic 'bold' and kept the objection to calling the incident resolved.

reply

serene_shrike92 2026-11-02 04:35 | rewritten4/10cross_examination | original | parent | next [–]

If they've fixed the exploit, I think marking it resolved is reasonable. I don't see why they'd need to wait an arbitrary amount of time first.

original comment by weird-eye-issue

If they fixed the exploit then what do you want them to do? Do they need to wait an arbitrary amount of time before setting it to resolved?

Real counterpoint, but the rhetorical questions are rewritten as a plain statement.

reply

eddythompson80 2026-11-02 04:487/10first_handinformative | root | parent | next [–]

I don't disagree with you, but I think generally when the mistake involves compromised user data, the answer is a bit more emotionally driven. People get rightfully mad when things like that happens, and services usually keep the incident in a "Mitigated" status while they "work with their customers to ensure blah blah blah" or whatever. Everywhere I've personally worked the Mitigated->Resolved involves publishing a postmortem, repair items, and general assurances or safe guards based on learnings from the incident that the issue won't happen again. However, the industry as a whole doesn't have a standard for what the line between Mitigation and Resolution is.

I don't disagree with you, but I think generally when the mistake involves compromised user data, the answer is a bit more emotionally driven. People get rightfully mad when things like that happens, and services usually keep the incident in a "Mitigated" status while they "work with their customers to ensure blah blah blah" or whatever. Everywhere I've personally worked the Mitigated->Resolved involves publishing a postmortem, repair items, and general assurances or safe guards based on learnings from the incident that the issue won't happen again. However, the industry as a whole doesn't have a standard for what the line between Mitigation and Resolution is.

Draws on first-hand practice to explain how Mitigated and Resolved statuses differ.

reply


So the active incident is fixed and they've already contacted impacted customers. It seems odd to me that it can't be marked resolved just because a more detailed blog post hasn't been published yet.

original comment by weird-eye-issue

So the active incident is now fixed and they've already reached out to impacted customers but they can't mark it as resolved yet because they are still yet to publish a more detailed blog post?

Rewrote the incredulous rhetorical question as a plain statement of the author's doubt.

reply


It's not that they can't mark it as resolved. It's just that it is bad business to do so.

How they handle the communication on the incident is crucially as important as remediating the original cause.

Just the fact that they are doing this means I will probably never use this service or recommend this service to anyone else.

It's not that they can't mark it as resolved. It's just that it is bad business to do so.

How they handle the communication on the incident is crucially as important as remediating the original cause.

Just the fact that they are doing this means I will probably never use this service or recommend this service to anyone else.

Blunt, but it makes a real point that how an incident is communicated matters as much as fixing it.

reply


Okay so let's just say you are one of those affected users

The founder of the company has already emailed you with details and their support team is around for you to ask any follow-up questions. Also the bug/exploit has been fully fixed

At this point are you saying you would actually be upset and leave because the incident on their status page has been marked as resolved?

Okay so let's just say you are one of those affected users

The founder of the company has already emailed you with details and their support team is around for you to ask any follow-up questions. Also the bug/exploit has been fully fixed

At this point are you saying you would actually be upset and leave because the incident on their status page has been marked as resolved?

A fair hypothetical that pushes back on the parent's position.

reply


Yes.

Yes.

A short but sincere answer to the direct question it replies to, so it stays as written.

reply

weird-eye-issue 2026-11-02 06:09 | removed0/10personal_attacksnarklow_effort | root | parent [–]

Drama queens

Drama queens

A one-line insult with no point behind it.

reply

sebastialonso 2026-11-02 15:32 | removed0/10personal_attackmetasnark | root | parent [–]

> Ask questions > When showed different opinion, complains like a bitch

HN is very cesspool-ly indeed

> Ask questions > When showed different opinion, complains like a bitch

HN is very cesspool-ly indeed

An insult plus a meta complaint about HN, with nothing about the incident.

reply


What makes you think it's fixed? They just state that they "blocked the exploit", and that could mean anything:

- did they just take the affected API offline?

- or did they just disable the account of the attacker?

- or is the exploit actually being fixed?

Environment variables are sensible data, and marking a security incident as resolved with that little detail is quite a take. Even changelog entries for harmless bug fixes are more detailed.

What makes you think it's fixed? They just state that they "blocked the exploit", and that could mean anything:

- did they just take the affected API offline?

- or did they just disable the account of the attacker?

- or is the exploit actually being fixed?

Environment variables are sensible data, and marking a security incident as resolved with that little detail is quite a take. Even changelog entries for harmless bug fixes are more detailed.

Points out, with concrete examples, that 'blocked the exploit' is ambiguous and doesn't mean the problem is fixed.

reply


I assume it's fixed based on it being marked resolved and from what was communicated. Yeah I agree it's a major issue but if it's fixed what they have done so far seems totally fine

I assume it's fixed based on it being marked resolved and from what was communicated. Yeah I agree it's a major issue but if it's fixed what they have done so far seems totally fine

Explains plainly why the commenter considers the response adequate.

reply


To use a fearful, apt analogy: resolving the operational issue isn't just plugging the hole in the dam, its also fixing the damage by pumping the water out and then addressing the damages.

To use a fearful, apt analogy: resolving the operational issue isn't just plugging the hole in the dam, its also fixing the damage by pumping the water out and then addressing the damages.

A useful analogy for what counts as resolved.

reply


In your analogy they can't pump the water out. Now it's up to their users to rotate their keys. How do you expect them to do that sort of thing on behalf of their users?

In your analogy they can't pump the water out. Now it's up to their users to rotate their keys. How do you expect them to do that sort of thing on behalf of their users?

Engages with the analogy and points out that key rotation falls to users.

reply


Depends on the TOS, but, blocking service until confirmed or decommed would get the trick done.

Depends on the TOS, but, blocking service until confirmed or decommed would get the trick done.

A short but concrete suggestion: suspend service until keys are confirmed rotated.

reply


I don't think blocking service works here. People use environment variables to store things like API keys for third-party services, and rotating or decommissioning those has to happen on the customer's side across every provider, so it can't be done instantly.

original comment by weird-eye-issue

That doesn't even make sense. People use environment variables to store things like API keys for third-party services. How do you expect them to magically rotate or decommission those keys?

Removed the dismissive phrasing and kept the practical objection about rotating third-party keys.

reply


Trigger.dev wouldn't rotate customer BYOK. What I was saying is they disable customer use of their service until rotation occurs or is confirmed by the customer.

Trigger.dev wouldn't rotate customer BYOK. What I was saying is they disable customer use of their service until rotation occurs or is confirmed by the customer.

Clears up a misreading and proposes a concrete fix: block service use until the customer confirms keys are rotated.

reply


they could have explained a bit better with proper postmortem and steps taken to improve, before marking it as resolved

they could have explained a bit better with proper postmortem and steps taken to improve, before marking it as resolved

A constructive criticism of how the incident was handled.

reply


They are no longer exposing anything, so they no longer have an incident.

Their customers now have an incident that will be resolved once their secrets are rotated. Maybe they also need to do previous intrusion forensics… In any case, not triggers problem anymore.

They are no longer exposing anything, so they no longer have an incident.

Their customers now have an incident that will be resolved once their secrets are rotated. Maybe they also need to do previous intrusion forensics… In any case, not triggers problem anymore.

Separates the vendor's incident from the customers' remaining work.

reply

cheeze 2026-11-02 04:37 | removed0/10snarklow_effort | parent | prev [–]

I like the fancy gradient INCIDENT REPORT image as well. At least it looks fancy and AI-ey

I like the fancy gradient INCIDENT REPORT image as well. At least it looks fancy and AI-ey

A sarcastic jab at the image with no substance.

reply

BADCAFE 2026-11-02 06:586/10first_handinformative | prev | next [–]

This also happened to a trigger.dev competitor a few months ago, inngest.

I was able to patch before it was exploited but that definitely made me question the service.

This also happened to a trigger.dev competitor a few months ago, inngest.

I was able to patch before it was exploited but that definitely made me question the service.

First-hand account of a similar incident at a competitor (Inngest).

reply


Have any of these companies disclosed the actual vulnerabilities used to gain access to their systems?

Have any of these companies disclosed the actual vulnerabilities used to gain access to their systems?

A real question about whether the vulnerabilities used in these incidents have been disclosed.

reply


Northflank mentioned they patched CVE-2026-98432. This appears to be similar, though not confirmed by trigger.dev yet

Northflank mentioned they patched CVE-2026-98432. This appears to be similar, though not confirmed by trigger.dev yet

Gives a specific CVE and a related disclosure.

reply


No. Which may mean they don't know.

No. Which may mean they don't know.

A short but real answer with a plausible inference.

reply


the recent CVE making any non-patched TCP exposed linux server RCE-root-able seems like a good stretch to me.

But could also be any of the recent supply chain attacks hitting a dev too i guess

the recent CVE making any non-patched TCP exposed linux server RCE-root-able seems like a good stretch to me.

But could also be any of the recent supply chain attacks hitting a dev too i guess

Offers some plausible attack vectors as guesses.

reply


[deleted]
eager_ferret42 2026-11-02 05:07 | rewritten2/10question | original | prev | next [–]

With incidents like this happening more often, do customers care whether SaaS vendors use AI in development? I wonder if vendors will start hiding that they use it.

original comment by asdfsa32

So at this rate, how long before people start hiding use of AI in development of in their SaaS and services? or people really don't care, do they?

Turned an unsupported jab into the open question underneath it.

reply

maple_bison65 2026-11-02 08:47 | rewritten3/10ideological | original | parent [–]

In my view, hand-written code is full of dirty hacks and exploitable bugs that LLMs can find easily, so I'd be wary of software that isn't using frontier models to audit and fix it.

original comment by Kiro

Hand-made code is riddled with dirty hacks and exploits that LLMs have no problem finding. I would not trust any software that is not using frontier models to fix the messy human code.

A sweeping assertion reframed as the author's view.

reply


I don't think frontier models reliably produce good architecture or secure code. Using AI to find bugs in existing software is a very different skill, with different outcomes, from using AI to write bug-free software. Most of the high-profile examples are AI driven by people who would have solved the same problem anyway, just more slowly by going through the code. AI is only as good as its operator.

original comment by asdfsa32

Oh that is right, the frontier models yield amazing architecture and secure code in the form of aislop.

There is a difference between using AI to find bugs in written software than using AI to write bug free software, completely different set of skills and outcomes. Most of the high profile stuff you see is AI being driven by people who would have solved the same problem just in slower time going through the code. AI is as good as the operator.

Kept the find-versus-write distinction and dropped the sarcastic opener.

reply


This should not be marked as "resolved". "Mitigated" until some percentage of customers ack the email notification at least (track clicks, get teams on Zoom call, etc.).

This should not be marked as "resolved". "Mitigated" until some percentage of customers ack the email notification at least (track clicks, get teams on Zoom call, etc.).

Gives a concrete alternative: call it 'Mitigated' until customers confirm they got the notice.

reply


Given the recent Claude Code remote access tool, it would be wise to not install any new software, or use any package manager for a few weeks as they could have already been silently backdoored during the aftermath of that incident.

Given the recent Claude Code remote access tool, it would be wise to not install any new software, or use any package manager for a few weeks as they could have already been silently backdoored during the aftermath of that incident.

Concrete if cautious advice that links this to a recent supply-chain concern.

reply


*VS Code extension for Claude Code

*VS Code extension for Claude Code

A useful factual correction.

reply

eddythompson80 2026-11-02 17:43 | removed0/10jokelow_effort | root | parent [–]

*VS Code extension for Claude Code for Cursor VS Code Fork

*VS Code extension for Claude Code for Cursor VS Code Fork

A joke correction that piles on qualifiers and adds nothing of substance.

reply


I was paranoid enough to just remove all my Chrome/VSCode etc extensions.

Im now thinking about just running tart VM's on my mac to do my regular stuff from.

I was paranoid enough to just remove all my Chrome/VSCode etc extensions.

Im now thinking about just running tart VM's on my mac to do my regular stuff from.

First-hand mitigation steps and a concrete idea.

reply

sergsoares 2026-11-02 16:555/10first_handinformative | root | parent [–]

I really ditched now VScode/Cursor after the extension vulnerability (beside I never used that, only the Claude code CLI).

Despite no using full VM's I using Orbstack Isolated machines to some level of restrictions https://docs.orbstack.dev/machines/isolated for coding.

I really ditched now VScode/Cursor after the extension vulnerability (beside I never used that, only the Claude code CLI).

Despite no using full VM's I using Orbstack Isolated machines to some level of restrictions https://docs.orbstack.dev/machines/isolated for coding.

A first-hand account of a practical isolation setup, with a useful link to OrbStack's isolated machines.

reply

plucky_viper17 2026-11-02 05:41 | rewritten6/10ideological | original | prev | next [–]

To me, the fact that Next.js projects need an external, paid background-jobs service shows a weakness in that kind of framework. A stack that handles concurrency out of the box, like Elixir, or one with an established open-source background-jobs library, avoids depending on a third party for this. The same goes for auth. I don't see why you'd outsource core functionality like this when libraries already do it, given the operational, security and cost risks.

original comment by cpursley

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.

Removed 'vibe projects' and 'nonsense' and kept the architectural argument and alternatives.

reply


Yes, outsourcing these kinds of core functionality (your queue, your users table!) is insane to me.

Yes, outsourcing these kinds of core functionality (your queue, your users table!) is insane to me.

Brief agreement that states a clear position.

reply


Auth0 and friends are useful for social logins but that should be about it, not replacing your user table wholesale like people do.

Auth0 and friends are useful for social logins but that should be about it, not replacing your user table wholesale like people do.

A short but real opinion on how far to rely on outsourced auth.

reply


There are open source libraries even for that sort of thing.

There are open source libraries even for that sort of thing.

Brief, but it makes a real point that self-hosted alternatives exist.

reply


You can run trigger in your own infra. That has very little to do with the libraries used for your web app

You can run trigger in your own infra. That has very little to do with the libraries used for your web app

Corrects the parent: Trigger can be self-hosted.

reply

plucky_viper17 2026-11-02 10:59 | rewritten5/10ideological | original | root | parent [–]

In my view Trigger and similar tools exist largely because Node lacks built-in primitives for background and async jobs, so you end up reaching for add-ons. Whether Trigger is open source or managed, I see that as an anti-pattern. Erlang/Elixir, C# and Go handle this kind of async work natively, and mature frameworks like Rails and Django have easy official libraries for it. It has been a solved problem for decades.

original comment by cpursley

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.

Kept the runtime comparison and toned down the sweeping dismissal of Node.

reply


That has nothing to do with node. You have a lot of situations where a dedicated job queue makes sense

That has nothing to do with node. You have a lot of situations where a dedicated job queue makes sense

Blunt but legitimate disagreement with the parent's claim about Node.

reply

plucky_viper17 2026-11-02 12:56 | rewritten3/10ideologicalsnark | original | root | parent [–]

My view is that people use these paid queue services because Node's ecosystem doesn't handle this well. Wouldn't it be better to use an open source library, or a more mature backend stack that solved this problem decades ago?

original comment by cpursley

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?

Removed 'Node sucks' and the 'adult stack' jab but kept the argument for open source or established job queues.

reply

gilded_pika50 2026-11-02 13:55 | rewritten6/10personal_attackinformative | original | root | parent [–]

Trigger is open source, and this has nothing to do with how mature the Node ecosystem is. If you want an in-process queue there are plenty of mature options. Trigger is a dedicated queue system: it runs in its own process and can be used from any language through its API.

Go has lots of mature in-process queue systems, yet River exists, because in many situations it makes sense to run your job queue in its own process.

original comment by dgellow

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

Removed the personal dig and kept the correction about Trigger's design and the River example.

reply

civic_vole95 2026-11-02 18:01 | rewritten5/10cross_examinationsnark | original | root | parent | next [–]

In my experience the open-source self-hostable version of Trigger feels like it exists mainly to check the "open source" box. It's missing lots of features, like sleeping on waits and warm starts.

original comment by ishandotpage

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.

I kept the specific point about missing self-hosted features and dropped the challenging "have you actually tried" framing.

reply

plucky_viper17 2026-11-02 15:52 | rewritten3/10snarklow_effort | original | root | parent | prev [–]

For context, I've worked on this problem directly. Here's my project: https://github.com/agoodway/pgflow

original comment by cpursley

Yeah, I understand this topic really well, actually: https://github.com/agoodway/pgflow

The defensive comeback is reframed as a plain pointer to the author's relevant project, and the link is kept.

reply


[deleted]

[flagged]

[flagged]

[flagged]
gilded_robin35 2026-11-02 04:50 | rewritten2/10curmudgeonlylow_effortkept_for_replies | original | prev [–]

Is security just not a priority anymore? It surprises me that this is considered acceptable, especially given how often incidents like this seem to be happening lately.

original comment by fathermarz

Holy smokes, is security just not a priority at all anymore? Like in what world do we live in, that this is acceptable. And at the volume this has been happening, bad guys are having a FIELD DAY.

I rewrote this into a plain question about how security is prioritized, because the replies under it, including _pdp_'s first-hand account of small teams, need a parent that makes sense.

reply

_pdp_ 2026-11-02 12:077/10first_handinsightful | parent | next [–]

In my experience, small teams put security off because someone on the dev team has some security experience, or thinks they do. But it is never the priority, there is always something more urgent to ship, and nobody has real skin in the game because it is not their job. Then shit happens. They rush to hire a security team, and that team spends the next few years fighting the culture.

In my experience, small teams put security off because someone on the dev team has some security experience, or thinks they do. But it is never the priority, there is always something more urgent to ship, and nobody has real skin in the game because it is not their job. Then shit happens. They rush to hire a security team, and that team spends the next few years fighting the culture.

Experience-based explanation of the organizational dynamics.

reply


It makes sense, I have a skewed perspective because I have only been in security software.

Thanks for that anecdote

It makes sense, I have a skewed perspective because I have only been in security software.

Thanks for that anecdote

A sincere acknowledgment with a small first-hand note, though it adds little new.

reply

amber_newt82 2026-11-02 05:18 | rewritten2/10low_effort | original | parent | prev | next [–]

I don't think security was ever really a priority to begin with.

original comment by OccamsMirror

What makes you think security was ever a priority?

Rhetorical jab turned into the view underneath it.

reply


Security has never been a priority in the software world

Security has never been a priority in the software world

A brief but sincere opinion.

reply


I think maybe my lens is slightly skewed because I have only worked in security software? This is shocking to me.

I think maybe my lens is slightly skewed because I have only worked in security software? This is shocking to me.

Short, sincere reaction from someone who has worked only in security software; it adds a little perspective.

reply




About | This page on Hacker News | HN Guidelines | Data: HN API

Curious Hacker News is an unofficial, experimental mirror and is not affiliated with, endorsed by, or operated by Hacker News or Y Combinator. Original comments are by their authors on news.ycombinator.com; rewritten text is AI-generated and was not written by the commenter.