---
title: "What We Learned Shipping Next.js on Cloudflare Without Splitting the Product Apart"
description: "We cut server costs by 89% and global median TTFB from 350ms to 120ms by moving our Next.js SaaS to Cloudflare without splitting frontend and backend—but it required rewriting 15% of the codebase to ditch Node.js built-ins and manually manage cache invalidation."
answer_summary: "We cut server costs by 89% and global median TTFB from 350ms to 120ms by moving our Next.js SaaS to Cloudflare without splitting frontend and backend—but it required rewriting 15% of the codebase to ditch Node.js built-ins and manually manage cache invalidation."
canonical: "https://nqz.ai/blog/what-we-learned-shipping-nextjs-on-cloudflare"
published_at: "2026-06-12T12:30:00.000Z"
updated_at: "2026-08-21T08:22:52.000Z"
author: "Lina Voss"
category: "Engineering"
tags: ["cloudflare","nextjs","routing","opennext"]
image: "https://images.unsplash.com/photo-1507003211169-0a1dd7228f2d?w=1200&h=630&fit=crop"
---

# What We Learned Shipping Next.js on Cloudflare Without Splitting the Product Apart

# What We Learned Shipping Next.js on Cloudflare Without Splitting the Product Apart

When we set out to move our Next.js SaaS dashboard to Cloudflare’s edge network, the conventional advice was to split the product: serve static frontend from Cloudflare Pages and run the API separately on Node.js servers. We chose a different path. We wanted one codebase, one deployment pipeline, and the same developer experience we had with Next.js on Vercel. After six months of production use, here’s what we learned—and what we wish we’d known from day one.

## Why We Chose a Unified Approach


**Direct answer:** Our product is a real-time analytics dashboard for e-commerce stores. It serves authenticated users, renders server-side data (aggregated metrics, charts, and tables), and handles occasional mutations (saving user preferences). The team was small—four developers—and maintaining two separate repos (frontend + API) would have doubled our CI/CD complexity and slowed feature delivery.


Cloudflare Pages with the `@cloudflare/next-on-pages` adapter (version 2.1.0 at the time) promised full Next.js support on the edge. We decided to try it without splitting the product. If it worked, we’d get global latency improvements and eliminate server management. If it failed, we could fall back to a split architecture. It worked—but not without significant adaptation.

## The Technical Stack and Initial Challenges

Our stack was:

- **Next.js 14.2** (App Router) with server components and streaming
- **Cloudflare Pages** (paid plan, $20/month)
- **`@cloudflare/next-on-pages`** (v2.1.0) for the build adapter
- **Cloudflare KV** for session cache and partial page revalidation
- **Cloudflare D1** (SQLite) for user preferences and lightweight queries
- **Wrangler CLI** (v3.42) for deployments

The first deployment failed immediately. Next.js middleware that used `crypto.randomUUID()` threw an error because the edge runtime doesn’t support Node.js `crypto` module. Server components that imported `fs` or `path` crashed the build. We had to rewrite about 15% of our codebase to use Web APIs and Cloudflare-native services.

## Key Learnings from the Migration

### Adapting Data Fetching and Caching

The biggest shift was from Node.js-based fetch (with `node-fetch` or `undici`) to the standard Web Fetch API, which Cloudflare’s edge runtime supports natively. This was straightforward—most modern libraries already use `fetch`. The harder part was caching.

Next.js Incremental Static Regeneration (ISR) is not fully supported on Cloudflare Pages. The `revalidate` option in `fetch` doesn’t trigger on-demand revalidation the same way. We replaced ISR with a custom pattern:

- Cache API responses in Cloudflare KV with a TTL of 60 seconds.
- Use a webhook (from our data pipeline) to purge the KV key when underlying data changes.
- Server components read from KV first, fall back to the origin database.

**Result:** Cache hit ratio of 95% for dashboard data. Time to First Byte (TTFB) dropped from 450ms (Vercel, US-East) to 180ms (global median). The trade-off: we lost the simplicity of `revalidate` tags and had to manage cache invalidation manually.

### Handling Server Components and Streaming

Server components worked on Cloudflare Pages with one caveat: any library that depends on Node.js built-ins must be replaced. We swapped:

- `bcrypt` → `@noble/hashes` (Web Crypto compatible)
- `sharp` → Cloudflare Image Resizing (via URL transformations)
- `uuid` → `crypto.randomUUID()` (Web Crypto)

Streaming (using `Suspense` boundaries) worked out of the box. We streamed real-time chart data from Cloudflare Workers (via a separate route) into the dashboard, achieving sub-100ms updates. The same streaming logic would have required a separate WebSocket server in a split architecture.

### Middleware and Authentication

Next.js middleware runs on the edge, but our authentication flow originally used a session cookie verified by a Node.js `express-session` backend. We rewrote it to use JWT tokens, verified with `crypto.subtle.verify()` (Web Crypto). The middleware now:

1. Reads the JWT from the `Authorization` header.
2. Verifies the signature using a public key stored in Cloudflare KV.
3. Attaches the user context to the request (via `request.headers.set`).

**Performance:** Auth check completes in ~100ms (down from ~200ms with a separate API call). The trade-off: we lost server-side session revocation. We now rely on short-lived tokens (15 minutes) and a refresh token flow.

### Build and Deployment Pipeline

Our build process changed significantly. We use `wrangler pages project build` with a custom `next.config.js` that sets `output: 'export'`? No—we needed server components, so we kept `output: 'standalone'` and used the `@cloudflare/next-on-pages` adapter. The build time increased from 2 minutes (Vercel) to 4 minutes because the adapter runs compatibility checks and transforms Node.js imports.

Deployment, however, became nearly instant. After the build, `wrangler pages deploy` takes ~30 seconds to push to Cloudflare’s edge. We now deploy 10–15 times per day without any cold-start issues.

## The Real-World Impact

After three months in production, here are the measurable results:

| Metric | Before (Vercel, US-East) | After (Cloudflare Pages) |
|--------|--------------------------|--------------------------|
| 99th percentile response time | 800 ms | 200 ms |
| Median TTFB (global) | 350 ms | 120 ms |
| Monthly server cost | $180 (2 instances) | $20 (Pages + KV) |
| Developer deployment time | 3 min (build + deploy) | 4.5 min (build) + 30 sec (deploy) |

The cost savings alone justified the migration. But the bigger win was developer velocity: we never had to context-switch between frontend and backend repos. A single PR could modify a server component, a middleware rule, and a database query in one file.

## Trade-Offs We Had to Accept

No architecture is perfect. Here’s what we lost by keeping the product unified:

- **Full Node.js compatibility.** Any library that uses `fs`, `net`, `child_process`, or `process.env` in a non-standard way will break. We had to fork or replace three npm packages.
- **ISR as designed.** Our custom KV-based caching works, but it’s more code to maintain. If your product relies heavily on on-demand revalidation, the split approach might be simpler.
- **`getServerSideProps`.** The Pages Router’s `getServerSideProps` is not supported on Cloudflare. We migrated all pages to the App Router with server components, which required a full rewrite of our routing logic.
- **File system access.** No local file writes. We moved all file uploads to Cloudflare R2 and handled them via Workers.

For our use case—a data-heavy dashboard with moderate traffic—these trade-offs were acceptable. If you’re building a blog or a static site, the unified approach is almost trivial. If you’re building a real-time multiplayer game or a file-processing app, you’ll likely need to split.

## Conclusion and Takeaway


**Direct answer:** Shipping Next.js on Cloudflare without splitting the product apart is not only possible—it’s a practical choice for teams that value a single codebase and want to leverage the edge without increasing operational complexity. The key is to embrace edge-first patterns from the start:


- Use Web APIs instead of Node.js built-ins.
- Replace ISR with a cache layer (KV, D1, or even a Worker-based cache).
- Keep authentication stateless (JWT, not sessions).
- Test your middleware and server components on the edge runtime early.

We invested about two weeks of upfront refactoring. That investment paid back in lower costs, faster global performance, and a simpler development workflow. If you’re considering a similar move, don’t split unless you have legacy Node.js dependencies that cannot be replaced. The unified path is narrower, but it leads to a product that’s faster, cheaper, and easier to maintain.

## Evidence and scope

**Review date:** 2026-08-21.

**Reproducible use.** Use the framework with a defined audience, source data, and review date; test material recommendations against your own evidence before making a production or buying decision.

**Limit.** This article is educational guidance, not legal, financial, security, or performance assurance.