Laravel Open Graph Image Laravel Package

Product Decisions This Supports

• Social/ OG share cards as a growth lever: Dynamic, per-page Open Graph images improve click-through on shares in Slack, X, LinkedIn, WhatsApp, Discord. This is a marketing/awareness bet, not core product logic — treat it as an acquisition/conversion investment with measurable lift (share CTR, referral traffic).
• Build vs buy: The package covers Laravel-native routing, templating (Blade views for the card), caching, and now pre-generation. Buying (adopting) beats building a Browsershot/Puppeteer + S3 + cache-invalidation pipeline unless you need a non-Laravel runtime, video/animated cards, or designer-owned templates without deploys.
• v1.4.0 — og-image:warm de-risks launch moments: Social crawlers (X, Facebook, LinkedIn) time out fast and often don't retry. On-demand generation on first crawl is a cold-start gamble. A warm command lets you pre-generate at deploy time or on a schedule, so a campaign launch, product drop, or press push doesn't ship broken share previews.
• v1.4.0 — Larastan/PHPStan boot support: Lowers adoption friction for teams with strict CI (level 6+ static analysis). This is a "does it fit our engineering standards" checkbox that shortens the buy decision and reduces the maintenance tax of a package that renders views the analyser couldn't previously see.
• Roadmap fit — programmatic SEO at scale: Pairs naturally with sitemap-driven content (blog posts, listings, docs, changelog entries) where each URL needs a distinct card. The warm command makes "generate cards for all N pages" a schedulable job rather than an unplanned spike on first share.
• Operational decisions this forces (good — decide them deliberately): cache TTL and invalidation triggers (regenerate on content publish vs. fixed TTL), storage/CPU budget for warming N pages, and whether warming runs inline in deploy or as a queued/rate-limited job.
• Multi-tenant / white-label SaaS: Per-tenant branding in cards is a plausible premium-tier differentiator, but confirm per-tenant templates and cache keying before committing it to a roadmap.

When to Consider This Package

Consider it when:

• You're on Laravel/PHP and want share images generated from Blade templates you already know, not a separate Node/Puppeteer stack.
• You have many pages needing unique cards (posts, products, listings, docs) and want pre-generation rather than per-request rendering.
• Your CI enforces PHPStan/Larastan, and you want a package that analyses cleanly rather than one you must baseline-ignore.
• You need scheduled pre-warming before a launch or campaign, or after content bulk-import.
• You want the image pipeline inside the app — same auth, config, deployment, and observability as the rest of your Laravel code.

Look elsewhere when:

• You're not on Laravel (or on a non-PHP runtime, edge/serverless renderer).
• You need animated/video OG assets, or client-side canvas generation.
• Card design must be owned by designers/marketers without deploys — a hosted design tool with template editing will beat code-defined views.
• You're at very high card volume with strict latency, where edge generation or a dedicated image CDN is the better architecture.
• You need guaranteed rendering fidelity across exotic fonts/emoji/CSS that headless-browser pipelines handle more predictably; validate your actual template first.

How to Pitch It (Stakeholders)

For executives (one paragraph): Every link our users share is a free ad — and right now most of ours render as a grey placeholder. This Laravel package generates branded, per-page share images automatically, and the new release adds a command to pre-build them for every page before we launch, so previews never fail when a crawler or journalist hits us. Cost is a small amount of compute and storage; the upside is measurable click-through on shared links, at essentially zero per-share marginal cost. It's a contained, reversible adoption — no new vendor, no new stack, no data exposure.

For engineering leads (the short version): Laravel-native OG image generation via Blade views, with caching. v1.4.0 gives us (a) og-image:warm to bulk pre-generate — wire it into deploy or the scheduler so social crawlers never trigger a cold render, and (b) Larastan bootstrapping so the package's views are visible to PHPStan and don't need to be excluded from analysis. Adoption is a composer require plus a route/template; the real work is deciding cache TTL, invalidation-on-publish, and how to bound the warm job (queue it, chunk it, and skip unchanged pages) so a 10k-page site doesn't turn a deploy into a CPU spike.

Ask: a one-sprint spike — template one high-value page type, measure render time, and decide warm-job scheduling and cache strategy before we commit it to the launch checklist.