Can Orshot be vibe coded?
Template driven image, video, and PDF generation you call from an API, a workflow, or an AI agent
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.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
high editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- 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.
The parts a prompt cannot buy
- visual studio editor for non developers
- 2,000 plus prebuilt templates
- one design auto resized to every social format
- scheduled and webhook driven workflows
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
Build, switch, or keep paying
Narrower, with trade-offs
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.
Use the build brief ↓3 checked options
- Gotenberg ↗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 ↗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 ↗Forever free at 20 GB bandwidth with all transformations included, so layered text over a base image is a URL rather than a pipeline.
$39/mo
Because the person who needs the graphic is usually not the person who can maintain a Chromium pool, and the value shows up when marketing edits a template without filing a ticket.
Visit Orshot ↗Why people still pay
Because the person who needs the graphic is usually not the person who can maintain a Chromium pool, and the value shows up when marketing edits a template without filing a ticket.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
Reliability at the vendor's scale is an operations problem, not a prompt.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Orshot
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 — 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 — 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 — 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 — The API first image generation category opener; proof the template plus API shape is a real product and not a script
Satori — Vercel's HTML and CSS to SVG renderer, the engine behind most homegrown OG image endpoints
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/orshot
You still own the product
- 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.
Projects built from this idea
No reviewed implementation has been linked for Orshot yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Orshot?Submit the project as evidence for this report.
Open-source prior art
Before you start
Can Orshot be vibe coded?
Partly, if you narrow it. 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.
What can an AI coding agent reproduce from Orshot?
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.
What will a DIY Orshot replacement still be missing?
visual studio editor for non developers; 2,000 plus prebuilt templates; one design auto resized to every social format; scheduled and webhook driven workflows; Connectors, OAuth flows, and vendor API changes require constant upkeep.; The last 20 percent is sync, migration fidelity, speed, and edge cases.
What do I still own after building a Orshot alternative?
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.