The same screenshot, both ways

Puppeteer (self-hosted)

import puppeteer from "puppeteer";

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setViewport({ width: 1280, height: 720 });
await page.goto("https://example.com", { waitUntil: "networkidle0" });
await page.screenshot({ path: "out.png", fullPage: true });
await browser.close();

// Still to solve: where this runs, how many at once, what happens when
// the renderer dies, fonts in the container, and the ~400 MB Chromium
// download in your CI image.

getSnap.dev

curl -X POST https://api.getsnap.dev/v1/screenshot \
  -H "X-API-Key: sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "format": "png", "full_page": true}'

# -> {"url": "https://cdn.../screenshots/....png"}

What running it yourself costs

These are not estimates. They are measured from the getSnap.dev production deployment on 5 October 2026, which runs Playwright 1.50 on Chromium:

What	Measured	Why it matters
Container image	3.97 GB	Pulled on every deploy, cached on every CI runner, stored in every registry.
Chromium on disk	656 MB	Downloaded by playwright install; a cold CI cache pays for it every time.
Memory ceiling	3 GiB	A full-page capture of a heavy site is the spike that finds this limit.
Concurrent captures	3	Throughput against OOM risk. Raising it is not free.
Capture timeout	30 s	Long enough for slow pages, short enough that a stuck one does not hold a worker.

None of this is exotic. It is simply the part that does not appear in the five-line example on the library's front page.

What actually breaks when you run it yourself

Not a list of hypotheticals. Every one of these is fixed in getSnap.dev's source with a comment explaining the symptom, because each one reached production first.

Teardown that skips itself and leaks a renderer

The obvious cleanup is wrong:

} finally {
  await page.close();
  await context.close();   // never runs if the line above rejects
}

When the renderer has already died — "Target closed", an OOM on a heavy full-page capture, the common cases — page.close() rejects and the context is never closed. The orphaned context keeps its renderer process alive on the shared browser until the container hits its memory ceiling. Worse, the rejection propagates out of the finally and replaces the real capture error, so your logs name the wrong cause.

networkidle that never arrives

Waiting for the network to go quiet is the natural choice and it is a trap. Any page with long-polling, websockets or analytics beacons never goes quiet, so the capture runs to the full timeout and fails. You need a weaker condition available per request, and you need to decide which pages get which.

Options that contradict each other

Set quality on a PNG and Chromium throws options.quality is unsupported for the png screenshots. Pass a cookie with both a URL and a domain and you get Cookie should have either url or path. These are easy to fix once and easy to reintroduce, and they surface as a failed capture rather than a validation error.

Capacity you have to pick in advance

This deployment runs 3 concurrent workers against a 3 GiB ceiling with a 30-second capture timeout. Those numbers are a compromise between throughput and being OOM-killed, and they are yours to tune, re-tune, and get paged about.

Which should you use?

Stay with Puppeteer if…

• You need to drive a page, not photograph it — form fills, multi-step flows, scraping behind a login that changes shape.
• You are already running browsers for end-to-end tests, so the infrastructure cost is paid.
• Your captures are infrequent and local, where a cold start and a 400 MB download do not matter.
• You need Chrome DevTools Protocol access that no HTTP API exposes.

Use a hosted API if…

• Screenshots are a feature of your product, not a step in your build.
• You do not want a 4 GB container image and a memory ceiling in your deployment.
• You want cache, CDN delivery, retries and quotas without building them.
• You want captures from code that has no business running a browser — a Rails app, a Lambda, a cron job.

Frequently asked questions

Next steps

• Playground — take a capture in the browser, no signup
• Code examples — every option, with cURL, Node.js and Python
• Quick starts for Python, Node.js, PHP, Ruby, Go, Java, C#
• Already paying for a screenshot API? Compare the hosted options

Related reading

• Where the DevTools screenshot stops working — the manual and self-hosted options, compared honestly
• Puppeteer vs Playwright in 2026 — if you are still choosing between the two