Generating social share images at the edge

When you paste a link into a message, a social post, or a chat, the rich preview that appears — the card with a title, a description, and an image — is driven by Open Graph metadata, and the image in that card is the OG image. For a site with a handful of pages, you can make those images by hand. For a site with hundreds of blog posts and docs across multiple products, hand-making a share image for every page is not a real option, and shipping the same generic image for all of them makes every link look identical and untrustworthy. novusstreamsolutions.com solves this by generating each page's share image on demand, at the edge, from the page's own data. No one exports an image; the card builds itself. This post is about how that works and why dynamic generation is the right call for a multi-product content site.

The short version: there is an image route that takes a page's title and description as parameters and renders a branded card as an actual image, executed at the edge so it is fast and close to whoever requested it. Each blog post and doc points its OG metadata at that route with its own title and excerpt, so every page automatically gets a unique, correct, on-brand preview without a static file existing anywhere. The image is a function of the page, computed when it is needed.

Static OG images fail a multi-product content site in two directions. If you make one shared image and use it everywhere, every link to every post looks the same in a feed — same picture for a background-remover deep-dive and a visualizer tutorial — which is both visually monotonous and a weak trust signal, because a thoughtful preview is part of how a link earns a click. If you instead try to make a bespoke image per page, you have signed up for an unbounded manual chore: every new post needs someone to open a design tool, lay out a card, export it at the right dimensions, and wire it up, and every title edit means redoing the image. Neither option scales. The first sacrifices quality; the second sacrifices the maintainer's time, which for a solo operation is the scarcer resource.

The deeper issue is that a static image is a copy of information that already exists elsewhere. The page already has a title and a description; a static OG image is a hand-made duplicate of that text baked into a picture, which means it can drift out of sync the moment the title changes and nobody remembers to regenerate the image. Any time you are manually maintaining a copy of data that the system already has, you have found a thing that should be derived automatically rather than maintained by hand.

The dynamic approach treats the share card as a derived artifact, computed from the page's real data rather than stored. The image route is a small piece of code that accepts parameters — a title, a description, a channel label that marks whether it is a blog post or a doc — and lays them out into a branded card that it renders as an image at request time. Each post's metadata is generated from the same typed post object that drives the page itself: the post's title becomes the card's headline, its excerpt becomes the card's description, and the route turns those into the picture. Because the card is built from the post data, it is correct by construction and can never drift, because there is no separate copy to drift — change the post's title and the next time the card is requested it reflects the new title automatically.

Running this at the edge matters for the same reason it matters for any request: the image is generated on infrastructure close to whoever asked for it, so the preview that a platform fetches when someone shares a link comes back quickly rather than from a single distant origin. And because the route generates on demand, there is no build-time cost of pre-rendering thousands of images and no storage of thousands of files — the card for a given page exists only as the ability to compute it, materialized when a platform actually requests the preview. The site ships the recipe, not the cake, and bakes each card the moment it is ordered.

It is worth grounding the discussion in what Open Graph metadata is, because the share card is a more consequential surface than it first appears. When a link is pasted into a social platform, a messaging app, or a chat, that service fetches the page and reads its Open Graph tags — a title, a description, and crucially an image — to build the rich preview card that appears in place of the bare URL. That card is often the first and sometimes the only impression a potential reader gets of the page before deciding whether to click, which makes it a real part of how a link performs. A compelling, specific card earns clicks; a generic or broken one is ignored.

This is why the image in that card is worth automating rather than neglecting. For a content property whose links are shared, the share card is a piece of the distribution, not a technicality — it is the page advertising itself in feeds and conversations. A site that ships the same generic image for every link looks monotonous and untrustworthy in a feed, undercutting the reach its content deserves, while a site where every link gets a distinct, on-brand, accurate card looks considered and earns engagement. Understanding that Open Graph metadata drives the actual first impression of a shared link is what justifies treating the share image as something worth generating correctly for every page rather than an afterthought to be handled with one static file.

Generating the share image at the edge — on infrastructure distributed close to wherever the request originates — is a deliberate performance choice, and the reason it matters is the timing of when these images are fetched. When someone shares a link, the platform fetches the Open Graph image right then, often while a person is waiting to see their pasted link resolve into a card, so the speed of that fetch affects whether the card appears promptly or laggily. Rendering at the edge means the image is produced near the requester rather than at a single distant origin, so the round-trip is short and the card materializes quickly regardless of where in the world the share happened.

Edge execution also suits the on-demand nature of the generation. Because the image is computed when requested rather than pre-built, doing that computation at a distributed edge location keeps it fast everywhere rather than fast only near a central server. This is the same performance instinct applied throughout the stack — do the work close to the user and only when needed — and for share cards specifically it ensures the generation's on-demand flexibility does not come at the cost of slow previews. The combination of generating on demand, so there is no storage or staleness, and generating at the edge, so it is fast everywhere, is what makes dynamic share cards practical at the scale of a large content site rather than a clever idea that would be too slow to actually use.

The share-image approach is the clearest expression of a principle that runs through the whole stack: prefer deriving an artifact from your real data over maintaining a separate copy of it. A static share image is a hand-made duplicate of the page's title and description, baked into a picture — which means it is a copy that can fall out of sync the moment the source changes and nobody remembers to regenerate it. Deriving the card from the post's own title and excerpt at request time means there is no copy to drift, because the card is computed from the source every time it is needed. Correctness is structural: the card cannot disagree with the page, because it is a function of the page.

This derive-don't-duplicate instinct is worth recognizing as a general design heuristic, because the opportunities to apply it are everywhere once you look. Any time you find yourself manually keeping one thing in sync with another that the system already knows, you have found a candidate to derive instead — the manual sync is work you can delete and a drift you can eliminate by computing the dependent thing from the source. The share image, the sitemap generated from the content data, the valid-slug type derived from the real docs — these are all the same move applied to different artifacts. Maintaining copies is a recurring tax and a recurring source of bugs; deriving from the source removes both, which is why the stack reaches for derivation wherever an artifact can be computed from data that already exists.

A reasonable concern about generating images on demand is whether computing them repeatedly is wasteful, and the answer is that caching makes the on-demand model both efficient and fresh. The first time a given page's card is requested, it is computed; after that, the result can be cached so subsequent requests for the same card are served from the cache rather than recomputed. Since a given page's title and description change rarely, its card is computed once and then served cheaply many times, which means the on-demand approach does not pay a recomputation cost on every share — it pays once and caches, getting the freshness of on-demand with most of the efficiency of static.

This caching is what resolves the apparent tension between dynamic generation and performance. Pure recomputation on every request would be wasteful for content that rarely changes; pure static pre-generation would mean building and storing thousands of images that may never be requested and that go stale when titles change. Caching on-demand generation takes the best of both: cards exist only as the ability to compute them, are generated only when actually requested, and are then cached so repeat requests are fast, with the cache naturally refreshing when the underlying page changes and the card is regenerated. The result is an approach that is both efficient and always correct, which is why on-demand generation at the edge, backed by caching, is practical at the scale of a large content site rather than a clever idea that would be too expensive to run.

A structural benefit of generating every share card from a single route is that the brand styling of every card across the entire ecosystem is defined in exactly one place. The layout, the colors, the typography, the logo treatment of the card — all of it lives in the one image route that every page points at, which means there is no per-page card design to keep consistent and no opportunity for cards to drift apart in style. Every link to every post, across hundreds of pages and multiple products, gets a card that shares the same brand language because they are all produced by the same code.

This centralization is what makes brand consistency across a large card surface effortless rather than a maintenance burden. With hand-made cards, keeping hundreds of share images on-brand would require designing each to match and re-doing them all when the brand evolves — an unbounded chore. With one generating route, the entire ecosystem's share cards are restyled by changing the route once, and every page's card updates the next time it is requested, automatically. A feed full of links to the site looks like a coherent, considered brand because the cards are not independently designed but centrally generated from one definition. For a multi-product hub trying to present a unified brand across a large and growing set of pages, that single-source styling is exactly the kind of automatic consistency that a solo operator could not maintain by hand.

The economics of dynamic share-card generation are worth examining, because they are part of why it suits this stack rather than being an extravagance. On-demand generation means no build-time cost of pre-rendering thousands of images and no storage of thousands of files — the only cost is computing a card when one is actually requested, which happens when someone shares a link, not on every page build or page view. Most pages are shared far less often than they are built or viewed, so generating cards only on actual share requests, and caching the results, keeps the total computation modest and proportional to real sharing activity rather than to the size of the catalog.

This cost model scales gracefully as the content grows, which a static approach does not. A static-image approach pays to generate and store a card for every page whether or not it is ever shared, so its cost grows with the catalog size regardless of usage; the on-demand approach pays only for cards that are actually requested, so its cost grows with sharing activity, which is the thing that actually matters. For a site that may have hundreds or thousands of pages, most of which are shared rarely, paying only for the cards that are genuinely needed is dramatically more efficient than pre-building all of them. The cost model — compute on demand, cache the result, pay proportional to real use — is what lets dynamic generation scale to a large catalog without the cost or storage burden that pre-rendering everything would impose.

Dynamic OG generation earns its keep most clearly on exactly this kind of site: many pages, multiple products, one brand. The per-page uniqueness means a link to any post anywhere in the catalog gets a card that reflects that specific post, so a feed full of Novus links looks like a coherent set of distinct, considered pages rather than one image repeated. The channel label lets a doc page and a blog post be visually distinguished while staying on-brand, which helps a reader know what kind of page they are about to open. And the single shared route means the brand styling of every card in the entire ecosystem is defined in one place — change the card design once and every page's preview updates, across hundreds of posts, with no per-page work. For a multi-product hub trying to look consistent and trustworthy across a large surface, that centralized, automatic consistency is precisely the property you want.

The broader pattern is the one worth taking away: prefer deriving artifacts from your real data over maintaining copies of it. The OG image is the same insight as the type-safe content guardrails from a different angle — the system already knows the page's title and description, so the share card should be computed from them, not hand-built alongside them. Anything you find yourself manually keeping in sync with data the system already has is a candidate to be derived instead, and deriving it removes both the work and the drift. The typed post data already powers the page; here it powers the page's share card too, for free.