Statamic Og Images Laravel Package

Product Decisions This Supports

• Automated social/OG image generation for content. The addon wires Statamic entries (collections, taxonomies, and other content types) to templated OG image rendering, so every published URL ships a branded share card without an editor touching a design tool. This directly supports distribution and CTR decisions on the content roadmap.
• Build vs. buy for image rendering infrastructure. The real "build" alternative here is standing up headless Chrome (Puppeteer/Browsershot) plus a caching layer, a queue, and font/CSS packaging — a multi-week engineering line item with ongoing ops cost. This package is a thin Statamic-native wrapper over the html2img rendering API, which converts a standing infra commitment into a small, usage-priced vendor line. That is the core trade to make explicit in any ADR.
• Templating and brand-consistency roadmap. Because OG layouts are authored as templates rather than one-off assets, it enables decisions like per-collection layouts, A/B testing of share card designs, and consistent typographic/logo treatment across a content set — cheap to iterate on, and reviewable like any other view.
• SEO/social debt reduction. Useful as a backlog item for existing sites with missing or generic og:image output. Adoption is typically a "sweep the whole corpus once" project rather than a gradual rollout.
• Not a fit for: PDF generation, dynamic ad creative, or user-facing image APIs — this is a narrow, content-publishing concern.

When to Consider This Package

Consider it when:

• You are on Statamic v4/v5 and already comfortable installing addons via Composer; the package assumes Statamic's data model and templating, not vanilla Laravel.
• You produce enough content that hand-authored share images do not scale (roughly: dozens per month and up, or a large existing back-catalogue to backfill).
• You are willing to accept a third-party rendering API as a dependency, with the associated per-image cost, network latency on first render, and uptime coupling.
• Your OG image needs are template-driven and brand-consistent rather than bespoke/illustrative.

Look elsewhere when:

• You need self-hosted or air-gapped rendering (regulated, on-prem, or privacy-sensitive content) — you want a Browsershot-based implementation or an in-house service instead.
• You have hard availability or data-residency requirements that a third-party image API cannot meet.
• Volume is very low (a handful of landing pages). Design the images once by hand; the integration cost exceeds the benefit.
• You need guarantees. At v1.0.x this is a young addon with a small maintainer surface and a patch-level release history — treat it as a pilot candidate, not a load-bearing dependency, until you have vetted it against your Statamic version and pinned it in composer.json.
• You are not on Statamic — most of the value is the CMS integration; a plain Laravel app gains little over calling the html2img API directly.

How to Pitch It (Stakeholders)

To executives: Every shared link is a free impression, and generic or missing preview images measurably depress click-through. This addon makes branded share images automatic for all published content, which means a one-time integration effort instead of recurring design time per article. Cost is usage-based and small relative to any design retainer; the trade-off is a third-party dependency that we should scope and price before committing.

To engineering: It is a small, Composer-installable Statamic addon — configuration plus templates, no new infrastructure to operate, no Chrome fleet to keep patched. Evaluate it against your Statamic version, confirm the html2img API key/service tier, and pin the version. Expect to own an image template, a cache/regeneration story for backfills, and error handling for failed renders. Vendor lock-in is low because the surface area is thin; the escape hatch is swapping the render call for Browsershot.

Caveats to state plainly: v1.0.2 is a patch release with no published changelog detail beyond a diff link, so there is no new capability or migration signal here — the strategic posture is unchanged from v1.0.1. Re-evaluate on any minor/major bump or if the project shows signs of maintainer dormancy, and keep a documented fallback path before this becomes load-bearing on a high-traffic property.