What Does a Screenshot API Actually Cost? Price per 1,000 Captures, Self-Hosted vs Managed
The question people actually ask is “how much does a screenshot API cost?” The question they should ask is “what is the total cost of getting N screenshots a month, reliably, for the next two years?” Those two questions have very different answers, and the gap between them is where most of the bad d…
The question people actually ask is “how much does a screenshot API cost?” The question they should ask is “what is the total cost of getting N screenshots a month, reliably, for the next two years?” Those two questions have very different answers, and the gap between them is where most of the bad decisions live.
This is the arithmetic on both sides. The managed numbers are exact, because they’re published and I can simply read them off the page. The self-hosted side gets shapes and ranges instead of figures, on purpose: your instance size, your region, your average page weight and your provider’s rate card move that total by more than any estimate written by someone who has seen none of them. So what follows on that side is a list of which lines exist, which ones scale with capture volume, which ones you pay while completely idle, and how they rank against each other. Fill it in with the rates on your own invoices and you’ll have something you can defend in front of a finance team.
The managed side, exactly
Four tiers, monthly, in EUR:
- Free — €0 for 50 requests a month.
- Pro — €7 for 1,000 requests a month.
- Ultra — €20 for 15,000 requests a month.
- Mega AI — €39 for 30,000 requests a month.
The marginal figure that matters is the fully-used rate. Ultra at 15,000 requests works out to €1.33 per 1,000 captures. Mega AI at 30,000 works out to €1.30 per 1,000. Pro is €7 per 1,000 — a small-volume price, and priced as one. Ultra for a full year is €240.
Two things about those numbers before we compare anything. First, they’re per request, not per successful screenshot, which matters more than it sounds and gets its own section below. Second, the effective rate you personally pay is the plan price divided by what you actually use, not by what’s included — a habit worth keeping, because it’s the number that makes plan choices obvious.
What the managed rate covers is not just compute. It covers the browser fleet, the Chromium upgrades, the rendering environment’s fonts, storage of the resulting image (the API response carries a hosted link to it), and someone else’s pager. That bundling is the entire thing being priced, and it’s why comparing a managed rate against a compute-only estimate is comparing two different products.
The self-hosted side, completely
The incomplete version of this list is precisely why people underestimate self-hosting. Here is the complete one.
Compute and memory. This is the line everybody starts with and the one that misleads most, because the mental model is wrong. A Node or Python web process serving JSON has a working set measured in tens of megabytes, and a modest box will handle hundreds of concurrent requests. A Chromium instance rendering a real page — with images, fonts, web workers and a JavaScript heap — has a working set measured in hundreds of megabytes to gigabytes, and the same box will handle a handful of concurrent captures before it starts swapping or getting OOM-killed. Whatever machine size your instinct suggests, the browser needs roughly an order of magnitude more memory per unit of concurrency than you’re used to. That changes both the machine you provision and how many of them you need to absorb a burst.
Bandwidth, in both directions. People budget egress and forget ingress. To render a page, the browser downloads the whole page: hero images, video posters, web fonts, third-party scripts, analytics beacons. A single content-heavy page can pull several megabytes in, and you pay for that traffic on a metered path. Exactly which meter depends on your topology — plain egress, inter-zone transfer, or a managed gateway that charges for every gigabyte it forwards — so the useful exercise is working out which of those a capture worker actually trips in your architecture, remembering that a browser is a far heavier network client than the service it replaces. Then you pay again on the way out, serving the resulting images to whoever consumes them.
Object storage, and its growth. Storage is not a monthly cost, it’s an accumulating one. At flat capture volume with no retention policy, your storage bill grows every single month, forever, because last month’s screenshots are still there. Work it out as captures per month × average image size × months retained, and then look at the twenty-fourth month rather than the first. A lifecycle rule that expires or tiers old captures is a five-minute config change that changes the slope of a line on your bill; almost nobody writes it on day one.
Chromium version churn. This is the line with no end date, which is what makes it a budget item rather than a setup task. Browsers ship every few weeks; each release is another chance that the combination you tested against stops matching itself. Plan against roughly an engineer-week a year, arriving in pieces you didn’t schedule. The mechanics of what actually breaks are worked through in the Lambda article linked below.
On-call and incident time. The line with no invoice attached, which is exactly why it disappears from spreadsheets. Browser processes leak, disks fill with crash dumps, and a queue jammed behind one page that never finishes loading does not wait for business hours. Somebody carries that pager.
Add those up and the conclusion is uncomfortable but consistent: at the volumes most teams actually run, the biggest number in the self-hosted column is people’s time, not machine time. That engineer-week from the churn line is, by itself, a bigger number than the entire managed bill at every volume in this article — which is precisely why a per-1,000 rate is a poor guide to this decision. If you want the operational substance behind those last two lines, along with package limits, cold starts, memory provisioning and the GB-second arithmetic, we worked all of it through for the serverless case in running Puppeteer on AWS Lambda.
Scenario 1: about 500 captures a month
A side project. A small SaaS generating Open Graph images for its public pages. Maybe a nightly capture of a dozen dashboards.
Managed: the free tier’s 50 requests won’t cover it, so this is Pro at €7 a month, €84 a year. Effective rate at 500 used out of 1,000 included: €14 per 1,000. That’s an unimpressive per-unit number and an entirely irrelevant one, because the absolute figure is €7.
Self-hosted: at this volume the compute is close to noise. You could run 500 captures a month on a small always-on instance, or on a function that’s idle 99.9% of the time, and the infrastructure bill would plausibly land in the same neighbourhood as Pro — possibly under it. It still isn’t close, and the reason has nothing to do with infrastructure. Standing the thing up at all costs more than €84 buys, on any generous reading of how long it takes — and the build is the cheap half, because from then on the upgrades and the incident calls are yours for as long as the feature lives.
Verdict: managed, decisively. Not because the compute is expensive but because the compute isn’t the cost. At 500 captures a month you are choosing between paying €84 a year and owning a browser fleet in exchange for saving some fraction of €84 a year. There is no version of that trade that works out.
Scenario 2: about 5,000 captures a month
A real product feature. Link previews for user-submitted URLs, PDF exports of reports, a visual QA pass on every deploy across a few dozen pages.
Managed: Pro’s 1,000 doesn’t reach, so this is Ultra at €20 a month, €240 a year. Effective rate at 5,000 used: €4 per 1,000, against a floor of €1.33 if you grew into the full 15,000. Which means the next three-fold increase in volume is free, and that headroom is worth something on its own — a feature that takes off doesn’t trigger an infrastructure conversation.
Self-hosted: this is where compute stops being noise and where honest comparisons get interesting. Depending on your provider, your region, your page weight and how well you keep instances busy, raw compute for 5,000 renders a month can genuinely come in under €20. That result is real and it would be dishonest to bury it: measured on machines alone, self-hosting can win at this volume. What that measurement leaves out is that you’d be running a fleet that has to absorb bursts, with storage accumulating, egress metered, and a browser stack to keep current — all to compete with a €240 annual line item. One incident consumes the entire yearly saving. Two consume several years of it.
Verdict: managed, unless someone in your organisation already runs a browser fleet. That exception is real and worth naming: where rendering infrastructure is already a named team’s responsibility, with rotations and runbooks that would exist whether or not you needed screenshots, bolting captures onto it is close to free and the comparison genuinely changes. Outside that case, what you’re really deciding is whether to open a new operational surface for something that sits at the edge of your product — and operational surfaces without a clear owner have a habit of becoming everyone’s problem at the worst possible moment.
Scenario 3: about 50,000 captures a month
A monitoring platform capturing a few thousand tracked pages daily. A web archive. An agency running a large site inventory on a schedule.
This is the volume where the answer stops being automatic, and it deserves to be stated plainly rather than spun.
Managed: 50,000 a month sits above the published grid — Mega AI’s 30,000 requests is the largest published allowance — so none of the per-1,000 figures earlier in this article describe it, and projecting the curve past its last published point would be inventing a number rather than reporting one. For a volume like this the honest instruction is to start from the published plans — they top out at 30,000 requests, with overage handling layered on top — and work out your own exposure from there rather than from anything I could put in a blog post. Which means the interesting column in this scenario is the other one.
Self-hosted: this is the first scenario where volume works for you rather than against you. Fifty thousand renders a month is enough sustained load to keep machines occupied instead of idling, so you’re paying for capacity you’re actually consuming. The bigger shift is what happens to the fixed half of the bill. The engineer-week a year of browser upkeep is the same engineer-week at 50,000 captures as at 500 — you just divide it across a hundred times more output, and a maintenance burden that was ruinous per screenshot in scenario one becomes a rounding error here. What’s left is a bill that moves with capture count, which is a shape a large operation can forecast and optimise.
Verdict: it depends, and the deciding factors are usually not cost. Three questions settle this more reliably than the spreadsheet does.
Where is the page allowed to be rendered? Internal tools, anything behind your own authentication, anything carrying personal data that cannot cross an organisational or jurisdictional boundary — that constraint outranks every figure on this page and points at a browser inside your own perimeter. It’s a compliance answer, not an economic one.