trigger.dev

cit determinism, found breaking their work into small “steps” tricky, and they wanted to install any system packages they needed. Serverless timeouts made this even more painful. We also wanted to allow you to wait for things to happen: on external events, other tasks finishing, or just time passing. Those waits can take minutes, hours, or forever in the case of events, so you can’t just keep a server running. The solution was to build and operate our own serverless cloud infrastructure. The key breakthrough that enabled this was realizing we could snapshot the CPU and memory state. This allowed us to pause running code, store the snapshot, then restore it later on a different physical server. We currently use Checkpoint Restore In Userspace (CRIU) which Google has been using at scale inside Borg since 2018. Since then, our adoption has really taken off especially because of AI agents/workflows. This has opened up a ton of new use cases like compute-heavy tasks such as generating videos using AI (Icon.com), real-time computer use (Scrapybara), AI enrichment pipelines (Pallet, Centralize), and vibe coding tools (Hero UI, Magic Patterns, Capy.ai). You can get started with Trigger.dev cloud (https://cloud.trigger.dev), self-hosting (https://trigger.dev/docs/self-hosting/overview), or read the docs (https://trigger.dev/docs). Here’s a sneak peek at some upcoming changes: 1) warm starts for self-hosting 2) switching to MicroVMs for execution – this will be open source, self-hostable, and will include checkpoint/restoring. We’re excited to be sharing this with HN and are open to all feedback!

can run any length of task. You write the code like any other job in your codebase. Discussion here: https://github.com/triggerdotdev/trigger.dev/discussions/400 - Support for long-running servers (so you can use if you’re not deploying to serverless). Issue here: https://github.com/triggerdotdev/trigger.dev/issues/244

ady support. Either publicly (we appreciate PRs) or privately in your existing codebase. We’re open about what we’re building (https://trigger.dev/changelog) and what we’re planning on doing next (https://trigger.dev#roadmap) as we believe community feedback ensures that we’re solving real problems. So here’s where we’re at, and where we’re headed: [x] Easy self-hosting. [x] Serverless. Long-running Jobs on your serverless backend. [x] Integration kit. Build your own integrations, or use ours. [x] Bring-Your-Own-Auth. You can now authenticate integrations as your users. [x] Dashboard. View every Task in every Run. [x] Cloud service. No deployment required. [x] React hooks. Easily update your UI with Job progress. [x] React frameworks. Support for Next.js, Astro, Remix, Express. [ ] More frameworks. Support for SvelteKit, Nuxt.js, Fastify, Redwood. [ ] Background functions. Offload long or intense tasks to our infrastructure. [ ] Long-running servers. Use Trigger.dev from your long-running backend. [ ] Polling Triggers. Subscribe to changes without webhooks. [ ] And lots more… I’d love to hear your thoughts on background jobs. Have we missed anything off the list? What should we be building next? https://github.com/triggerdotdev/trigger.dev

igger workflows from webhooks, custom events or schedules (CRON) - Use API integrations with Slack, GitHub, Shopify and Resend. We’re adding more of these each week. - Add delays of up to 1 year. Workflows will resume where they left off, even if your server has gone down. - Support for Fetch and subscribing to generic webhooks. - Observe every workflow run in the app (great for debugging). - Open source MIT license so anyone can self-host the platform. We’re still early so would love your feedback and opinions. Feel free to try us out for free – and if you want a specific API integrated, just let us know. Main website: https://trigger.dev Github: https://github.com/triggerdotdev/trigger.dev