DEV Community: Nick Fasulo

Vercel Was Too Expensive, So I Migrated My Next.js App to Cloudflare Workers

Nick Fasulo — Wed, 14 Oct 2026 23:45:44 +0000

I recently moved production traffic for Galaxy Movies, my Next.js movie/TV discovery site, off Vercel and onto Cloudflare Workers. This isn't a Vercel hit piece: Vercel is a great platform, and the app ran happily there for a long time. But I was paying for a Pro plan for what is ultimately a side project, my DNS was already on Cloudflare, and the entire backend surface is fetch-based (Upstash REST, OpenAI, Resend, TMDB); no databases, no TCP. That's about as close to a best-case scenario for running Next.js on workers as you can get.

The site is Next.js 16 Pages Router, React 19, Chakra UI, with ISR catalog pages, a pile of API routes, four Vercel cron jobs, and dynamic OG images via next/og. Here's what the migration actually looked like, including the parts that fought back.

The adapter: @opennextjs/cloudflare
The OpenNext Cloudflare adapter takes a standard next build output and rebundles it into a worker. Setup is two files. First, open-next.config.ts. The interesting bit is the incremental cache override, which points ISR's cache at an R2 bucket:

import { defineCloudflareConfig } from '@opennextjs/cloudflare'

import r2IncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache'

export default defineCloudflareConfig({

  default: { experimentalBundledNextServer: true },

  incrementalCache: r2IncrementalCache

})

Then wrangler.jsonc:

{

  "main": ".open-next/entry.js",

  "name": "galaxy-movies",

  "compatibility_flags": ["nodejs_compat", "global_fetch_strictly_public"],

  "assets": { "directory": ".open-next/assets", "binding": "ASSETS" },

  "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "galaxy-movies" }],

  "r2_buckets": [

    { "binding": "NEXT_INC_CACHE_R2_BUCKET", "bucket_name": "galaxy-movies-inc-cache" }

  ],

  "triggers": { "crons": ["0 6 * * *", "30 6 * * *", "0 7 * * *", "0 16 * * 5"] },

  "find_additional_modules": true,

  "rules": [

    { "type": "Data", "globs": ["public/fonts/**", "public/backdrop_fallback.jpg"], "fallthrough": true }

  ]

}

Deploy is two commands: opennextjs-cloudflare build then wrangler deploy. Everything below is the gap between "two commands" and "actually works in production."

Gotcha 1: Next's dev-only require()s break the bundle
The adapter bundles the Next server with esbuild, and esbuild wants every require() to resolve, including dev-only code paths inside Next's own dist files (next-dev-server, setup-dev-bundler, an upgrade nudge) and an RSC-only path (react-server-dom-webpack) that a Pages Router app never executes. They're dead code in production, but dead code still has to resolve.

I fixed it with patch-package to mark them external in the adapter's bundle step, plus a postbuild script that drops tiny stub modules where the runtime resolution lands:

// scripts/opennext-postbuild.js: runs after opennextjs-cloudflare build

fs.writeFileSync('.../dev/next-dev-server.js', 'module.exports = {}\n')

fs.writeFileSync('.../router-utils/setup-dev-bundler.js', 'module.exports = {}\n')

// ...etc

The patch also adds preview-props.json to the manifest glob the adapter uses, which the Pages Router build emits, and the adapter wasn't collecting. Not elegant, but it's contained in patches/ and reapplied on every npm install by patch-package. If the upstream adapter fixes these, the patch just stops applying cleanly, and I delete it.

Gotcha 2: next/og picks the wrong runtime
This one took the longest. I generate OG images with next/og, which wraps @vercel/og. The library has two entries: a Node build that does readFileSync on a bundled font and calls WebAssembly.instantiate at runtime (both disallowed on workerd), and an edge build that doesn't.

The problem: OpenNext forces NEXT_RUNTIME="nodejs" at bundle time, so next/og always resolves the Node entry, even inside a worker. The workaround is sniffing the runtime myself and importing the edge build directly:

const { ImageResponse } = (await (globalThis.navigator?.userAgent === 'Cloudflare-Workers'

  ? import(/* webpackIgnore: true */ 'next/dist/compiled/@vercel/og/index.edge.js')

  : import('next/og'))) as { ImageResponse: typeof ImageResponseType }

Navigator.userAgent === 'Cloudflare-Workers' is genuinely how you detect workerd. The webpackIgnore comment keeps webpack from trying to bundle the path at build time, and I pin the whole @vercel/og compiled directory into the output via outputFileTracingIncludes in next.config.ts so the edge build and its resvg wasm actually ship.

Gotcha 3: fs reads land in the wrong directory
My OG route also reads custom fonts and a fallback backdrop off disk with readFile(path.join(process.cwd(), 'public', ...)). On Vercel, process.cwd() is the project root. On workerd, the vfs cwd is /bundle (the .open-next output root), so public/fonts doesn't exist where the code looks for it.

The fix is a three-part move: the postbuild script copies public/fonts and backdrop_fallback.jpg into .open-next/public/, and wrangler's find_additional_modules + the Data rules in wrangler.jsonc ship those files in the worker's virtual filesystem. Same code path, files just exist where the worker looks.

Gotcha 4: packages hiding behind the workerd export condition
Some packages, in my case @emotion/* (Chakra's styling engine) and uncrypto, publish their ESM builds behind a workerd export condition. Next's file tracer only follows the CJS variants, so the worker bundle ends up with nothing it can resolve for those imports.

The fix is listing them in serverExternalPackages in next.config.ts, which tells the adapter to copy the packages whole instead of relying on tracing:

serverExternalPackages: [

  '@emotion/react', '@emotion/cache', '@emotion/serialize',

  '@emotion/sheet', '@emotion/weak-memoize', '@emotion/hash',

  '@emotion/memoize', '@emotion/unitless', '@emotion/utils',

  '@emotion/use-insertion-effect-with-fallbacks',

  'hoist-non-react-statics', 'uncrypto'

]

If you hit "cannot resolve module" errors on workerd that don't reproduce locally, this is the first thing to check.

Gotcha 5: Vercel crons don't exist on Workers
vercel.json crons are a Vercel platform feature; nothing in a Next.js build output describes them. On Workers the equivalent is triggers.crons + a scheduled() handler. But the adapter generates worker.js, so I wrap it in a custom entry that adds the handler and maps each cron expression back to the same endpoint Vercel used to hit:

// .open-next/entry.js, written by the postbuild script

import worker from './worker.js'

const CRON_ROUTES = {

  '0 6 * * *': '/api/cron/generate-content',

  '30 6 * * *': '/api/cron/streaming-changes',

  '0 7 * * *': '/api/cron/watchlist-alerts',

  '0 16 * * 5': '/api/cron/weekly-digest'

}

export default {

  ...worker,

  async scheduled(event, env, ctx) {

    const route = CRON_ROUTES[event.cron]

    if (!route) return

    ctx.waitUntil(

      env.WORKER_SELF_REFERENCE.fetch(

        new Request('https://worker.internal' + route, {

          headers: { authorization: 'Bearer ' + env.CRON_SECRET }

        })

      )

    )

  }

}

Two things make this nice. The WORKER_SELF_REFERENCE service binding lets the worker call itself as an internal fetch, no public round trip. And the endpoints needed zero changes: they already checked Authorization: Bearer $CRON_SECRET because that's how Vercel's cron caller authenticates too. Testing is wrangler dev --test-scheduled, then hit /__scheduled?cron=0 6 * * *.

Secrets
wrangler secret bulk takes a JSON file, so a 20-line script converts .env.local into .secrets.json, skipping NEXT_PUBLIC_* vars (those get inlined at build time anyway) and my local Cloudflare API token. npm run cf:secrets and done: no dashboard clicking through a dozen vars.

Cutover and rollback
The safest part of the whole migration was the cutover itself, because I deliberately ran both platforms in parallel:

npm run cf:deploy, then verify everything on the *.workers.dev URL (all routes, OG images, cron triggers registered).
Attach the galaxymovies.app + www custom domains to the worker. Since DNS was already on Cloudflare, this was instant, no propagation wait.
Keep Vercel as cold standby: git.deploymentEnabled.main: false in vercel.json stops main pushes from auto-deploying, and I disabled the Vercel crons in the dashboard so the two platforms don't double-fire jobs.

Rollback is re-adding two DNS records (A to Vercel's anycast IP, CNAME www to the Vercel DNS name). Traffic flips back immediately because the worker custom domains only take precedence while they're the only records on those names. That escape hatch made the whole thing low-stress: worst case is a DNS edit, not a redeploy.

What's actually running
Same codebase, same next build, no platform fork in the source. SSR, ISR (backed by R2), all API routes, the OG image route, and all four crons work identically to how they did on Vercel. The only code that knows which platform it's on is that one navigator.userAgent check in the OG route.

The honest summary: the adapter gets you ~80% there out of the box, and the remaining 20% is the kind of platform-shim work above. It's tractable, but expect an afternoon of debugging, not a lunch break. If your app leans on Node APIs that aren't fetch-shaped, the logic is different. But if you're already edge-friendly and your DNS is on Cloudflare anyway, the economics are hard to argue with, and Vercel sitting dormant as a free rollback target is a pretty nice safety net.

Repo notes worth taking if you're doing this: patch-package for the adapter externals, a postbuild script for stubs + vfs assets + the cron entry, serverExternalPackages for workerd-conditioned packages, and wrangler dev --test-scheduled for cron testing.

Happy to answer questions in the comments!

My side project's free tiers were dying, so I counted what each service actually bills

Nick Fasulo — Thu, 08 Oct 2026 22:41:27 +0000

Galaxy Movies is a movie discovery side project ~ Next.js Pages Router on Vercel, TMDB for data, Upstash Redis for caching & rate limiting, and OpenAI for a chat assistant & generated synopses. Everything runs on free tiers, which is the whole point of a side project.

A few weeks ago all three of those free tiers started groaning at once. Vercel function usage was climbing, Upstash was burning through its daily command quota well before midnight, and OpenAI spend had a suspicious correlation with traffic spikes that produced no actual readers.

The fixes all came down to the same realization: every "free" tier bills a different unit, and I was counting the wrong things. Here's what was actually billing me, and what I changed.

Act 1: The bots were running up my function bill

Vercel bills function duration, and my movie and TV detail pages were expensive: five parallel TMDB fetches (title, watch providers, credits, ratings, recommendations), plus Redis reads for the AI content slots, all in getServerSideProps.

The expensive traffic wasn't humans. SEO crawlers and AI scrapers sweep the entire TMDB ID space in bulk, and every one of those detail pages ran the full fetch chain. They don't index anything and send zero readers. Pure cost.

The fix was a thin render path just for them:

// Bots that don't index get a minimal render. They sweep the TMDB id
// space in bulk and don't need providers, credits, videos, or AI slots.
if (isBot(ua) && !isSearchEngine(ua)) {
  const titleRes = await fetch(`https://api.themoviedb.org/3/${media}/${id}?api_key=${apiKey}`)
  // on failure return notFound or errorProps; otherwise:
  context.res.setHeader('Cache-Control', 'private, no-store')
  return { props: { ...thinProps, media, title, topCast: [] } }
}

Two details matter here:

The isSearchEngine split. isBot matches a broad allowlist, but Googlebot, Bingbot, and DuckDuckGo still get the full render since they index. Social preview bots get the thin version. Whether a bot indexes is the only question that matters.
private, no-store is critical. If the stripped page entered the shared CDN cache, a cache collision could serve the bot version to a human, or worse, to Googlebot. Cheap responses must never contaminate the real cache.

I also found robots.txt was being rendered by a Next.js page, which meant every crawler's very first request was a function invocation. It moved to a static public/robots.txt, which doubles as an enforcement layer:

User-agent: AhrefsBot
User-agent: SemrushBot
User-agent: MJ12bot
User-agent: Bytespider
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
# ...several more
Disallow: /

Yes, Disallow is an honor system, but the big commercial crawlers honor it, and they were most of the volume.

Finally, I lengthened the SSR CDN cache windows: s-maxage from 1 hour to 1 day, stale-while-revalidate from 1 day to 1 week. Repeat crawler hits on popular titles now terminate at the edge instead of running SSR again.

Act 2: Upstash bills every single Redis command

This one caught me off guard. Upstash's free tier bills per command, and a pipeline doesn't save you, because each member of a pipeline is its own billed command. My request paths fanned out into Redis calls that felt free because "Redis is fast."

The audit turned up some embarrassing finds. Cache reads on detail pages were ~97% misses, so I was paying a billed command for a null almost every time. Rate limiting cost up to three commands per check. A dataset updated once a day was being fetched again on every pageview.

The fixes, roughly in order of satisfaction:

Rate limiting became one Lua script. INCRBY plus a conditional EXPIRE plus a TTL recovery check run inside a single EVAL, billed once no matter how many redis.call()s it makes:

local count = redis.call("INCRBY", KEYS[1], ARGV[1])
if count <= tonumber(ARGV[1]) then
  redis.call("EXPIRE", KEYS[1], ARGV[2])
elseif count > tonumber(ARGV[3]) and redis.call("TTL", KEYS[1]) < 0 then
  redis.call("EXPIRE", KEYS[1], ARGV[2])
end
return count

The TTL check handles a real edge case: if a key somehow loses its expiry, a blocked client fixes it on the next attempt instead of being rate limited forever.

Check caches before paying the rate limit write. /api/prices was rate limiting requests that would have been cache hits, paying a write before doing a read. Reorder, and every cache hit is one command instead of two.

Memoize what changes daily. The streaming-changes diffs are rewritten once a day by cron but were being fetched per key on every pageview. A per instance LRU holding results for ten minutes turns repeat page loads into zero Redis commands:

const changesMemo = new LRUCache<string, Record<string, ProviderChanges>>({ max: 64, ttl: 10 * 60 * 1000 })

export async function getProviderChanges(providerKeys = [], { fresh = false } = {}) {
  const memoKey = [...providerKeys].sort().join(',')
  if (!fresh) {
    const memoized = changesMemo.get(memoKey)
    if (memoized) return memoized
  }
  // ...Redis reads, then changesMemo.set(memoKey, changes)
}

The fresh flag exists because the cron itself must never match subscribers against a diff it just replaced. Memoization that's correct most of the time is a bug with extra steps.

Batch the counters. Every HINCRBY is billed, so AI usage and analytics deltas accumulate in a Map and flush every 30 seconds (or 50 fields). Stats lag by up to half a minute and a dying instance loses its unflushed tail, a fine trade for telemetry.

Restructure data to match access patterns. Detail pages fetch both AI content slots in one MGET instead of two GETs. Generated lists moved from one key per slug into a single hash, where HGETALL is one command replacing an unbounded key fanout.

Net result: roughly half the daily command volume, with quota headroom for the first time in weeks.

Act 3: OpenAI spend, or "why is a scraper generating my content?"

The AI features on detail pages (generated synopses, similar title blurbs) trigger an OpenAI call on a cache miss. Guess who was causing cache misses at scale: the same scrapers from Act 1. Bots were literally generating my content.

So bots got read only access: they can consume AI content that's already cached but can never trigger generation (generate: false on the cache lookup). Human traffic is unaffected; scraper sweeps now cost zero tokens.

The other fixes were less dramatic but added up:

Failed cron seeds stopped retrying forever. A broken seed now records failed with an attempt counter and gives up after 3 tries, instead of burning a discover call on every daily run until the heat death of the universe.
Longer cache TTLs. Reviews and similar titles are static per title, so 365 day TTLs mean one generation per title, ever.
Prompt dieting. Similar title prompts dropped to 6 candidates with 200 character overviews; editorial prompts got explicit word budgets; structured JSON output removed the "please don't ramble" tax.
Shared chat cache. Identical chat requests (quick actions, common first questions; the bulk of traffic) now hit a Redis cache shared across instances, plus tighter limits: 10/hr per IP, 1000/day global.
Per task model control. All OpenAI calls route through one module with per task reasoning_effort: none for latency sensitive tasks, low only for the discover generator. Real token usage gets logged so I can see where spend actually goes.

The kill switch

The scariest scenario isn't gradual spend. It's a quota or billing problem silently converting every request into an error, or worse, into retry storms. Billing and auth failures (401/402, insufficient_quota) now trip a shared kill switch with a one hour cooldown:

export function isQuotaError(err: unknown): boolean {
  if (!(err instanceof OpenAI.APIError)) return false
  if (err.status === 401 || err.status === 402) return true
  const code = err.code || err.error?.code
  return code === 'insufficient_quota'
      || code === 'billing_hard_limit_reached'
      || code === 'billing_not_active'
}

While it's tripped: /api/chat returns 503 { code: 'ai_unavailable' } before spending budget, the chat widget checks /api/aiStatus on mount and hides itself entirely instead of showing an error bubble, the generators skip their calls, and the content cron skips the run without burning seed attempts, since an outage isn't a seed's fault. Crucially, ordinary 429 rate_limit_exceeded errors don't trip it; those are transient.

One deliberate choice throughout: degrade in the direction that saves money. When Redis errors on a check that protects spend, the code falls back to a per instance limiter and never fails open. An in memory limiter might be less accurate, but a Redis outage can't be used to run up my OpenAI bill.

The part where I broke things

Honest bookkeeping: the cost cuts shipped two bugs worth their own paragraph.

After moving the chat cache to Redis, identical requests started hitting on every quick action prompt, and the cache hit path returned plain JSON that the SSE client never parsed. Cache hits went from "the fast path" to "the broken path" overnight. Fix: return cache hits through the SSE stream like everything else.

And when bots stopped triggering AI generation, Lighthouse CI got caught in the crossfire. It audits the real detail pages, and its UA matched the bot list, so it was suddenly measuring the thin render. Chrome-Lighthouse went on the search engine side of the check.

Both bugs were the same shape: a filter added at the edge changed behavior for a consumer I forgot about. If your bot detection doesn't have a list of legitimate automated consumers, it will find one for you. In production. On a Sunday.

What I'd tell past me

Count the billed unit, not the abstraction. "Redis call," "function invocation," and "API request" are all wrong. It's commands, gigabyte seconds, and tokens, and the gap between what I thought I was spending and what I was billed lived entirely inside that distinction.
Segment bots by whether they index, not whether they're bots. That one boolean decided which requests deserved the expensive render, the Redis reads, and the cacheable output.
Cache at the cheapest layer that works. CDN edge > shared Redis > per instance LRU > regenerate. I had requests traversing the whole hierarchy when a static file would do (looking at you, robots.txt).
Free tier quotas are architecture constraints, not billing details. "A few Redis commands per request is fine" is a statement that only survives until you do the multiplication.
Instrument spend itself. The usage counters I added to survive the Upstash quota are now how I watch OpenAI costs. The fix for a quota crisis becomes your observability for the next one.

The site is galaxymovies.app if you want to see the thin renders in the wild. View source as a human, please; the bots are expensive enough. Happy to compare notes in the comments if you've fought the same free tier math!

I Added a Chatbot to My Movie Discovery App

Nick Fasulo — Sat, 03 Oct 2026 23:17:00 +0000

I recently added a chatbot feature to Galaxy Movies, my movie discovery app.

The idea came from a problem I run into all the time: there are too many movies to choose from, and browsing doesn’t always help.

You can scroll through trending lists, genres, ratings, and streaming options, but sometimes what you really want is to ask a simple question: “What should I watch tonight?”

So I built Galaxy Bot.

Galaxy Bot is a conversational movie assistant that helps users find movies based on what they actually want in the moment. Instead of only relying on filters, users can describe their mood, who they’re watching with, how much time they have, or what kind of movie they’re trying to avoid.

Some example prompts:

“Recommend a feel-good movie under two hours.”
“I want a sci-fi movie that isn’t too confusing.”
“What should I watch with my family?”
“Give me something tense but not horror.”

The main thing I focused on was making the chatbot feel useful without getting in the way. It should make discovery faster, not make the app feel heavier.

This first version is about helping users get unstuck when they don’t know what to watch. Over time, I’d like to make it better at understanding taste, saved movies, ratings, and streaming availability.

You can check it out here: Galaxy Movies

How I Built an Ultra-Fast Movie Discovery App with Next.js, Edge Runtime, and OpenAI

Nick Fasulo — Thu, 24 Sep 2026 16:46:50 +0000

The Problem

Finding something to watch shouldn't feel like a chore. Legacy movie sites are often weighed down by heavy ads, sluggish page transitions, and buried streaming links. I wanted a tool that got straight to the point: instant search, immediate streaming availability, and quick, objective AI synopses.

So, I solo-developed Galaxy Movies.

Live Demo: https://www.galaxymovies.app/

GitHub: https://github.com/NickFasulo/galaxy-movies

Key Features

Lightning-Fast Search: Browse thousands of titles and explore cast networks in a clean, cosmic dark-mode UI.

One-Click Streaming Check: Instantly view exact platform availability (where to stream, rent, or buy) without jumping through menus.

Instant AI Synopses: Concise, objective film overviews powered by OpenAI to give quick context before pressing play.

Dynamic OG Cards: Social share preview cards rendered on the fly with custom branding.

Tech Stack & Architecture Highlights

Frontend: Next.js (Pages Router) + Chakra UI
State & Data: React Query + TMDB API
Edge & AI Services: Vercel Edge Runtime (@vercel/og) + OpenAI API
Quality Assurance: Lighthouse CI

Dynamic Social Cards on Vercel Edge Runtime: Built dynamic Open Graph image generation using @vercel/og. Requests parse title and poster data on Edge functions to serve custom social cards with sub-100ms response times.
TMDB Image Optimization Bypass: Direct-to-CDN poster loading to bypass server image transformation limits while maintaining high performance.
Automated Quality Checks: Integrated Lighthouse CI to enforce performance, accessibility, and SEO thresholds on builds.