Introduction
Learn what Trigger.dev is, why you might pair it with Browserbase, and what you can build with this integration.
Overview
By the end of this guide, your Trigger.dev agent will automate a background job that processes data and sends notifications.
You’ll learn how to:
- Set up a Trigger.dev workflow to handle long-running tasks.
- Use Trigger.dev to schedule and monitor your background jobs.
Background jobs meet cloud browsers
Trigger.dev is an open-source background-jobs & AI infrastructure platform. It lets you write long-running workflows in plain async/await code without worrying about queues, cron schedulers, retries, or observability. Think BullMQ + Cron + Sentry + Kubernetes, but rolled into one developer-first package and available as a hosted SaaS or self-hosted.
Browserbase, on the other hand, gives you disposable, headless Chrome instances over WebSockets—perfect for scraping, screenshotting and PDF generation. When you combine the two you unlock server-side browser automation that never times out:
- Spin up an isolated browser in Browserbase
- Drive it with Puppeteer/Playwright from a Trigger task
- Stream logs & status back to your UI in real-time via Trigger Realtime
- Scale to thousands of concurrent browsers with zero infra work
Why use them together?
Challenge | How the integration helps |
---|---|
Functions on Vercel/Netlify time-out after 10–30 s | Trigger tasks have no timeouts, so long scrapes finish happily |
Queuing, retries, rate limits | Built-in retry , concurrency , and cron features |
Running Chrome on serverless | Browserbase hosts Chrome—no Lambda layers, no xvfb |
Observability | Every scrape is a run in Trigger with logs & replay |
What you can build
- PDF → PNG pipelines (MuPDF via
aptGet
extension) - High-volume scraping with rotating proxies
- Automated report generation (React-to-PDF, screenshots)
- AI agents that browse sites, summarise content and send email
Looking for a concrete example? Jump to the Quickstart or browse the code here: Repo