Build vs buy for image generation is mostly a question about what you are willing to be on call for. A script that screenshots a page takes an afternoon. A renderer that stays up for two years is a different project, and the gap between those two is where the cost hides.
What you own when you build
The first version is a browser, a page, and a screenshot call, as in Chrome’s Puppeteer guide. Then the list grows:
| Component | What it means in practice |
|---|---|
| Browser binary | Puppeteer and Playwright both download and pin browser builds, so upgrades are your change window |
| Fonts | Missing fonts on the server render as fallback glyphs, and the bug only shows in production |
| Load timing | Deciding when a page is ready is a heuristic you tune per template |
| Concurrency | Browsers are heavy processes; a burst of renders needs a queue and a pool |
| Storage and caching | Rendered files need a bucket, cache headers, and cleanup |
| Signed URLs | <img> and og:image cannot carry a secret, so you build and verify signatures yourself |
| Retries and webhooks | Slow renders need a 503 and Retry-After path, and completion callbacks need idempotency |
| The layout | Every design change is a code change and a deploy |
None of these is hard alone. Together they are a product that nobody was hired to maintain.
What you give up when you buy
Control. A template API draws what its editor can draw, so arbitrary CSS and live-page capture are out of scope. You also take on a vendor, and your layer names become a contract; export your templates and keep the payload schema in your own repo.
When building is the right call
- The layout is the product, such as a screenshot service or a design tool.
- You already operate headless browsers for another purpose and have the monitoring in place.
- Volume is tiny and stable, and no designer will ever touch the output.
- You need HTML features no editor offers.
When buying is the right call
- One layout repeats across records: Open Graph cards, certificates, product banners, email heroes.
- A non-engineer edits the design.
- Renders must be reliable at a burst, such as a registration list closing or a catalog price change.
jsontoimg covers the second list with POST /api/v1/render, signed URLs, 50-job batches, and webhooks. Prices for it and seven other tools are in Image Generation API Pricing. The technical comparison of the two approaches is in HTML to Image API vs Template API.
FAQ
Is it cheaper to build an image generation service myself?
The first version is cheaper to start. Running it is where costs accumulate: browser upgrades, fonts, concurrency, storage, signed URLs, and every layout change shipping as a deploy.
When should I run my own headless Chrome?
When the layout is the product, when you already operate browsers and monitor them, or when you need arbitrary HTML that no template editor supports.
What is the main risk of buying?
Lock-in on layer names and editor capability. Keep your payload schema in your own repository so a migration means rebuilding templates, not rewriting every caller.
Can I migrate from Puppeteer to a template API gradually?
Yes. Move one repeating layout first, such as Open Graph cards, behind the API and keep the screenshot script for pages that need arbitrary HTML.
Related Resources
- How JSON-to-image conversion works — the pillar guide
- Image generation API pricing — the numbers
- Why I built a JSON-to-image API instead of Puppeteer — the origin story
- Image generation API: 8 questions — vendor checklist