Cloudflare Browser Run alternatives in 2026: when PDFs deserve a document product

Why teams route PDFs away from Browser Run

The meter runs on browser duration. Quick Actions are billed on browser time; Browser Sessions on time plus concurrency, with concurrent browsers computed as the monthly average of daily peaks (see Cloudflare's pricing page for the current numbers). For agents exploring the web, that model fits. For rendering 3,000 statements on the last day of the month, it means your bill depends on page load times and your batch's concurrency spike, neither of which you want as billing variables. Per-document pricing makes the same run cost arithmetic instead of forensics.

PDF output is a browser feature, not a product. The /pdf Quick Action and page.pdf() inside a session give you Chrome's print output with Chrome's options, and that is where it ends. The document pipeline around it (upload to your bucket, completion webhooks, retry-safe idempotency, accessible tagged PDFs, bookmarks, watermarked test renders) is yours to build in Workers code. Screenshot-and-scrape users never notice; invoice pipelines notice immediately.

Capacity is plan math. Three concurrent browsers on the free plan, 10 included on paid with overage per additional browser, spin-up rates per minute: real limits that agent workloads absorb gracefully and bursty document batches slam into. Queueing renders through a browser pool is exactly the infrastructure a rendering service was supposed to spare you.

The roadmap is agents. Live View, human-in-the-loop, session recordings, and Stagehand's intent-driven element finding are excellent features aimed at somebody else's use case. Document generation is not where this product is investing, which is a fair thing for it to choose and a fair reason to route documents elsewhere.

The parallel-rendering bill, worked out

Parallelism is where Browser Run's pricing and document workloads disagree most. Every concurrent render is a concurrent browser, billed at $2.00 per browser beyond the included 10, and the count that gets billed is the monthly average of your daily peaks. Transformy has no concurrency dimension at all: fire 50 renders at once or use the async mode, and the price is still per document. Three low-volume scenarios where that difference decides the bill:

To be fair in the other direction: with fan-outs of 10 or fewer and fast-rendering pages, Browser Run's usage bill at middling volumes can undercut a $99 plan. The flip factors are wide daily parallelism, slow pages, and tight delivery windows; run your own numbers with the formula from the tip above before either bill surprises you.

The shortlist at a glance

The managed option: Transformy

Transformy is what the PDF corner of Browser Run looks like when it is the entire product. The engine is the same headless Chromium, but the unit of thought is a document, not a browser: one authenticated POST with document parameters, a per-document price, and no session lifecycle or concurrency math. It is plain HTTPS, so a Worker calls it with one fetch, and so does the rest of your stack.

// Inside a Worker: no browser session, no browser-hours
const res = await fetch("https://api.transformy.io/v1/pdf/chrome", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${env.TRANSFORMY_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://app.example.com/invoices/1042",
    page_size: "a4",
    footer: { html: '<span style="font-size:10px">Page {{page}} of {{pages}}</span>' },
    output: "storage", // delivered straight to your R2 bucket
  }),
});

The document plumbing is the point: async jobs with signed webhooks for batch runs, delivery straight to your own bucket (R2 included) instead of hand-written upload code, idempotency keys so retried Workers cannot double-render, tagged (accessible) PDFs and bookmarks, and a free watermarked test mode. Pricing is document-shaped: free tier of 100 documents a month (no credit card), then $99/month for 10,000 documents and $0.01 per additional document, independent of how long pages take to load or how hard your batch spikes. The honest trade-offs: it renders HTML and URLs only, so Browser Run stays the better tool for screenshots, scraping, and agent sessions, and it is another vendor rather than a line on the Cloudflare bill you already pay.

The in-Worker option: pdf-lib

For simple documents (receipts, tickets, labels, single-page confirmations), pdf-lib constructs the PDF inside the Worker in pure JavaScript: no browser session, no browser-hours, milliseconds of CPU. The ceiling is the usual one for construction libraries: layout is code, so styled multi-page documents with flowing content become arithmetic you maintain. Right for a barcode ticket, wrong for a designed report, and unbeatable on cost for the documents it fits.

The self-hosted routes

Puppeteer or Playwright on your own infrastructure

Self-hosting removes every plan limit and adds every operational cost: pools, memory recycling, crash recovery, Chrome upgrades, and shipping browsers in your deploys. It is the control option for teams with compliance reasons or the ops capacity to want it. Our Puppeteer alternatives and Playwright alternatives pages map that territory honestly, in both directions.

Gotenberg

Between a platform's browsers and browsers in your app sits Gotenberg: Chromium behind an HTTP API in a Docker container you host. Workers (and everything else) call it like a managed API; your cluster carries the container and its scaling. It suits teams leaving Browser Run for control rather than convenience; our Gotenberg alternatives page covers what that ownership costs as volume grows.

Migrating: from browser sessions to document requests

The mental shift is from operating a browser to describing a document:

- /pdf Quick Action   /  page.pdf() in a session
+ POST /v1/pdf/chrome with document options

- puppeteer.launch() + session management in a Worker
+ one fetch(); no session lifecycle

- page.pdf({ format: "A4", ... })
+ "page_size": "a4" and friends, as request fields

- headerTemplate / footerTemplate
+ "header"/"footer" with {{page}}, {{pages}} tokens

- await env.BUCKET.put(key, pdf)   # hand-written R2 upload
+ "output": "storage"   # delivered to your bucket, R2 supported

- browser-hours + averaged-peak concurrency billing
+ per-document pricing

- Live View, recordings, Stagehand, crawling
# no equivalent; keep those workloads on Browser Run

The last row is the scope statement: migrate the document workload, keep the automation where it thrives.

Frequently asked questions

The bottom line

Split the workload and both halves get cheaper to run and easier to reason about. Documents: Transformy renders the same Chrome output with per-document pricing and the pipeline built in, and the free tier (100 documents a month, no credit card) is one Worker fetch away. Documents too simple for any browser: pdf-lib, inside the Worker. Control requirements: Puppeteer, Playwright, or Gotenberg on your own infrastructure. Agents and automation: right where they are.

Browser Run gave agents a browser on Cloudflare's network, and that is exactly what it should be. Your invoices were never really its audience.