@santi020k/og

Goals

• Keep brand ownership inside each project instead of prescribing a template or content model.

• Make committed social images verifiable with deterministic fingerprints and a read-only CI command.

• Regenerate only what changed across collections that may contain hundreds of cards.

• Stay framework-agnostic so the same pipeline works with Astro, Next.js, Node.js, a CMS, or a static array.

What I built

• 01

  A typed configuration API and CLI

  with init, generate, check, and force-generation workflows.

• 02

  Sharp and Satori entry points

  for SVG-based designs, HTML-like templates, font loading, and raster encoding.

• 03

  Five output families

  selected by extension: SVG, PNG, WebP, JPEG, and AVIF.

• 04

  Content-aware caching

  that fingerprints card data, dimensions, output names, configuration, templates, fonts, logos, and declared source files.

• 05

  Bounded worker-thread generation

  for large collections without letting native image work overwhelm CI memory.

• 06

  Tracked cleanup

  that removes only obsolete outputs recorded by the previous manifest instead of scanning and deleting arbitrary files.

Technical highlights

Renderer contract

projects can return SVG, use the bundled Sharp or Satori adapters, or provide a completely custom renderer.

Safe paths

output files and the cache manifest are constrained to the project root to prevent traversal.

Deterministic CI

santi-og check reports missing or stale outputs without mutating the repository.

Portable inputs

card data can come from content collections, Markdown, CMS responses, framework loaders, or any serializable source.

Parallel builds

worker renderer modules support structured-cloneable data and automatic or fixed concurrency.

Results

Why it matters

Social images are small artifacts backed by a surprisingly repetitive build system.