Cloudflare Browser Rendering alternatives in 2026: PDFs beyond the Workers limits
The best Cloudflare Browser Rendering alternative depends on why you are looking. If you need more rendering capacity and document control than the Workers platform's browser limits allow, a dedicated HTML-to-PDF API like Transformy is purpose-built for exactly that job. If you want rendering on infrastructure you own, self-hosted Puppeteer or Playwright, or Gotenberg in Docker, take the browser in-house. And if your PDFs are simple enough, pdf-lib constructs them inside the Worker itself.
Fair framing first: if your application lives on Workers and occasionally needs a screenshot or a PDF, a managed browser one binding away is genuinely convenient. The searches for alternatives start where the design does: it is a browser-automation utility attached to a compute platform, not a document product.
$ wrangler tail pdf-worker
POST /render 200 1.4s
POST /render 200 1.6s
POST /render 429 0.1s
Browser Rendering: concurrent session limit
reached for this account
POST /render 429 0.1s
POST /render 429 0.1s
invoices queued ······· 2,847
$ KEY TAKEAWAYS
- It is a browser utility, not a document product. Rendering options are Puppeteer's; there is no document-side plumbing (async jobs, delivery options, idempotency) beyond what you build in your Worker.
- The limits are platform limits. Concurrent browser sessions and session lifetimes are capped per plan; bursty PDF workloads (invoice runs, report batches) meet those caps first.
- A dedicated PDF API is the like-for-like upgrade. Same headless Chrome output, reached by plain HTTPS from anywhere (Workers included), with document features instead of browser sessions.
- Simple documents can skip the browser session entirely. pdf-lib runs inside Workers and constructs PDFs directly; for receipts and labels it is faster than launching any browser.
- Self-hosting remains the control option. Puppeteer, Playwright, or Gotenberg on your own infrastructure trade Cloudflare's limits for your own ops.
Why teams look for alternatives
PDF workloads are bursty; session limits are not. Browser Rendering caps concurrent sessions and session duration per plan. Interactive use rarely notices; a month-end batch of a few thousand invoices notices immediately, and the fix (queueing renders through limited sessions inside Workers) is exactly the infrastructure code a rendering service was supposed to save you.
The PDF controls stop at page.pdf(). Margins, formats, and header/footer templates are there, because Puppeteer's options are there. What is not: output delivery beyond what your Worker writes (you build the R2 upload, the retry logic, the signed notification), watermarked test modes, accessible/tagged output, bookmarks, idempotent retries. For screenshots and scraping that is fine; for a document pipeline it is a starter kit.
It assumes Workers, permanently. The bindings, the session management, and the operational model live inside Cloudflare's runtime. If part of your stack runs elsewhere (a Laravel monolith, a Django app, a data pipeline), Browser Rendering is not reachable as a general service the way an HTTP API is; the REST endpoints help but keep the same platform limits.
Debugging happens at the platform's mercy. When a render misbehaves, you are debugging a remote browser through Workers logs, with the platform's timeouts layered on top of the page's behavior. Self-hosted setups and document APIs both give you more direct failure surfaces.
None of this makes Browser Rendering a mistake. For Workers-native apps with light rendering needs, it is the lowest-friction option there is. The alternatives below are for when PDFs stop being an occasional feature and start being a workload.
Tip
Check your actual render volume and concurrency against your plan's browser limits before migrating anything; if you are nowhere near them and your whole stack is Workers, staying put is the right call.
The shortlist at a glance
| TOOL | TYPE | ENGINE | WHERE IT RUNS | PRICING | BEST FOR |
|---|---|---|---|---|---|
| Transformy | Managed PDF API | Headless Chrome | Vendor fleet, called from anywhere | Free 100 docs/mo, then $99/mo for 10,000 | Document workloads with real plumbing needs |
| pdf-lib | JS library | None (constructs PDF directly) | Inside your Worker | Free | Simple documents with zero browser sessions |
| Puppeteer / Playwright (self-hosted) | Libraries | Headless Chrome | Your servers | Free (your infra) | Full control, your own ops |
| Gotenberg | Self-hosted service | Chromium + LibreOffice | Your cluster (Docker) | Free (your infra) | Service-shaped rendering in-house |
The managed option: Transformy
Transformy is what Browser Rendering's PDF corner looks like when it is the whole product. The engine is the same headless Chromium, but the interface is a document API rather than a browser session: one authenticated POST with document parameters, no session lifecycle, and concurrency that scales with your traffic instead of a per-plan browser cap. It is plain HTTPS, so it works identically from a Worker, a queue consumer, or the parts of your stack that never touched Cloudflare.
// Inside a Worker: no browser binding, no session limits
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 actual upgrade: 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 starts free (100 documents a month, no credit card); the Pro plan is $99/month for 10,000 documents, then $0.01 per additional document. The honest trade-offs: it renders HTML and URLs only (no screenshots-of-anything utility; Browser Rendering stays better as a general automation tool), and it is another vendor alongside Cloudflare rather than a checkbox on the plan you already pay for.
The in-Worker option: pdf-lib
The alternative most Workers teams overlook: if the documents are simple (receipts, tickets, labels, single-page confirmations), you can construct the PDF inside the Worker with pdf-lib and never open a browser session at all. It is pure JavaScript, runs comfortably in the Workers runtime, and returns in milliseconds. The ceiling is the same as all construction libraries: layout is code, so styled multi-page documents with wrapping content become arithmetic you maintain. Right for a barcode ticket; wrong for a designed 10-page report.
The self-hosted routes
Puppeteer or Playwright on your own infrastructure
Running the browser yourself removes every platform limit and adds every operational cost: pools, memory recycling, crash recovery, Chrome upgrades, and the deployment weight of shipping browsers. It is the control option, chosen deliberately by teams with the ops capacity for it. Our Puppeteer alternatives and Playwright alternatives pages map that territory honestly, including when it is the right call.
Gotenberg
Between "browser sessions on a platform" and "browsers in your app" sits Gotenberg: Chromium behind an HTTP API in a Docker container you host. Your Workers (or anything else) call it like a managed API; your cluster carries the container. It suits teams who left Browser Rendering for control reasons rather than convenience ones; our Gotenberg alternatives page covers its own trade-offs at scale.
Migrating: from a browser session to a document request
The mental shift is from managing a browser to describing a document:
- const browser = await puppeteer.launch(env.MYBROWSER);
- const page = await browser.newPage(); // + session keep-alive logic
+ one fetch(); no session lifecycle
- await page.goto(url); await page.pdf({ format: "A4" });
+ "url" + "page_size": "a4" 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
- retry logic around 429 session-limit responses
+ "async": true + signed webhooks + idempotency keys
- REST /pdf endpoint # same platform limits
+ same shape, document-grade options, no session capsScreenshot, scraping, and automation code has no equivalent here and should stay on Browser Rendering or a self-hosted browser; migrate the document workload, not the utility.
Frequently asked questions
Is Cloudflare Browser Rendering good?+
For Workers-native applications with light or occasional rendering needs, yes: it is the lowest-friction way to reach a managed browser from that platform. The alternatives above address document workloads that outgrow its session limits and PDF surface.
What are Browser Rendering's limits?+
Concurrent browser sessions and session lifetime are capped per plan, with usage-based pricing tied to the Workers platform; the specific numbers change with plans, so check Cloudflare's current documentation against your renders-per-minute at peak.
Can I generate PDFs in a Worker without a browser at all?+
Yes, two ways: construct simple documents directly with pdf-lib inside the Worker, or call an HTML-to-PDF API over HTTPS and let the browser run elsewhere. Both avoid browser sessions entirely.
Does Transformy work from Cloudflare Workers?+
Yes; it is a plain HTTPS API, so a fetch from a Worker is a first-class client. Delivery to R2 via the storage output mode means the PDF never has to pass back through the Worker at all.
Should I self-host Puppeteer instead?+
If you left Browser Rendering for control (compliance, network boundaries, custom Chrome flags), self-hosting is the honest answer and comes with the full ops bill. If you left because of limits or missing document features, a dedicated API solves that without inheriting the operations.
The bottom line
Match the exit to the reason. Outgrew the session limits or need document plumbing: Transformy is the like-for-like upgrade, same Chrome output with a document API around it, and the free tier (100 documents a month, no credit card) works from a Worker with one fetch. Documents too simple for any browser: pdf-lib, right inside the Worker. Need control more than convenience: Puppeteer, Playwright, or Gotenberg on your own infrastructure.
Cloudflare made a headless browser a platform feature. The alternatives above are for the day your PDFs need a document product instead of a browser session.