Next.js Memory Leak: Fetch + Standalone Mode — 2 Years Without a Fix

TL;DR

Next.js patches the global fetch and adds a cache layer that holds references to response data after they should have been freed. Every fetch call adds memory that is never returned to GC. In Docker/Kubernetes this leads to OOM crashes every few hours. The bug has existed since Next.js 14 (April 2024) and is still unresolved in 16.2.x (March 2026). On Vercel the problem doesn't manifest due to ephemeral serverless functions.

How Normal Fetch Works

Request → fetch → got data → response to user → GC cleans up → memory free

How Fetch Works in Next.js

Next.js intercepts the global fetch and wraps it with its own cache/tracking layer:

Request → Next.js fetch wrapper → creates:
  - Performance entry (speed tracking)    ← not cleaned
  - Request metadata object               ← not cleaned
  - Internal promise wrapper              ← not cleaned
  - Cache lookup entry                    ← not cleaned
  - Response body (for unique URL)        ← not cleaned
→ Response to user
→ GC sees objects are still referenced → doesn't touch them
→ Memory grows indefinitely

What Happens in Production

Self-hosted (Docker/K8s):
  Request 1:      fetch → +100KB → RAM: 100KB
  Request 2:      fetch → +100KB → RAM: 200KB
  Request 1000:   fetch → +100KB → RAM: 100MB
  Request 50,000: fetch → +100KB → RAM: 5GB → OOM Kill 💀
  → Kubernetes restarts the pod → cycle repeats

Vercel (Serverless):
  Request 1: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  Request 2: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  → Memory never accumulates

Affected Versions

Next.js — All Versions with App Router

Node.js

Tested on Node.js 20, 22, 24, 25 — leaks on all of them.

What Doesn't Work

What Works (Workarounds)

Axios Workaround Limitation

Your own API calls can be replaced with axios. But Next.js internally uses the patched fetch for:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• Server Components data fetching with deduplication
• use cache (Next.js 16)

Even without a single fetch in your code — Next.js still uses it under the hood.

Why Vercel Doesn't Fix It

Business Logic

Vercel is a company that makes money hosting Next.js. On their platform the problem doesn't manifest (serverless = ephemeral). The bug only affects self-hosted (Docker, K8s, VPS) — those who don't pay Vercel.

Official Position

Tim Neutkens (Vercel maintainer) analyzed the issue and declared it a problem with undici (Node.js fetch library), not Next.js. Issue #90433 was closed. Despite the fact that:

• axios and node-fetch on the same Node.js work without leaks
• The leak only appears when fetch goes through the Next.js wrapper
• The bug has been open for 2 years without a fix

Priorities

In these 2 years the Next.js team shipped:

• Turbopack (2-5x faster builds) — marketing advantage
• Cache Components / use cache — reduces load on Vercel servers
• proxy.ts instead of middleware — simplifies edge deployment on Vercel
• DevTools MCP — AI hype

Memory leak in self-hosted? Not a priority.

Solution: AWS Lambda (SST + OpenNext)

What Is It

OpenNext is an open-source adapter that converts a Next.js build into a format for AWS Lambda. SST is a framework that automates the infrastructure.

Architecture

Next.js build
  → OpenNext
    → AWS Lambda (SSR, API routes)
    → S3 (static, assets)
    → CloudFront (CDN)
    → SQS + DynamoDB (ISR revalidation)

Why This Solves the Memory Leak

Lambda functions process requests and are recycled after 5-15 minutes of inactivity. Memory doesn't have time to accumulate.

Deploy

npx sst@latest init
npx sst deploy --stage production

Comparison

Lambda Nuances

• Cold starts — first request is slower (~200-500ms)
• Security — enable OAC (Origin Access Control), otherwise Lambda URL is public
• OpenNext — community project, not official Vercel. New Next.js features may break
• Wallet attack — during DDoS, Lambda auto-scaling can lead to a large bill

Why a Real Fix Is Unrealistic

1. Architectural Problem

The leak is not an accidental bug but a consequence of a design decision: Next.js intercepts the global fetch and adds cache/tracking on top. To fix it — the way App Router interacts with fetch needs to be redesigned. This affects ISR, revalidation, data cache, request deduplication — the framework's core.

2. Conflict of Interest

Vercel is not motivated to fix what doesn't affect their platform. Self-hosted competes with their business. The more problems in self-hosted — the more people migrate to Vercel.

3. Blame Shifting

The official position is "it's undici, not us". Until this changes — they won't work on a fix.

4. No Community Fix

Next.js AGPL-3.0 license allows forks, but the codebase is massive and tightly coupled with Vercel infrastructure. A community PR to fix the fetch wrapper would require deep understanding of the internal architecture and approval from maintainers — who already closed the issue.

Conclusions

1. If on Vercel — no problem, nothing to do
2. If self-hosted and need serverless — SST + OpenNext on AWS Lambda
3. If self-hosted Docker — replace fetch with axios where possible, monitor RAM, set up automatic pod restarts
4. If starting a new project — consider SvelteKit or Nuxt as alternatives without this problem

Sources

• Issue #64212 — Memory Leak with global fetch (April 2024)
• Issue #68578 — Possible memory leak in Fetch API (August 2024)
• Issue #85914 — Memory Leak with fetch + standalone (November 2025)
• Issue #90433 — OOM in 16.0.10 (February 2026)
• Discussion #88603 — OOM in Docker/K8s (January 2026)
• Discussion #88078 — cacheMaxMemorySize behavior
• OpenNext
• SST — Next.js on AWS
• Secret knowledge to self-host Next.js
• Next.js Memory Usage Guide