Vercel OG (Satori) Limitations — and What to Use Instead

Vercel OG is elegant: npm i @vercel/og, use Satori in your Next.js API routes, get PNG images. It's built on the same engine as RenderOG (Satori + resvg). But Vercel OG has fundamental architectural limits that make it suboptimal for high-traffic or multi-platform scenarios. RenderOG solves all of them.

The Problem with Vercel OG

1. Cold Starts (Even on Vercel)

Vercel OG runs in Vercel Functions. Each deploy spins up Node, loads Satori/resvg wasm, and renders. First call = 500–2000ms. Subsequent calls (within the same function instance) are faster, but instance pooling is unpredictable.

RenderOG: Wasm initializes once per Cloudflare Worker instance (warm). Cached renders serve in <5ms. Even cold renders (first after a deploy) are 50–150ms. No JS runtime startup cost.

2. Tied to Vercel's Infrastructure

Vercel OG only runs on Vercel. Want to use AWS, Railway, or another host? You need to rewrite your rendering logic or vendor-lock in. The code is portable (Satori is framework-agnostic), but deployment is not.

RenderOG: Pure API. Use from any platform. Renders happen at Cloudflare's edge globally; you call https://api.renderog.app/og?... from anywhere. Zero lock-in.

3. No True Pay-As-You-Go

Vercel OG is "free" while you're on Vercel's free plan, then charges per function invocation ($0.50 per 1M calls, $6 minimum). You pay for compute time, not per image — so a 50ms render costs the same as a 2s render. Overprovisioning is common.

RenderOG: $0.003 per render, no minimum. Cache hits = free. Failures = free. You pay exactly for what succeeds and isn't cached.

4. No Built-In Caching

Vercel OG doesn't cache renders across requests. You control caching yourself (HTTP headers, Redis, etc.). Popular images render repeatedly, wasting compute.

RenderOG: 1-year immutable cache at the edge. Same image, 1 million times? First render counts; rest are free and <5ms. Your compute bill drops by orders of magnitude.

5. Function Timeout Risk

Vercel Functions timeout at 60 seconds (Pro) or 10 seconds (free). A complex render or slow network can timeout, returning 504 to users. RenderOG has no arbitrary timeout — renders finish or fail with clear errors.

6. No Failures-Never-Billed Guarantee

Vercel's compute charges accrue regardless of success. 4xx, 5xx, timeout — you pay. RenderOG explicitly never bills failures. Test designs, debug freely.

Feature Comparison

The RenderOG Advantage

Portable Code, Portable API

Vercel OG is tied to Next.js/Vercel. RenderOG is an HTTP API — call from Next.js, Node, Python, Go, Rust, browser JavaScript, anywhere. Today's "nextjs-only" solution becomes tomorrow's migration headache. RenderOG is future-proof.

Sub-100ms Cached Renders vs. 500ms+ Cold Starts

OG images are immutable. Once rendered, they're cached forever. Vercel OG renders on every request (unless you layer caching); RenderOG renders once and serves globally in <5ms. For high-traffic sites, this difference compounds into massive latency and cost wins.

$0.003/Render vs. $0.50/1M Calls (Min)

Vercel's minimum ($6/month) assumes 12M invocations/month. RenderOG's minimum is zero. Render 10 images/month for free. 1,000/month = $3. No tiers, no waste.

Failures Never Billed

Vercel charges for every function invocation, including failures. RenderOG's core promise: 4xx and 5xx cost zero. Iterate and debug confidently.

Global Edge Cache Out of the Box

Vercel OG requires you to layer on Redis, CDN, or database caching. RenderOG includes 1-year immutable caching by default. Setup is instant; you don't have to architect it.

When Vercel OG is Still Useful

• Embedded in Next.js routes — if you're a Next.js-only shop and need zero external dependencies, @vercel/og is simpler than an API call
• Testing locally — @vercel/og with next dev is easy to iterate on before deploying
• Very low volume — under 100 renders/month, the cost and latency differences don't matter

If you're using Next.js and rendering fewer than 100 images/month, stick with Vercel OG. Otherwise, RenderOG is strictly better.

Migration Path

1. Export your Satori code — your @vercel/og render function is already HTML/JSX; convert to HTML/CSS string (10 min)
2. Test in RenderOG playground — paste your HTML/CSS, tweak if needed
3. Implement signing — swap from inline rendering to HMAC-SHA256 signed URL generation
4. Update Next.js metadata — instead of calling @vercel/og, call our API with a signed URL:

// Before (Vercel OG)
export async function generateImageMetadata({ params }) {
  return [{
    alt: 'My OG',
    type: 'image/png',
    size: { width: 1200, height: 630 },
    url: new URL('/api/og?title=...', baseUrl).toString(),
  }];
}

// After (RenderOG)
export async function generateImageMetadata({ params }) {
  const url = signOGUrl({ title: '...' }); // HMAC-SHA256 signing
  return [{
    alt: 'My OG',
    type: 'image/png',
    size: { width: 1200, height: 630 },
    url,
  }];
}

5. Delete /api/og.ts — no more compute cost for rendering

Most migrations take under 1 hour. Email support@renderog.app for code review.

The Bottom Line

Vercel OG is convenient if you're all-in on Vercel and volume is low. But it's fundamentally limited by cold starts, Vercel lock-in, and per-compute-minute pricing that doesn't align with image value.

RenderOG solves all of these: global edge cache, sub-100ms renders, true pay-as-you-go, and zero lock-in. If you're growing or multi-platform, it's the clear choice.

Most users migrating from Vercel OG see:

• 10–100× faster renders (500ms → 50ms cold, <5ms cached)
• 60–90% cheaper (Vercel $6/month minimum → RenderOG $0 for low volume, or $3–15 for medium)
• Vendor independence — your code and data are yours

Start migrating today →

Paste your Vercel OG HTML, test in the live playground, then go production with an API key and 500 free renders.