At a glance
- ~10% to 0%
- Screenshot failure rate
- ~500,000
- Screenshots rendered per month
- 2-3 lines
- Of code to migrate
- 30-40
- End-to-end tests run in parallel on CI
- 1 month+
- Of in-house build avoided
Overview
Dune is the industry standard for onchain data, providing structured, institutional-grade blockchain datasets across stablecoins, tokens, lending, trading, payments, and more. Trusted by 1,000+ industry leaders, including Visa, WisdomTree, S&P, UBS, and Bloomberg.
It uses Browserless on two fronts: rendering the preview images and chart visualizations its users see and share, and running its engineering team's end-to-end tests on CI. The screenshot pipeline came first, replacing self-managed browser infrastructure where roughly one in ten requests failed, and bringing that to zero. Once it proved itself, the same platform became the team's testing workhorse too.
The challenge
When an airdrop hits, traffic to Dune is not predictable. Thousands of people rush in at once to check whether their wallet qualifies, each one running queries, loading dashboards, and generating screenshots. Scheduled screenshots add their own spikes, sometimes all firing at midnight together.
Screenshots are not a background job at Dune. Every public dashboard and query needs an OG-tag preview image, and users rely on clean screenshots of their charts, including for private queries. So when the rendering pipeline buckled under traffic, customers noticed.
The early version ran client-side and didn't scale. The team moved to a self-managed setup of a few browser instances, but different queries demanded wildly different resources, and the spikes kept breaking it. Around 10% of requests were failing or retrying. There was a fallback that pushed failed renders back to the client to try again, but the underlying problem stayed.
Fixing it meant living inside hard browser-scaling questions: scale by traffic or by CPU, how many tabs per browser, one browser per request or many. Few engineers had that context, so every fix surfaced a new failure. It became a rabbit hole, quarter after quarter, until the team decided to stop patching and pick a real solution.
It's not the core business of Dune to be running browser automation. We're a data provider. Browserless let us focus on that instead of pouring engineering hours into fixing the browser setup.
Why Browserless
Most vendors Dune looked at assumed a simple flow: hand over a URL, get back a screenshot. That doesn't work for private queries. To keep user data private, Dune injects the data and rendering scripts straight into the browser rather than passing secrets to a third party, so it needed somewhere it could run its own code.
Browserless allowed exactly that. And the switch cost almost nothing in engineering time: two or three lines to point at the Browserless WebSocket URL. Norbert had already run into Browserless during earlier experiments, so it was a known quantity when the team went looking for a way out.
Porting to Browserless was two or three lines, where we just set up the WebSocket URL. The setup was so easy, we didn't hit any roadblocks.
How it works: two paths
Dune connects to Browserless over a Puppeteer WebSocket connection through the load balancer, one browser per request. From there it splits into two distinct paths.
The customer-facing path. This is the screenshot service. For each request Dune launches a browser, injects its own data and rendering scripts, renders the visualization, and captures the image. The same pattern powers OG-tag previews, on-demand query visualizations, and scheduled alerts. Because some of these queries are private, Dune injects code directly into the browser rather than handing secrets to a third party. On their side, the team layered in a queue so blocking, user-facing screenshots jump ahead of async alerts.
Real dashboards rendered through Dune's Browserless screenshot pipeline.
The developer-facing path. Over the past year Dune adopted Browserless for end-to-end testing too. The team runs 30 to 40 tests in parallel on CI to catch regressions that unit tests miss before they reach production, without standing up a large machine to host all those browsers. What's notable is how it spread: the screenshot service was already there, and the team realized it could solve a completely different problem.
We could be running 30 or 40 tests simultaneously on CI without needing a massive machine. That's where Browserless proved to be highly valuable for us.
Despite a flow more involved than a basic screenshot call, setup on both paths was straightforward and the team hit no real roadblocks working from the docs.
Results
Before, around 10% of all requests were failing or were retried. Now it's down to zero. We no longer have any issues or reports from customers about the screenshots.
On the customer-facing side, the pipeline went from roughly 10% of requests failing to zero, and the customer complaints stopped with it. (Dune optimized its own query CPU usage in the same period, so the win is shared, but the screenshot service is no longer something anyone thinks about.)
On the developer-facing side, the payoff is speed and coverage: dozens of browser-based tests run in parallel on every branch, catching critical issues unit tests can't, with no dedicated test infrastructure to maintain. One platform now serves both a production feature and the engineering team's safety net.
The thread connecting both is that Dune was never in the business of running browser automation. Offloading it freed the team from a problem that had eaten multiple quarters. A scalable in-house build would have taken at least a month, on top of around $20 a month per Kubernetes pod just to run a single browser.
What's next
Next, the team is looking at agentic use cases. Dune has invested heavily in its MCP and MCP-generated mini-apps, and expects future agentic features to lean on screenshots and browser automation the same way. Norbert's top request is multiple API keys, so Dune can split browser capacity cleanly between the customer-facing and developer-facing paths, which he sees as the unlock for putting Browserless on more of the paths that matter to users.
In Norbert's words
Just don't do it yourself. You'll spend hours on it and it'll never be that reliable. In today's era of AI and "vibe coding," it's easy to build everything yourself, but you don't want to spend time on something that isn't the core of what you're building.
Get out of the browser-infrastructure business
Dune stopped patching a self-managed browser fleet and pointed a WebSocket URL at Browserless instead. Screenshots, visualizations, and CI browsers now run on infrastructure the team doesn't think about.
Stop building browser infrastructure. Start shipping.