Unlike Trigger.dev Cloud, the self-hosted setup is optimized for single-tenant use, with code and
users you trust. It is not designed to run untrusted code or untrusted payloads.
What is in scope
A self-hosted deployment is a single trust domain: as above, it is built for code and users you trust. Role separation inside an organization is therefore not a security boundary there. Role-based access control comes from a plugin that is not part of the open-source distribution, and without it the permission layer falls back to a permissive ability for session users and personal access tokens. That is deliberate. Out of scope for self-hosted: a member of an organization performing a privileged action inside that same organization, such as renaming or deleting the organization or managing other members. Control who you invite, or use Cloud, if you need that separation. In scope from any deployment: reaching data or actions belonging to an organization the caller is not a member of, or bypassing authentication. Organization is a hard boundary on Trigger.dev Cloud, and Cloud runs this same code, so report these even though your own install is single-tenant. Tell us which deployment you tested against. The same report can be out of scope for self-hosting and in scope for Cloud. The security policy is canonical.Reporting a vulnerability
1
Choose a private channel
- GitHub (preferred): open a private report from the repository’s Security tab using “Report a vulnerability” (direct link).
- Email:
security@trigger.dev
2
Include the details
A description and impact, steps to reproduce (a proof of concept helps), affected versions/components, and any suggested fix.
3
We track it privately
Every report is tracked in a private GitHub Security Advisory. If you email us, we open the advisory on your behalf.
What to expect
We score issues with CVSS 3.1 and prioritise remediation by severity:
These are best-effort targets measured from when we validate and accept a report, not guarantees. We follow coordinated disclosure with a default 90-day window, and publish a GitHub Security Advisory (requesting a CVE where applicable) once a fix ships.