Render infrastructure / self-hosted Nuremberg · operational

One render engine. Every file your product ships.

supaserv turns HTML into pixels and into print: PNG, press-ready PDF, MP4, GIF. It reads files back into structured data too. One HTTP contract, on infrastructure you control, with no render vendor between you and the output.

Read the documentation Read the API documentation
Request path HTTPS
  • InHTML string, URL or uploaded file (JSON or multipart)
  • AuthBearer token (per-key rate limits)
  • EngineChromium · WeasyPrint · FFmpeg · Python
  • Out image/pngapplication/pdfvideo/mp4image/gifapplication/json
The binary is streamed straight back. Nothing is stored unless you ask for it.
InterfaceHTTP · Bearer token
RuntimeChromium, WeasyPrint, FFmpeg
RegionNuremberg (nbg) · warm
ModelSelf-hosted · no lock-in
01 / The problem

Rendering splits into three separate jobs.

Teams reach for a screenshot service, then discover that print, motion and extraction each need a different engine. Stitching four vendors together is how the bill and the blast radius grow.

Runtime Chromium does not run on the edge.

Serverless and edge functions ship without a browser. The moment a product needs a real screenshot, the platform is the wrong shape for it.

Print A PDF is not a screenshot.

Press output needs CMYK, ICC profiles, bleed and trim marks. A browser print dialog silently drops all four.

Motion Video has to be deterministic.

Capture runs as a seek loop. The page is stepped one frame at a time, so the same input produces the same file on every run.

02 / The engine

Two tiers. One contract.

A thin edge gateway handles identity and limits. The work itself happens in a dedicated container. Your application only ever sees one endpoint and one token.

  • 01 Request Your application posts HTML, a URL or a file over HTTPS.
  • 02 Gateway Hono on Vercel Edge. Authentication, routing, per-key rate limits.
  • 03 Worker Chromium, WeasyPrint, FFmpeg and Python on dedicated CPU in Nuremberg. Kept warm.
  • 04 Response The finished binary, streamed back to the caller.

Long jobs (video capture, multi-minute downloads, batch pipelines) address the worker directly, because the edge tier closes any connection at 25 seconds. The gateway tells you when to do that instead of timing out on you.

03 / Capabilities

What the engine returns.

01
Screenshot HTML → PNG

Custom viewport, plus animation-frame seeking to land on a chosen moment. Repeated renders can be served from the cache.

02
Document HTML → PDF

Chromium when speed matters. WeasyPrint when the file goes to press: CMYK, ICC profiles, bleed, trim marks and PDF/X-4.

03
Motion HTML → MP4 / GIF

A deterministic frame loop drives your animation, then FFmpeg encodes it server-side. Set frame rate, duration and resolution.

04
Cutout Image → transparent PNG

u2net segmentation with tunable strength and edge refinement, for product shots that have to sit on any background.

05
Extraction PDF → text / JSON

PyMuPDF for clean text. An optional vision pass handles scans and returns typed fields for invoices, contracts and forms.

06
Capture URL → MP4

Video pulled from YouTube or X via yt-dlp, behind an SSRF guard and a duration cap. Pick a quality, or take the audio track only. Shipped in the image, switched off in production.

04 / API surface

Eleven endpoints. No SDK required.

Everything is a POST with a bearer token. The response is the file.

POST/renderHTML to PNG
POST/render/pdfHTML to PDF, Chromium engine
POST/render/pdfv2HTML to PDF, WeasyPrint (CMYK, ICC, bleed)
POST/render/videoHTML to MP4 or GIF
POST/render/rembgImage to transparent PNG
POST/render/pdf2textPDF to text or structured JSON
POST/v1/pdfContract render: screen or print profile
POST/v1/imageContract render: PNG, JPEG or WebP
POST/render/youtubeURL to MP4, also /twitter and /x · off by default
POST/render/batchHTML to base64 PNG frames
GET/healthWorker status and engine versions

Full request and response reference, including every option object, is in the documentation.

05 / Integration

One request, one file.

There is no job queue to poll and no client library to install.

# Render a 1080 x 1350 social asset
curl -X POST https://www.supaserv.io/render \
  -H "Authorization: Bearer $SUPASERV_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<h1>Q4 results</h1>", "width": 1080, "height": 1350 }' \
  --output asset.png

# HTTP/2 200
# content-type: image/png

Swap the path for /render/pdfv2 and the same markup comes back as a press-ready PDF.

06 / Operations

The limits, stated up front.

Every number below is enforced in production, not aspirational.

Edge timeout: 25 s Requests through the gateway are cut at 25 seconds. Video and long downloads are routed to the worker directly; the gateway returns the worker endpoint rather than failing.
Rate limits: per key, per endpoint 60 requests per minute by default. Video 5, document extraction 10, PDF 30. Measured in one-minute windows.
Payload: 5 MB default 10 MB for image uploads, 20 MB for documents. Larger source material belongs in object storage, referenced by URL.
Capacity: dedicated CPU A warm machine with a recycled browser pool, so there is no cold start and no accumulating memory from long-running Chromium sessions.
Access: one key per client Every client gets its own key, held as a single environment variable on the gateway. Each request logs the key it came in with, and a key is withdrawn by deleting that one variable.
07 / Next step

Put it in front of a real job.

Send it the asset you actually need this week, then look at the file that comes back.

Read the documentation Every endpoint, every option, with copy-paste requests. Print PDF reference CMYK, ICC profiles, bleed and trim marks via WeasyPrint. Architecture How the gateway and worker are built, and why.