# Build brief — a focused alternative to Orshot

> **Verdict:** Partly, if you narrow it · **Buildability:** 49/100 · **Category:** Automation
> **Source:** https://www.canitbevibecoded.com/orshot
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Orshot. Verify current pricing and capabilities before acting.

## Context

**Orshot** — Template driven image, video, and PDF generation you call from an API, a workflow, or an AI agent. It currently costs $39/mo.

The render itself is not the moat. Headless Chromium plus a Handlebars template gets you a PNG or a PDF from JSON with a focused implementation, and for one team rendering its own OG images that really is the whole job. What does not fall out of a focused implementation is everything around the render: a visual editor non engineers can use, one design that re solves cleanly into a story, a square, and an OG card, workflows that fire on a schedule or a webhook against Sheets and Airtable, publishing into 15 plus social platforms, and a render farm that stays warm and predictable under burst. Build it if you own the templates and the volume is small. Keep paying if the people making the creatives do not write HTML.

This brief describes a focused, single-operator replacement for the part of Orshot that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Fill an HTML template with JSON, render it in headless Chromium at a fixed viewport, return PNG or PDF over HTTP, and batch a CSV through the same path.

- Automate a small number of known workflows with logs, retries, and manual recovery.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Headless Chromium (Playwright or Puppeteer).
- A template language and a place to store templates.
- A warm browser pool and a render queue.
- Font and brand asset handling.
- Object storage plus a CDN for delivery.
- A host that tolerates burst traffic.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a local templated image and PDF render service to replace an image generation API. Requirements:

- Node 22 with Express in a single server.js, plus Playwright driving Chromium.
  No build step, no framework, no database.
- A template is a folder at templates/<name>/ holding index.html with Handlebars
  placeholders, style.css, and meta.json with width, height, and defaults.
- Ship 3 starters: an OG card at 1200x630, an Instagram square at 1080x1080, and
  a one page invoice that renders to PDF.
- POST /render {template, modifications, format} returns PNG, JPEG, or PDF.
  Fill the template, set the viewport from meta.json, screenshot the page.
  PDFs go through page.pdf() instead.
- GET /render/<template>.png?headline=...&image=... does the same thing from
  query params so the URL can be dropped straight into an img tag.
- POST /batch accepts a CSV or a JSON array, renders every row into out/ with a
  concurrency of 4, and returns a manifest of paths.
- A brand.json with 4 colors and 2 local font files, injected into every template
  as CSS custom properties so a rebrand is one file edit.
- Keep one browser instance warm and reuse pages. Launching Chromium per request
  is the thing that makes the naive version unusable.
- Cache by a hash of template plus modifications into .cache/ and serve hits from
  disk before touching the browser.
- Fonts load from ./fonts via @font-face with file:// URLs, and the renderer waits
  on document.fonts.ready so text never screenshots mid swap.
- Out of scope: a visual editor, video, social publishing, and multi tenant auth.
  I write templates in HTML by hand and that is the trade I am making.
- README: how to add a template, how fonts resolve, and the Docker line that
  installs the Chromium system dependencies.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Visual studio editor for non developers.
- 2,000 plus prebuilt templates.
- One design auto resized to every social format.
- Scheduled and webhook driven workflows.
- Publishing to social platforms.
- MCP and agent integrations.
- White label embedded editor.
- Workspaces, audit logs, and team access.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: high. No reviewed project implementation is linked yet.

## Existing alternatives

Before building, compare these checked options:

- [Gotenberg](https://gotenberg.dev/) — A Docker API that turns HTML into PDFs and screenshots, so you bring the templates and it handles the Chromium wrangling you do not want to own
- [Cloudinary Free](https://cloudinary.com/pricing) — Free forever with 25 monthly credits; text and image overlays are URL parameters, which covers product shots and simple cards without a render server
- [ImageKit Free](https://imagekit.io/plans) — Forever free at 20 GB bandwidth with all transformations included, so layered text over a base image is a URL rather than a pipeline

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [Bannerbear](https://www.bannerbear.com/) — The API first image generation category opener; proof the template plus API shape is a real product and not a script
- [Satori](https://github.com/vercel/satori) — Vercel's HTML and CSS to SVG renderer, the engine behind most homegrown OG image endpoints

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/orshot
