[BUG] No support for `proxy.js` in Cloudflare Workers

[incognitotgt]

Describe the bug

When I try to deploy a project with a proxy.js file, it gives an error that Node.js middleware isn't currently supported. This is even though the file is supposed to be edge unless a Node API is used, which is what I did.

Steps to reproduce

1. Make a new cloudflare project
2. add a proxy.ts file with the following content:

import { type NextRequest, NextResponse } from 'next/server';

export default async function proxy(req: NextRequest) {
  return response;
}

3. Run the deploy step (opennextjs-cloudflare deploy)
4. Get an error about only edge middleware being supported

Expected behavior

This should build properly as it imports no Node APIs, and is thus edge only.

@opennextjs/cloudflare version

1.19.11

Wrangler version

4.49.0

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:33:09 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 25.5.0
  npm: 11.8.0
  Yarn: 1.22.19
  pnpm: 9.4.0
Relevant Packages:
  next: 16.2.3 // There is a newer version (16.2.7) available, upgrade recommended! 
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Additional context

No response

[ScienHAC]

Hey team, I've opened a Pull Request over in #1280 to address this!

Here is the breakdown of the problem and how the PR implements the fix:

Problem

Next.js 16 replaces middleware.ts (Edge runtime) with proxy.ts (Node.js runtime).
Apps using proxy.ts currently fail at build time with:

Node.js middleware is not currently supported. Consider switching to Edge Middleware.

Proposed solution

Allow proxy.ts apps to build and deploy on Cloudflare Workers by:

1. Detecting Node.js middleware via functionsConfigManifest.functions["/_middleware"]
2. Warning instead of hard-exiting — lets the build continue
3. Copying the compiled middleware.js from the Next.js standalone output into the server bundle so esbuild can reach it
4. Patching loadNodeMiddleware() in next-server.js to require() the file via a static path (esbuild bundles dynamic requires only when the path is a string literal)
5. Writing a passthrough middleware/handler.mjs so the worker entry-point import stays valid

Requirement for users: nodejs_compat must be in compatibility_flags in wrangler.toml.

Related

• Next.js 16 proxy.ts docs: https://nextjs.org/docs/app/api-reference/file-conventions/proxy
• Next.js migration guide: https://nextjs.org/docs/messages/middleware-to-proxy

[vankayalapativv]

Hitting this exact issue on @opennextjs/cloudflare@1.19.11.

My proxy.ts only refreshes a Supabase session cookie on navigation — no
Node-specific APIs, no fs/crypto/etc., just createServerClient from
@supabase/ssr and NextResponse. Should be Edge-eligible by the actual
code, but the build hard-exits with "Node.js middleware is not currently
supported" regardless, since Next.js 16 compiles all proxy.ts/middleware
files to the Node.js runtime by default now (no runtime config escape
hatch — Next throws if you try to set one in a Proxy file).

This is currently a hard blocker for shipping to Cloudflare Workers for
any app using Supabase Auth (or anything else needing per-navigation
cookie refresh) on Next.js 16, since there's no way to opt the proxy file
back into Edge.

PR #1280 looks like a real, scoped fix for this exact problem. Saw on
#1213 that proxy/Node middleware support is intended to land via the
adapters-api project instead — if that's still the direction, would
appreciate a pointer to where that work is tracked, since right now
there's no supported path forward for this on @opennextjs/cloudflare.

Happy to test a fix against a real repo if that's useful.

[13RTK]

Same problem in NextJS v16, I use proxy.ts to protect the route via better auth

import { NextRequest, NextResponse } from 'next/server';
import { headers } from 'next/headers';
import { auth } from '@/lib/auth';

export async function proxy(request: NextRequest) {
  const session = await auth.api.getSession({
    headers: await headers(),
  });

  if (!session) {
    return NextResponse.redirect(new URL('/auth/sign-in', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/'], // Specify the routes the middleware applies to
};

[conico974]

@vankayalapativv @13RTK You can still use the old middleware file. Especially if you don't need anything that requires the Node runtime