# Next.js middleware.ts to proxy.ts: What Changes

Next.js 16 quietly renamed `middleware.ts` to `proxy.ts`, and most changelogs bury it in a single bullet point next to Cache Components and Turbopack. It deserves more attention than that, because the rename comes with a real architectural change: `proxy.ts` runs on the Node.js runtime by default instead of the Edge runtime `middleware.ts` used.

Three things change together:

1.  **Filename**: `middleware.ts` becomes `proxy.ts`
    
2.  **Export**: named export `middleware` becomes default export `proxy`
    
3.  **Default runtime**: Edge becomes Node.js
    

The runtime switch is the part worth paying attention to. Edge gave global low latency distribution but a restricted API surface, which often meant hunting for Edge compatible package forks. Node.js runtime gives `proxy.ts` full Node API access by default, removing most of that friction.

The good news: `middleware.ts` still works. It's deprecated, not removed, so nothing breaks on upgrade. Simple middleware (cookie checks, header rewrites, basic redirects) can migrate today in about five minutes. Middleware relying on Edge specific geo distribution or Edge only APIs should be benchmarked on `proxy.ts` in a branch before touching production traffic.

This guide walks through a real auth check example migrated step by step, a full compatibility table for what breaks under the Node.js runtime, and a free tool that rewrites your middleware file automatically.

Read the full guide:  
https://devencyclopedia.com/blog/nextjs-middleware-to-proxy